107 lines
3.9 KiB
Markdown
107 lines
3.9 KiB
Markdown
# 技术债清理策略讨论
|
||
|
||
> 日期: 2026-04-28 | 参与者: 用户 + Claude
|
||
|
||
## 背景
|
||
|
||
HMS 健康管理平台经过 17 天密集开发（301+ 次提交），功能层面已建成完整的医疗 SaaS 骨架。但安全合规、测试质量、事件消费闭环三个维度存在系统性欠账——6 个 Critical 安全问题、测试覆盖率 < 5%、13 个事件仅 3 个被消费。需要确定技术债清理策略。
|
||
|
||
## 讨论要点
|
||
|
||
### 1. 还债策略选择
|
||
|
||
**选项：**
|
||
- A: Critical 优先，集中清理
|
||
- B: 按类型分批还债（安全→事件→测试）
|
||
- C: 随功能开发顺带还
|
||
- D: 重新排列优先级
|
||
|
||
**结论：选择 B（按类型分批还债）**，批内 Critical 优先。
|
||
|
||
### 2. 小程序 PII 密钥管理
|
||
|
||
**选项：**
|
||
- A: 密钥由后端下发
|
||
- B: 密钥协商（ECDH）
|
||
- C: 后端加解密
|
||
- D: 后端加解密 + Blind Index
|
||
|
||
**结论：选择 D（后端加解密 + Blind Index）**
|
||
- 前端不接触加密密钥
|
||
- 盲索引支持精确搜索（HMAC-SHA256）
|
||
- API 按角色/场景返回不同脱敏级别
|
||
- A4+A5+A8+A9 四个 Critical 合并为一个实施任务
|
||
|
||
### 3. 事件消费者补全策略
|
||
|
||
**选项：**
|
||
- A: vital.critical 最先
|
||
- B: 先建框架再接业务
|
||
- C: 全部一起补
|
||
|
||
**结论：选择 A（vital.critical 最先）**
|
||
- 危急体征告警无人响应是真实医疗安全风险
|
||
- 30min 未确认分级升级（主治→科室主任→院领导）
|
||
- 微信订阅消息推送
|
||
- 新增 critical_alerts + critical_alert_responses 表
|
||
|
||
### 4. 积分系统处理方式
|
||
|
||
**选项：**
|
||
- A: 拆为独立 crate erp-points
|
||
- B: health 子模块先拆出来
|
||
- C: 跳过，后续再聊
|
||
|
||
**结论：选择 A（拆为独立 crate erp-points）**
|
||
- 清晰模块边界，积分可跨业务复用
|
||
- points_service.rs（1805 行）拆为 6 个子模块
|
||
- 事件契约：订阅 lab_report.uploaded / patient.verified / daily_monitoring.created
|
||
|
||
### 5. 批次 B/C 顺序
|
||
|
||
**结论：B 先（事件优先），C 后（测试）**
|
||
|
||
### 6. 测试入口选择
|
||
|
||
**选项：**
|
||
- A: 修基础设施让现有测试跑通
|
||
- B: 从安全测试开始写
|
||
- C: 跳过测试
|
||
|
||
**结论：选择 B（从安全测试开始写）**
|
||
- 与批次 A 联动，修一个写一个
|
||
- 事务回滚模式解决并行化问题
|
||
|
||
### 7. 代码审计发现
|
||
|
||
讨论过程中对代码进行了实际验证，发现：
|
||
- `follow_up_service.rs` 的 SQL 实际已参数化（`$N` 占位符），不是注入风险
|
||
- `tenant_rls.rs` 不在 erp-health 中，而在 `crates/erp-server/src/middleware/tenant_rls.rs`
|
||
- SSE Token 键名实际一致（auth store 和 message store 都用 `access_token`）
|
||
- 清缓存问题已在 `apps/miniprogram/src/pages/profile/settings/index.tsx` 中修复（preserve-and-restore 模式）
|
||
- 积分系统实际有 6 个 Entity（非 8 个），`points_exchange` 和 `points_sign_record` 不存在
|
||
- EventBus 已有完善基础设施（持久化、幂等去重、filtered subscription、NOTIFY outbox）
|
||
|
||
## 结论
|
||
|
||
**还债策略：三批次串行 — 安全(A) → 事件(B) → 测试(C)**
|
||
|
||
**产出文档：**
|
||
- 设计规格：`docs/superpowers/specs/2026-04-28-technical-debt-cleanup-design.md`
|
||
- 实施计划：`docs/superpowers/plans/2026-04-28-technical-debt-cleanup-plan.md`（14 个 Task / 4 个 Chunk）
|
||
|
||
**核心决策记录：**
|
||
| # | 决策 | 理由 |
|
||
|---|------|------|
|
||
| D1 | PII → 后端加解密 + Blind Index | 前端不接触密钥，安全性最高 |
|
||
| D2 | 积分 → 独立 erp-points crate | 清晰模块边界，可跨业务复用 |
|
||
| D3 | 事件 → vital.critical 最先 | 医疗安全底线，30min 分级升级 |
|
||
| D4 | 测试 → 安全测试驱动 | 与批次 A 联动，修一个写一个 |
|
||
| D5 | 策略 → 按类型分批 | 避免上下文切换，每批有清晰完成标准 |
|
||
|
||
## 待定
|
||
|
||
- 小程序 `secure-storage.ts` 中非 PII 的本地存储加密是否保留
|
||
- `health.checkup.completed` 和 `health.appointment.completed` 事件需在后续迭代中新增
|
||
- 前端路由级 code splitting 的具体组件边界
|