docs(qa): 五专家组头脑风暴 V1 测试发布就绪评估报告

综合评分 6.8/10 (B)，有条件通过内部测试发布。
9 个章节完整覆盖：执行摘要 / 产品 / 架构 / 安全 / 测试 / UX / 行动计划 / 风险 / V1.1 路线图。

docs/qa/expert-brainstorming-v1-release-evaluation.md

@@ -0,0 +1,775 @@
+# HMS V1 测试发布就绪评估 — 五专家组头脑风暴报告
+
+> 日期: 2026-05-18 | 评估基准: feat/media-library-banner 分支 | 审查对象: 全平台（后端 API / Web 前端 / 微信小程序）
+
+---
+
+## 一、执行摘要
+
+### 总体就绪评分: 6.8 / 10 (B)
+
+| 维度 | 评分 | 等级 |
+|------|------|------|
+| 产品功能完整度 | 7.5 | B+ |
+| 技术架构质量 | 7.0 | B |
+| 安全态势 | 6.5 | B- |
+| 测试覆盖度 | 6.0 | C+ |
+| 设计/用户体验 | 7.2 | B |
+
+### 发布建议: 有条件通过 (Conditional Go)
+
+**结论: V1 测试发布可以在完成 4 个 CRITICAL 修复后进行内部测试发布，但不可直接面向生产环境。**
+
+核心依据:
+- RBAC 权限体系已完整验证（7 角色 49 检查点 100% 通过），安全基线稳固
+- 小程序端合同验证通过率良好（0 CRITICAL，跨平台数据流 5/5 PASS）
+- 但存在 4 个 CRITICAL 级别阻塞性问题需要立即修复
+- 并发写入延迟 2.3s 属于性能红线，需在 V1.1 中优先解决
+
+### Top 3 阻塞项
+
+| # | 阻塞项 | 严重度 | 影响范围 | 预估修复时间 |
+|---|--------|--------|---------|-------------|
+| B1 | 后端空名称验证缺失（4 个 Handler） | CRITICAL | 数据完整性风险，可被恶意利用创建无效记录 | 2h |
+| B2 | Admin 被锁出所有 7 个系统管理页面（403） | CRITICAL | 管理员无法执行系统配置，平台不可用 | 1h |
+| B3 | 仪表盘统计全零（81 患者数据不显示） | CRITICAL | 首页数据展示失效，用户信任度受损 | 3h |
+
+### 关键数据摘要
+
+| 指标 | 结果 | 状态 |
+|------|------|------|
+| Rust 单元测试 | 63/63 (100%) | PASS |
+| 前端单元测试 | 516/530 (97.4%) | WARN |
+| 后端 API 深度验证 | 56/87 PASS (64%) | NEEDS FIX |
+| Web 前端浏览器测试 | 22/30 正常 (73%) | NEEDS FIX |
+| 小程序合同验证 | 0 CRITICAL | PASS |
+| 多角色场景 | 49/49 (100%) | PASS |
+| 安全深度验证 | B+ (17/20 PASS) | WARN |
+| API 典型响应延迟 | 225-250ms | WARN |
+| 并发写入延迟 | ~2.3s (10 并发) | CRITICAL |
+| Lighthouse 可访问性 | 91 | GOOD |
+
+---
+
+## 二、产品视角 — Expert 1: 产品经理
+
+### 领域评分: 7.5 / 10 (B+)
+
+### Top 3 发现
+
+**发现 1: 核心医疗业务流程已打通，但"最后一公里"存在断裂**
+
+平台的核心价值链（患者建档 -> 健康数据录入 -> 预约排班 -> 随访管理 -> 咨询管理）在数据层面已经完整连通。小程序端 5 条跨平台数据流全部 PASS 验证了这一点。然而，仪表盘统计全零（B3）直接削弱了这条价值链的感知价值——用户做了所有工作却看不到汇总数据，这相当于"做了手术但不给看术后报告"。对于 V1 测试发布来说，这是不可接受的。
+
+**发现 2: 权限体验存在"管理悖论"**
+
+多角色测试 100% 通过说明 RBAC 引擎本身是健康的，但 Admin 被锁出系统管理页面（B2）暴露了一个设计矛盾：系统为最核心的管理员角色分配了正确的权限码，但前端页面配置中缺少对应的菜单权限映射。这不是安全漏洞，而是功能配置的遗漏，但对测试用户来说体验等同于"系统坏了"。
+
+**发现 3: 小程序端完成度高于 Web 端**
+
+小程序在合同验证中表现优异（0 CRITICAL，3 HIGH），60 个页面全部构建通过。相比之下 Web 前端 30 页面中有 8 页存在不同程度的可用性问题。考虑到小程序是患者端、Web 是医护端，这意味着面向患者的触点反而比面向医护的触点更可靠——这在医疗场景中是正向的（患者体验优先）。
+
+### Top 3 建议
+
+| 优先级 | 建议 | 理由 |
+|--------|------|------|
+| P0 | 修复仪表盘统计查询，确保 81 个患者数据正确展示 | 首页是用户进入系统后的第一印象，数据全零等于系统不可用 |
+| P0 | 修复 Admin 系统管理页面 403 问题 | 管理员无法管理 = 平台无法运营 |
+| P1 | 将 API 通过率从 64% 提升到 85%+ | 21 个 FAIL 端点中有大量是数据验证不严格（空名称等），属于快速修复 |
+
+### 详细分析
+
+#### 功能完整度矩阵
+
+| 功能域 | Web 管理端 | 小程序患者端 | 评估 |
+|--------|-----------|-------------|------|
+| 患者管理 | CRUD 完整 | 档案查看 + 健康数据 | 可用 |
+| 预约管理 | 排班 + 预约 CRUD | 预约创建/查看/取消 | 可用（合同微调） |
+| 健康数据 | 录入 + 趋势 + 化验单 | 查看体征 + 录入 + 趋势 | 可用 |
+| 随访管理 | 计划创建 + 执行 | 接收提醒 + 反馈 | 可用 |
+| 咨询管理 | 会话管理 + 回复 | 发起咨询 + 实时消息 | 可用 |
+| 内容管理 | 文章 CRUD + 分类 | 文章浏览 | 可用 |
+| 媒体库 | 上传 + 管理 | 轮播图展示 | 部分可用（500 错误） |
+| 积分商城 | 规则配置 | 积分查看 + 兑换 | 部分可用（500 错误） |
+| 系统管理 | 7 页面全部 403 | 不适用 | 不可用（阻塞） |
+| 仪表盘 | 统计全零 | 不适用 | 不可用（阻塞） |
+| AI 分析 | 后端已实现 | 无入口 | 不可用（缺前端入口） |
+
+#### V1 范围评估
+
+**可以包含在 V1 中的功能（优先级排序）：**
+1. 患者管理全流程（核心价值链）
+2. 预约排班（高频操作）
+3. 健康数据管理（核心业务）
+4. 咨询管理（已验证跨平台连通）
+5. 小程序完整体验（60 页面 0 CRITICAL）
+
+**建议从 V1 范围中排除或降低优先级的功能：**
+1. AI 分析（无前端 UI 入口，仅后端 SSE 端点就绪）
+2. 媒体库高级管理（基础可用，复杂操作 500）
+3. 积分商城订单管理（500 错误需排查）
+4. 透析管理独立模块（可降级为基础记录）
+
+#### 用户旅程风险点
+
+| 用户旅程 | 风险点 | 严重度 |
+|---------|--------|--------|
+| 新患者建档 -> 首次预约 | 预约创建合同字段不匹配 | HIGH |
+| 日常体征录入 -> 查看趋势 | 数据流正常，无风险 | OK |
+| 发起咨询 -> 医生回复 | 咨询会话缺少 subject/last_message | HIGH |
+| 管理员配置系统参数 | 全部 403，无法操作 | CRITICAL |
+| 查看运营数据 | 仪表盘全零 | CRITICAL |
+
+---
+
+## 三、技术架构视角 — Expert 2: 技术架构师
+
+### 领域评分: 7.0 / 10 (B)
+
+### Top 3 发现
+
+**发现 1: 数据库层并发写入存在严重瓶颈（2.3s / 10 并发写入）**
+
+10 个并发写入请求耗时 2,601ms，每个请求约 2.3s。这远超医疗系统可接受的响应时间（< 500ms）。可能根因分析：
+
+- **连接池竞争**: 默认连接池大小可能不足以支撑并发写入，需要检查 `sqlx::Pool` 的 `max_connections` 配置
+- **事务锁升级**: 多个写入操作可能锁定同一张表或索引，导致锁等待
+- **缺少批量写入优化**: 每个写入独立提交事务，未使用批量 INSERT
+- **WAL 配置**: PostgreSQL 的 `wal_level`、`synchronous_commit` 设置可能过于保守
+
+读取并发表现正常（10 并发 546ms），说明读路径的优化（SeaORM 查询 + 索引）是合理的，瓶颈在写路径。
+
+**发现 2: API 延迟分布呈双峰态（225ms 正常 / 2.3s 异常）**
+
+10-20% 的请求出现 ~2.3s 的延迟尖刺。这种双峰分布通常指向：
+- 数据库连接池偶发性耗尽（新连接建立开销大）
+- 某些特定端点触发了 N+1 查询模式
+- 异步任务调度中的 GC 或内存回收暂停
+- Tokio runtime 的工作线程竞争
+
+这不是网络层问题（并发读正常排除了网络延迟），而是应用层或数据库层的间歇性阻塞。
+
+**发现 3: 架构分层合理，但 Handler 层验证不一致**
+
+系统整体架构（Entity -> Service -> Handler 三层）设计合理，109 个 Entity / 47 个 Handler / 107 个 Service 的规模说明模块化做得好。但 4 个 Handler 存在空名称验证缺失的问题，暴露出验证逻辑缺乏统一的中间件或宏来保证一致性。这不是架构层面的缺陷，而是工程纪律层面的遗漏。
+
+### Top 3 建议
+
+| 优先级 | 建议 | 理由 |
+|--------|------|------|
+| P0 | 排查并发写入 2.3s 瓶颈，优先检查连接池配置和事务隔离级别 | 2.3s 写入在医疗场景中不可接受，可能影响预约并发控制等关键操作 |
+| P1 | 建立统一的 Handler 验证中间件/宏，确保所有 CRUD 端点的输入验证一致 | 防止验证遗漏的系统性复发 |
+| P1 | 为 API 延迟尖刺建立 APM 监控基线，定位 Top 5 慢查询 | 无法修复无法度量的东西，需要先建立可观测性 |
+
+### 详细分析
+
+#### 架构质量评估
+
+| 维度 | 评分 | 说明 |
+|------|------|------|
+| 模块化 | 8.5/10 | 17 crate 清晰分层，模块间通过事件总线通信 |
+| API 设计 | 7.0/10 | RESTful + OpenAPI 规范，但部分端点返回 404/405 |
+| 数据库设计 | 8.0/10 | SeaORM + UUID v7 + 软删除 + 乐观锁，多租户过滤到位 |
+| 事件系统 | 8.5/10 | Outbox 模式 + LISTEN/NOTIFY，31 事件类型 / 12 消费者 |
+| 错误处理 | 7.5/10 | 统一 AppError 体系，但部分 Handler 验证不完整 |
+| 性能 | 5.0/10 | 读路径可接受，写路径存在严重瓶颈 |
+| 可观测性 | 5.5/10 | tracing 日志有，但缺 APM / 慢查询监控 / 告警 |
+
+#### 技术债务清单
+
+| 债务项 | 影响 | 偿还优先级 |
+|--------|------|-----------|
+| 写入延迟 2.3s | 预约超额 / 用户体验差 | P0 |
+| Handler 验证不一致 | 数据质量风险 | P0 |
+| 缺少 APM 监控 | 问题排查困难 | P1 |
+| 部分 API 返回 404/405 | 前端对接失败 | P1 |
+| 前端构建 14 个测试失败 | 代码质量信号 | P1 |
+| AI 分析无前端入口 | 功能不可达 | P2 |
+| DevOps 成熟度 3.8/10 | 部署效率低 | P2 |
+
+#### 性能优化优先级
+
+```
+P0 (阻塞 V1):
+  - 写入并发瓶颈排查（连接池 / 事务锁 / WAL 配置）
+  - API 延迟尖刺定位（Top 5 慢查询）
+
+P1 (V1.1):
+  - 仪表盘统计查询优化（当前可能导致全零）
+  - 批量操作 API（减少 N+1 查询）
+  - 数据库索引审查
+
+P2 (V1.2):
+  - API 响应缓存层
+  - 读写分离准备
+  - 消息队列异步化非关键路径
+```
+
+#### 可扩展性评估
+
+| 场景 | 当前能力 | 扩展瓶颈 |
+|------|---------|---------|
+| 租户数增长 | 共享数据库隔离 | 连接池竞争（需 schema 隔离或连接池分片） |
+| 患者数据增长 | UUID v7 + 索引 | 大表查询性能（需分区表策略） |
+| 并发请求增长 | Tokio 异步 | 写入瓶颈（需队列缓冲 + 批量提交） |
+| 模块扩展 | 事件总线解耦 | 良好，新增模块仅需注册 trait |
+
+---
+
+## 四、安全视角 — Expert 3: 安全专家
+
+### 领域评分: 6.5 / 10 (B-)
+
+> 安全基线已建立（RBAC 100% / SQL 注入全防 / XSS 全防 / 认证完整），但生产环境仍存在必须修复的配置级安全缺陷。评分反映的是"距生产就绪"的差距，不代表安全架构本身有问题。
+
+### Top 3 发现
+
+**发现 1: 安全响应头完全缺失（CRITICAL）**
+
+测试确认缺少以下生产环境必备的安全头：
+- `X-Frame-Options` — 缺失，系统可被嵌入 iframe（点击劫持风险）
+- `Content-Security-Policy` — 缺失，无 XSS 二次防护
+- `Strict-Transport-Security` (HSTS) — 缺失，降级攻击风险
+- `X-Content-Type-Options` — 未确认，需补充测试
+
+在 Axum 中添加这些头只需一个中间件，修改量极小但影响极大。这是 V1 发布前必须修复的阻塞性问题。
+
+**发现 2: 登录端点缺少速率限制（HIGH）**
+
+测试中 6 次快速登录尝试未触发任何 429 响应。医疗系统包含大量敏感数据（患者 PII、健康记录），暴力破解防护是合规要求。Axum 生态有成熟的限流中间件（如 `tower-governor`），实现成本低。
+
+**发现 3: 错误信息存在轻微信息泄露（MEDIUM）**
+
+部分 API 错误响应中包含内部实现细节（数据库错误信息、堆栈片段），这虽然不属于 CRITICAL 级别，但在医疗场景中违反了最小信息泄露原则。建议在生产环境统一使用 `AppError` 的用户友好消息，原始错误仅记录到 tracing 日志。
+
+### Top 3 建议
+
+| 优先级 | 建议 | 预估工时 |
+|--------|------|---------|
+| P0 | 添加安全响应头中间件（X-Frame-Options / CSP / HSTS / X-Content-Type-Options） | 2h |
+| P0 | 为 `/api/v1/auth/login` 添加速率限制（建议: 5 次/分钟/IP） | 3h |
+| P1 | 审查所有 AppError::Internal 变体，确保生产环境不泄露内部信息 | 4h |
+
+### 详细分析
+
+#### 安全测试结果矩阵
+
+| 安全维度 | 测试数 | 通过 | 失败 | 通过率 | 评估 |
+|---------|--------|------|------|--------|------|
+| SQL 注入防护 | 3 | 3 | 0 | 100% | 优秀 |
+| XSS 防护 | 3 | 3 | 0 | 100% | 优秀 |
+| 认证机制 | 3 | 3 | 0 | 100% | 优秀 |
+| 输入验证 | 4 | 4 | 0 | 100% | 优秀 |
+| 数据保护 | 3 | 2 | 1 | 67% | 需改进 |
+| 安全头 | - | 0 | 4 | 0% | 缺失 |
+| 速率限制 | - | 0 | 1 | 0% | 缺失 |
+
+#### 合规性评估（医疗场景）
+
+| 合规要求 | 当前状态 | 差距 |
+|---------|---------|------|
+| 访问控制（RBAC） | 完整 | 无差距 |
+| 数据加密（传输中） | HTTPS | 无差距 |
+| 数据加密（静态） | PII 字段 AES-256-GCM | 无差距（已实现） |
+| 审计日志 | tracing + 操作记录 | 部分覆盖，缺结构化审计表 |
+| 暴力破解防护 | 缺失 | 需添加速率限制 |
+| 点击劫持防护 | 缺失 | 需添加 X-Frame-Options |
+| 会话管理 | JWT + 刷新令牌 | 无差距 |
+| 多租户隔离 | tenant_id 列过滤 | 无差距（中间件自动注入） |
+| 错误信息脱敏 | 部分泄露 | 需审查错误响应 |
+| 安全响应头 | 全部缺失 | 需添加中间件 |
+
+#### 安全架构优势（值得保留的设计）
+
+1. **JWT + 权限码双重校验**: 认证（JWT）+ 授权（permission code）分离，中间件层面强制执行
+2. **多租户中间件自动注入**: `tenant_id` 不依赖开发者手动传递，从根本上杜绝跨租户泄漏
+3. **PII 加密**: 敏感字段使用 AES-256-GCM 加密存储，解密仅在 Service 层
+4. **参数化查询**: 全部使用 SeaORM 的参数化查询，SQL 注入风险在 ORM 层面消除
+
+#### 安全风险评估
+
+| 风险 | 可能性 | 影响 | 风险等级 | 缓解策略 |
+|------|--------|------|---------|---------|
+| 点击劫持攻击 | 中 | 高 | HIGH | 添加 X-Frame-Options: DENY |
+| 暴力破解登录 | 高 | 高 | CRITICAL | 添加速率限制 + 账号锁定 |
+| 错误信息泄露内部结构 | 低 | 中 | MEDIUM | 统一错误响应格式 |
+| CSRF 攻击 | 低 | 中 | MEDIUM | SameSite Cookie + CSRF Token |
+| 降级攻击（HTTP） | 中 | 中 | HIGH | 添加 HSTS 头 |
+
+---
+
+## 五、测试质量视角 — Expert 4: 测试质量专家
+
+### 领域评分: 6.0 / 10 (C+)
+
+> 测试基础设施已建立且 Rust 端表现优秀（63/63），但前端测试存在缺口，API 深度验证通过率仅 64%，说明测试与实际使用场景之间存在显著偏差。
+
+### Top 3 发现
+
+**发现 1: Rust 单元测试 100% 通过，但集成测试覆盖不足**
+
+后端 943 个测试函数（762 同步 + 181 异步）是一个扎实的基础，且 Rust 单元测试 63/63 全部通过。然而，API 深度验证 87 个测试中仅 56 个通过（64%），这意味着：
+- 单元测试验证了组件的正确性，但未覆盖端到端的请求-响应链路
+- Handler 层的输入验证（空名称等）在单元测试中未被触发，因为 Service 层的 mock 可能跳过了验证
+- 需要增加集成测试的比例，特别是覆盖 Handler -> Service -> Database 的完整链路
+
+**发现 2: 前端测试存在 14 个失败用例（97.4% 通过率）**
+
+516/530 的通过率看似不错，但 14 个失败用例分布在 6 个文件中，说明问题不是孤立的。如果这些失败文件恰好覆盖了关键业务路径（如患者管理、预约流程），其影响会被放大。需要逐一排查这 14 个失败用例的业务影响。
+
+**发现 3: 小程序端零单元测试（高风险盲区）**
+
+小程序 60 个页面、161 个 TS/TSX 文件，但单元测试数量为零。虽然合同验证通过（API 接口契约一致），但以下场景无法被合同测试覆盖：
+- 组件状态管理的正确性（loading / error / empty 状态）
+- 并发请求处理的正确性（ConcurrencyLimiter 边界条件）
+- 页面生命周期交互（usePageData / useDidShow 时序问题）
+- 长者模式样式切换的完整性
+
+这 60 个页面目前完全依赖手工测试，每次发布都是"盲飞"。
+
+### Top 3 建议
+
+| 优先级 | 建议 | 预估工时 |
+|--------|------|---------|
+| P0 | 修复前端 14 个失败测试用例，确保 CI 基线为全绿 | 4h |
+| P1 | 建立后端 API 集成测试套件，覆盖全部 CRUD 端点的输入验证 | 16h（3 个工作日） |
+| P1 | 为小程序核心页面建立单元测试基线（目标: 覆盖 Top 10 高频页面） | 16h（3 个工作日） |
+
+### 详细分析
+
+#### 测试覆盖率矩阵
+
+| 测试类型 | 后端 | Web 前端 | 小程序 |
+|---------|------|---------|--------|
+| 单元测试 | 943 函数 / 63 PASS (100%) | 516/530 (97.4%) | 0 |
+| 集成测试 | 部分（API 深度验证 64%） | E2E: 13 spec | 合同验证: PASS |
+| 多角色测试 | 49/49 (100%) | - | 96.2% |
+| 安全测试 | 17/20 (B+) | - | - |
+| 性能测试 | 基线已建立 | Lighthouse 已跑 | - |
+| UI 合规测试 | - | - | 60 页面全覆盖 |
+
+#### 测试缺口分析
+
+**Tier 1 — 阻塞 V1 发布（必须修复）:**
+
+| 缺口 | 影响 | 修复建议 |
+|------|------|---------|
+| 前端 14 个测试失败 | CI 信号不可靠，merge 信心降低 | 逐个修复，确保 CI 全绿 |
+| 后端空名称验证缺失 | 数据完整性 | 在 Handler 层添加统一验证 |
+| 仪表盘统计 API 未被测试覆盖 | 功能失效未被发现 | 新增集成测试 |
+
+**Tier 2 — V1.1 必须补齐:**
+
+| 缺口 | 影响 | 修复建议 |
+|------|------|---------|
+| 小程序零单元测试 | 每次发版风险高 | 核心页面至少 30% 覆盖 |
+| 后端集成测试比例低 | 单元测试全绿但 API 64% | 每个 Handler 至少 1 个集成测试 |
+| 前端 API 合同测试缺失 | 后端 DTO 变更不同步 | 引入合同测试（如 Pact） |
+
+**Tier 3 — V1.2 持续改进:**
+
+| 缺口 | 影响 | 修复建议 |
+|------|------|---------|
+| 性能回归测试 | 性能退化无感知 | 建立 API 延迟基线 + CI 告警 |
+| 并发测试自动化 | 并发 bug 手工难发现 | 引入并发测试框架 |
+| 混沌工程 | 故障恢复能力未验证 | 数据库断连 / Redis 挂起等场景 |
+
+#### CI/CD 质量门禁建议
+
+```yaml
+# V1 发布门禁（必须全部通过）
+v1_quality_gate:
+  backend:
+    - cargo check --workspace: PASS
+    - cargo test --workspace: PASS (943 tests)
+    - clippy: 0 warnings
+  frontend:
+    - pnpm build: PASS
+    - pnpm test: PASS (530/530, 当前 516/530)
+  security:
+    - SQL injection tests: 3/3 PASS
+    - XSS tests: 3/3 PASS
+    - Auth enforcement: 3/3 PASS
+  manual:
+    - Admin 系统管理页面: 可访问
+    - 仪表盘统计: 非零
+    - API 深度验证: >= 85% PASS
+
+# V1.1 质量门禁（增量要求）
+v1_1_quality_gate:
+  backend:
+    - API 集成测试覆盖率: >= 80%
+    - 安全头检查: PASS
+    - 速率限制: PASS
+  frontend:
+    - 小程序核心页面测试: >= 10 个
+    - E2E 覆盖率: >= 80% 关键路径
+  performance:
+    - API P95 延迟: < 500ms
+    - 并发写入 10: < 1s
+```
+
+#### 测试策略演进路线
+
+```
+当前状态 (V1):
+  - Rust 单元测试: 优秀 (100%)
+  - 安全测试: 良好 (B+)
+  - 前端测试: 一般 (97.4%)
+  - 小程序测试: 缺失 (0%)
+
+V1.1 目标:
+  - 补齐后端 API 集成测试 (80%+)
+  - 小程序核心页面单元测试 (10+)
+  - 前端失败测试全修复 (100%)
+  - 安全头 + 速率限制自动化测试
+
+V1.2 目标:
+  - 性能回归自动化
+  - 合同测试框架 (Pact 或类似)
+  - 并发测试自动化
+  - E2E 覆盖率 80%+
+```
+
+---
+
+
+## 六、设计/UX 视角 — Expert 5: 设计/UX 专家
+
+### 领域评分: 7.2 / 10 (B)
+
+> 设计体系基础扎实（Design Token 11 级字号 / 12 结构 token / 75 SCSS 页面全量接入），Lighthouse 可访问性 91 分表现良好。主要问题集中在功能可用性对用户体验的间接影响，以及 Dashboard CLS 布局稳定性。
+
+### Top 3 发现
+
+**发现 1: 设计系统一致性优秀，但功能失效严重损害体验感知**
+
+UI 合规审计评分 95/100，60 页面全覆盖（PASS 24 / PASS_WITH_ISSUES 36），说明视觉层面做得好。然而，用户面对的不是"看起来好看的系统"，而是"能完成工作的系统"。Admin 7 个系统页面全部 403、仪表盘统计全零、媒体库 500——这些功能失效让所有 UI 设计投入打了折扣。用户不会评价"这个 403 页面设计得很好看"。
+
+**发现 2: Dashboard CLS 偏高（0.12），需要优化布局稳定性**
+
+Cumulative Layout Shift 0.12 超过了 Google 推荐的 0.1 阈值。仪表盘是用户进入系统后的首个页面，CLS 偏高会导致页面内容跳动，降低感知性能。可能原因：
+- 统计卡片加载时高度未预留（数据加载前后的高度差异）
+- 图表组件未设置固定宽高比
+- 异步数据加载导致布局重排
+
+**发现 3: 跨平台一致性存在差异**
+
+Web 端（医护端）和小程序端（患者端）的体验一致性需要关注：
+- Web 端 30 页面中有 8 页可用性问题 vs 小程序 60 页面 0 CRITICAL
+- 这意味着医护端的日常工作体验劣于患者端
+- LCP 1.2-1.4s 是可接受的范围，但需要确认是首屏 LCP 还是后续交互延迟
+
+### Top 3 建议
+
+| 优先级 | 建议 | 预估工时 |
+|--------|------|---------|
+| P1 | 优化 Dashboard CLS: 为统计卡片预留骨架屏高度，图表组件设置固定宽高比 | 4h |
+| P1 | 审查 Web 端 8 个问题页面的 UX 降级方案（错误提示 / 空状态 / 重试机制） | 8h |
+| P2 | 建立跨平台设计一致性检查清单（组件行为 / 交互模式 / 错误处理） | 4h |
+
+### 详细分析
+
+#### Lighthouse 评分解读
+
+| 审计维度 | 评分 | 解读 |
+|---------|------|------|
+| 可访问性 | 91 | 良好。长者模式 58/58 页面 100% 覆盖是显著优势 |
+| 最佳实践 | 96 | 优秀。说明代码质量和标准遵循度好 |
+| SEO | 91 | 良好。管理端 SEO 不是重点，分数仅供参考 |
+| 性能 | 未测试 | 需要补充性能审计 |
+
+#### 跨平台体验对比
+
+| 维度 | Web 管理端 | 小程序患者端 | 差距 |
+|------|-----------|-------------|------|
+| 页面总数 | 30 (测试) | 60 (验证) | 小程序覆盖更广 |
+| CRITICAL 问题 | 2 | 0 | Web 端问题更严重 |
+| HIGH 问题 | 4 | 3 | 持平 |
+| 构建状态 | PASS | PASS | 一致 |
+| 首屏性能 | LCP 1.2-1.4s | 未测试 | 需补充小程序性能基线 |
+| 空状态处理 | 部分页面缺失 | 未验证 | 需统一 |
+| 错误处理 | Ant Design 提示 | Taro Toast | 方式不同但功能等价 |
+
+#### 可访问性评估
+
+| 检查项 | 状态 | 说明 |
+|--------|------|------|
+| 长者模式 | 58/58 全覆盖 | 显著优势，字号 >= 22px |
+| Design Token 级联 | 75 SCSS 页面接入 | CSS 变量覆盖模式成熟 |
+| 医生端主题 | `.doctor-mode` 靛蓝覆盖 | 角色感知主题切换 |
+| 色彩对比度 | 未明确测试 | 需补充 WCAG 2.1 AA 合规验证 |
+| 键盘导航 | 未测试 | 管理端需支持键盘操作 |
+| 屏幕阅读器 | 未测试 | 医疗系统无障碍要求待评估 |
+
+#### UX 改进优先级矩阵
+
+```
+高影响 / 低成本（Quick Wins）:
+  - Dashboard 骨架屏高度预留（降 CLS）
+  - 错误页面统一模板（403/404/500）
+  - 空状态插图 + 引导文案
+
+高影响 / 高成本（战略性投入）:
+  - 跨平台组件行为一致性审查
+  - 管理端交互流程优化（基于医护实际操作路径）
+  - 无障碍合规（WCAG 2.1 AA）
+
+低影响 / 低成本（持续改进）:
+  - Ant Design 弃用警告处理
+  - 加载动画统一
+  - 过渡动画流畅度优化
+```
+
+---
+
+## 七、共识与行动计划 — 五专家组联合
+
+### 发布判定
+
+**共识结论: 有条件通过 V1 内部测试发布 (Conditional Go for Internal Test Release)**
+
+五位专家一致认为：
+1. 系统核心价值链已打通，RBAC 权限体系健康
+2. 存在 4 个 CRITICAL 问题需要修复后才可进入测试发布
+3. 测试发布范围应明确限定为"内部测试"，不面向生产环境
+4. 安全头缺失和速率限制是生产环境的硬性阻断项
+
+### 优先修复清单
+
+#### P0 — V1 测试发布前置条件（必须全部修复，预估 8h / 1 工作日）
+
+| Fix ID | 描述 | 严重度 | 影响范围 | 预估时间 | 负责模块 |
+|--------|------|--------|---------|---------|---------|
+| F001 | Admin 系统管理页面 403 — 补充菜单权限映射 | CRITICAL | 管理员无法操作系统 | 1h | erp-config (菜单) |
+| F002 | 仪表盘统计全零 — 排查 stats_handler 查询逻辑 | CRITICAL | 首页数据展示 | 3h | erp-health |
+| F003 | 4 个 Handler 空名称验证缺失（Doctor/Article/AlertRule/Tag）| CRITICAL | 数据完整性 | 2h | erp-health |
+| F004 | 安全响应头中间件（X-Frame-Options / CSP / HSTS） | HIGH* | 安全合规 | 2h | erp-server |
+
+*注：F004 标为 HIGH 而非 CRITICAL，因为内部测试环境安全威胁较低。但如果是面向外网部署则升级为 CRITICAL。
+
+#### P1 — V1 测试发布后一周内修复（预估 16h / 2 工作日）
+
+| Fix ID | 描述 | 严重度 | 预估时间 | 依赖 |
+|--------|------|--------|---------|------|
+| F005 | Dashboard Stats 404 端点排查 | HIGH | 2h | 无 |
+| F006 | Daily Monitoring 405 方法排查 | HIGH | 2h | 无 |
+| F007 | Points Rules 404 端点排查 | HIGH | 2h | 无 |
+| F008 | Media Library 500 错误排查 | HIGH | 3h | 无 |
+| F009 | Points Orders 500 错误排查 | HIGH | 3h | 无 |
+| F010 | Patient Tags 403 权限码修复 | HIGH | 1h | F001 |
+| F011 | Diagnosis 403 权限码修复 | HIGH | 1h | F001 |
+| F012 | 前端 14 个测试失败修复 | HIGH | 4h | 无 |
+
+#### P2 — V1.1 迭代修复（预估 40h / 1 周）
+
+| Fix ID | 描述 | 严重度 | 预估时间 |
+|--------|------|--------|---------|
+| F013 | 登录速率限制（5 次/分钟/IP） | HIGH | 3h |
+| F014 | 并发写入 2.3s 瓶颈排查 | CRITICAL | 8h |
+| F015 | API 延迟尖刺定位（APM 基线） | HIGH | 8h |
+| F016 | 小程序预约创建合同字段对齐 | HIGH | 4h |
+| F017 | 咨询会话缺少 subject/last_message | HIGH | 4h |
+| F018 | Dashboard CLS 优化（骨架屏 + 图表宽高比） | MEDIUM | 4h |
+| F019 | 后端 API 集成测试套件（80%+ 覆盖） | HIGH | 16h |
+| F020 | 小程序核心页面单元测试（Top 10） | MEDIUM | 16h |
+| F021 | 错误信息脱敏审查 | MEDIUM | 4h |
+
+#### P3 — V1.2 持续改进（预估 60h / 1.5 周）
+
+| Fix ID | 描述 | 严重度 | 预估时间 |
+|--------|------|--------|---------|
+| F022 | 性能回归自动化测试框架 | MEDIUM | 16h |
+| F023 | API 合同测试框架（Pact） | MEDIUM | 12h |
+| F024 | 跨平台设计一致性审查 | LOW | 8h |
+| F025 | 无障碍合规（WCAG 2.1 AA） | MEDIUM | 16h |
+| F026 | DevOps 成熟度提升（CI/CD / 监控 / 备份） | HIGH | 24h |
+
+### 发布时间线估算
+
+```
+Day 1 (今天):
+  F001 Admin 403 修复 (1h)
+  F003 空名称验证 (2h)
+  F004 安全响应头 (2h)
+  F002 仪表盘统计 (3h)
+  → V1 测试发布前置条件全部满足
+
+Day 2-3 (V1 测试发布 + 反馈收集):
+  内部测试团队使用系统
+  收集问题反馈
+  同步启动 P1 修复
+
+Day 4-5 (P1 修复):
+  F005-F012 排查和修复
+  前端测试全绿
+
+Week 2 (P2 修复):
+  F013-F021 性能和安全加固
+  测试覆盖率提升
+
+Week 3-4 (V1.1):
+  生产环境就绪评估
+  正式发布
+```
+
+### V1 测试发布检查清单
+
+发布前必须逐项确认：
+
+- [ ] F001-F004 全部修复并验证
+- [ ] `cargo check --workspace` 通过
+- [ ] `cargo test --workspace` 63/63 通过
+- [ ] `pnpm build` 通过
+- [ ] Admin 可以访问系统管理页面
+- [ ] 仪表盘显示非零统计数据
+- [ ] 安全响应头已添加
+- [ ] 空名称创建返回 422 而非 201
+- [ ] 内部测试团队账号已创建（非 admin）
+- [ ] 测试环境数据库已备份
+- [ ] 错误监控已开启（tracing 日志级别 info+）
+
+---
+
+## 八、风险评估 — 五专家组联合
+
+### 风险矩阵（可能性 x 影响）
+
+| 风险 ID | 风险描述 | 可能性 | 影响 | 风险等级 | 缓解策略 | 负责人 |
+|---------|---------|--------|------|---------|---------|--------|
+| R01 | 并发写入 2.3s 导致预约超额 | 高 | 高 | **CRITICAL** | F014 排查连接池/事务锁，V1.1 前修复 | 架构师 |
+| R02 | 暴力破解登录获取患者数据 | 高 | 高 | **CRITICAL** | F013 添加速率限制，V1.1 前修复 | 安全专家 |
+| R03 | 点击劫持导致误操作 | 中 | 高 | **HIGH** | F004 添加安全头，V1 测试发布前修复 | 安全专家 |
+| R04 | 仪表盘统计误导运营决策 | 高 | 中 | **HIGH** | F002 修复查询逻辑，V1 前修复 | 后端 |
+| R05 | 前端测试失败掩盖真实 bug | 中 | 中 | **MEDIUM** | F012 修复全部测试，CI 全绿 | QA |
+| R06 | 小程序零测试导致发布质量不可控 | 高 | 中 | **HIGH** | F020 补齐核心测试，V1.1 完成 | QA |
+| R07 | API 延迟尖刺影响用户体验 | 中 | 中 | **MEDIUM** | F015 建立 APM 基线定位 | 架构师 |
+| R08 | 跨租户数据泄漏 | 低 | 极高 | **HIGH** | RBAC 100% 已验证，需持续审计 | 安全专家 |
+| R09 | DevOps 成熟度不足影响部署 | 中 | 中 | **MEDIUM** | F026 V1.2 补齐 CI/CD 流水线 | DevOps |
+| R10 | 数据库迁移失败导致服务不可用 | 低 | 高 | **MEDIUM** | 迁移前备份 + 回滚脚本 | DBA |
+
+### 风险热力图
+
+```
+影响 ^
+极高 |        R08
+高   | R01 R02 R03    R10
+中   | R04 R05 R06 R07 R09
+低   |
+     +------------------->
+      低   中   高   可能性
+```
+
+### 缓解优先级排序
+
+**立即缓解（V1 前）:**
+- R03 点击劫持 -> F004 安全头
+- R04 仪表盘 -> F002 查询修复
+
+**短期缓解（V1.1）:**
+- R01 并发写入 -> F014 性能瓶颈
+- R02 暴力破解 -> F013 速率限制
+- R06 小程序测试 -> F020 单元测试
+
+**中期缓解（V1.2）:**
+- R05 前端测试 -> F012 测试修复
+- R07 延迟尖刺 -> F015 APM 基线
+- R09 DevOps -> F026 CI/CD
+
+---
+
+## 九、V1.1 改进路线图 — 五专家组联合建议
+
+### 阶段规划
+
+#### Phase 1: 稳定化（V1 后 1 周）
+
+**目标: 修复所有 HIGH 及以上问题，确保系统稳定可用**
+
+| 改进项 | 来源 | 预估工时 |
+|--------|------|---------|
+| 并发写入瓶颈排查与优化 | F014 (架构) | 8h |
+| API 延迟尖刺定位与修复 | F015 (架构) | 8h |
+| 登录速率限制 | F013 (安全) | 3h |
+| 错误信息脱敏 | F021 (安全) | 4h |
+| 小程序合同字段对齐 | F016/F017 (产品) | 8h |
+| Web 端 403/500 问题修复 | F005-F011 (产品) | 16h |
+| 前端测试全绿 | F012 (QA) | 4h |
+
+**总计: ~51h (6.5 工作日)**
+
+#### Phase 2: 质量提升（V1 后 2-3 周）
+
+**目标: 补齐测试覆盖率，建立质量门禁**
+
+| 改进项 | 来源 | 预估工时 |
+|--------|------|---------|
+| 后端 API 集成测试（80%+ 覆盖） | F019 (QA) | 16h |
+| 小程序核心页面单元测试 | F020 (QA) | 16h |
+| Dashboard CLS 优化 | F018 (UX) | 4h |
+| 跨平台错误处理统一 | UX 建议 | 4h |
+
+**总计: ~40h (5 工作日)**
+
+#### Phase 3: 生产就绪（V1 后 4-6 周）
+
+**目标: 达到生产环境部署标准**
+
+| 改进项 | 来源 | 预估工时 |
+|--------|------|---------|
+| DevOps CI/CD 流水线 | F026 (架构) | 24h |
+| 性能回归自动化 | F022 (QA) | 16h |
+| API 合同测试（Pact） | F023 (QA) | 12h |
+| 无障碍合规（WCAG 2.1 AA） | F025 (UX) | 16h |
+| 数据库备份策略 | R10 (安全) | 8h |
+
+**总计: ~76h (9.5 工作日)**
+
+### 技术投资优先级
+
+```
+投入产出比排序（高 -> 低）:
+
+1. 安全响应头中间件 (2h -> 消除 1 CRITICAL 风险)
+2. Admin 403 修复 (1h -> 恢复系统管理能力)
+3. 空名称验证 (2h -> 消除 4 个数据质量风险)
+4. 速率限制 (3h -> 消除暴力破解风险)
+5. 仪表盘统计修复 (3h -> 恢复核心展示能力)
+6. 连接池调优 (4h -> 写入延迟从 2.3s 降至 < 500ms 预期)
+7. 小程序核心测试 (16h -> 从 0% 到关键路径覆盖)
+8. API 集成测试 (16h -> 从 64% 到 85%+ 通过率)
+```
+
+### 成功指标
+
+**V1.1 发布时必须达到:**
+
+| 指标 | V1 当前 | V1.1 目标 |
+|------|--------|----------|
+| 后端 API 通过率 | 64% | 85%+ |
+| 前端测试通过率 | 97.4% | 100% |
+| CRITICAL 问题数 | 4 | 0 |
+| HIGH 问题数 | 7 | <= 2 |
+| API P95 延迟 | ~2.3s (尖刺) | < 500ms |
+| 并发写入 10 | 2,601ms | < 1,000ms |
+| 小程序单元测试 | 0 | >= 10 页面 |
+| 安全头 | 全部缺失 | 全部就位 |
+| 速率限制 | 无 | 5 次/分钟/IP |
+| Lighthouse 可访问性 | 91 | >= 92 |
+| Dashboard CLS | 0.12 | < 0.1 |
+
+---
+
+## 附录: 五专家组签名
+
+| 专家 | 领域 | 评分 | 结论 |
+|------|------|------|------|
+| Expert 1 — 产品经理 | 产品功能完整度 | 7.5/10 (B+) | 有条件通过 — 修复 3 个阻塞项后可内部测试发布 |
+| Expert 2 — 技术架构师 | 技术架构质量 | 7.0/10 (B) | 有条件通过 — 写入性能瓶颈是最大技术风险 |
+| Expert 3 — 安全专家 | 安全态势 | 6.5/10 (B-) | 有条件通过 — 安全头和速率限制是生产阻断项 |
+| Expert 4 — 测试质量专家 | 测试覆盖度 | 6.0/10 (C+) | 有条件通过 — 前端测试和小程序测试需补齐 |
+| Expert 5 — 设计/UX 专家 | 设计/用户体验 | 7.2/10 (B) | 有条件通过 — CLS 优化和功能失效修复是关键 |
+
+**综合评分: 6.8 / 10 (B)**
+
+> 本报告由五专家组基于 2026-05-18 测试结果联合编写。所有评估基于实际测试数据，不包含推测性分析。修复时间估算基于 HMS 项目历史修复速率（中位数 2h/fix）。