修复建议写法
修复建议的价值在于可执行：读者拿到建议后应该知道改哪里、怎么改、怎么验证。结构上分两层，一层是临时缓解，用于尽快降低风险；另一层是根治方案，解决产生问题的设计缺陷，并附验证方法。表述上要指明组件与具体位置，例如哪个服务、哪个接口、哪个配置文件；原则上给出原理性方案，用伪代码或配置示意说明，不绑定某个商业产品，避免引发实施阻力。
基本信息
| 结构 | 临时缓解、根治方案与验证方法三层 |
|---|---|
| 定位要求 | 指明文件、服务或接口的具体位置 |
| 表述方式 | 原理性伪代码或配置示意，便于迁移 |
| 复核要求 | 与客户实际技术栈匹配后再定稿 |
典型使用场景
- 逻辑类缺陷：给出校验应加在服务端哪一层
- 权限类问题：说明按会话用户强制归属校验的位置
- 配置类问题：给出需要调整的配置项与目标值
- 架构类问题：给出多种方案对比与各自代价
- 整改复核：附上可执行的验证步骤供对方自查
建议示例
建议示例
根治：订单查询接口按会话用户强制执行归属校验
逻辑示意：if order.owner_id != session.user_id: 返回 403
临时：在网关对订单接口前缀增加归属校验层 # 先止损
验证：两个账号交叉请求，均返回 403 且响应无数据
说明：不确定客户架构时，给出网关拦截与应用层校验两种方案
供客户按改造代价选择两类建议对比
| 类型 | 目标 | 适用时机 |
|---|---|---|
| 临时缓解 | 快速降低风险，改动小 | 修复排期前的止血措施 |
| 根治方案 | 消除成因，长期有效 | 纳入版本迭代正式修复 |
| 验证方法 | 确认修复有效 | 每次修复后与复测时使用 |
建议要与客户技术栈匹配：写清原理与位置，避免绑定具体产品，便于对方按既有架构落地。