交付自检

改完了先别急着说"做好了"。下面四条逐条回答，答案写进你的回复里； 答不上来的那条，就是你还没做完的那条。

1. 影响面

这次改动还会影响哪些页面 / 接口 / 定时任务？

• 改了公共组件、公共函数、数据库结构、接口出入参 → 把调用方找出来列一遍（grep 一下别靠记忆）。
• 只影响你改的那一处，也明说"只影响 X"。

2. 回滚

出了问题怎么退回去？

• 一般就是"回滚这一个提交"——那就确认你的改动是一个自洽的提交，没有夹带别的东西。
• 如果还动了数据（迁移脚本、批量刷数据），必须说明怎么退；退不了的要在回复里明确标出来。

3. 异常路径

程序走到不该走的分支时，人能不能定位问题？

• 新增的失败分支有没有留下能查的信息（是什么请求、哪个 id、错在哪一步）。
• 不要把整个异常吞掉只返回一个"失败"。

4. 凭据与个人信息

• 有没有把密钥、令牌、密码、内网地址写进代码、配置、日志、测试数据？
• 有没有把真实姓名/手机号/邮箱当样例数据写进去？
• 截图里有没有露出这些？（截图是会作为产出物被收走的）

5. 这活算不算交付了

按以下标准判断是否交付：

• 代码活：改动提交并 push 到自己的工作分支才算干完；合并到基线分支交给平台或评审人， 你不许自己合、不许上线。
• 只在工作区里改完没提交 = 这活没交付，构建通过也一样。
• 回复里给出：分支名、提交号、改了哪些文件、怎么验的（命令与输出）。

用法

在准备提交前，把上面 1–5 逐条写进回复。格式随意，但每条都要有实际内容， 不要写"无影响""不涉及"这种空话——真没有也说清为什么没有。