git status 显示 clean 不代表冲突解决完成，仅说明无未暂存文件和冲突标记，但逻辑正确性、功能完整性和环境一致性仍需分层验证与人工上下文对齐。
git status 显示 clean 就代表冲突解决完了吗
不是。git status 显示 nothing to commit, working tree clean 只说明所有冲突标记已被删除、所有文件都已 git add，但完全不保证逻辑正确或功能完整。常见错误是删掉冲突标记后随手一提交，结果上线发现登录态失效、API 返回结构错乱——因为改的那几行代码本该合并逻辑，你却只留了左边或右边的版本。
验证必须分层推进：
- 语法层面：运行
npm run build或make，确保没报Unexpected token、undefined is not a function这类硬错误 - 接口层面：用
curl或 Postman 快速调一个刚改过的 endpoint，看 HTTP 状态码和 body 是否符合预期 - 逻辑层面：重点检查冲突区域上下文——比如你解决了
user.js里权限判断那段冲突，就得手动测“管理员+普通用户+未登录”三种状态是否都走对了分支
自动化测试跑过就等于没问题？
不一定。很多项目测试覆盖率低，或者冲突恰好发生在测试用例没覆盖的边界路径上（例如空数组处理、超长字符串截断、第三方 SDK 回调时序）。更危险的是：测试本身可能依赖被你删掉的旧字段或旧函数。
实操建议：
- 先查冲突文件名，再查这些文件在测试目录里有没有对应
*.test.js或spec.rb—— 如果没有，立刻补一个最小用例 - 运行
npm test -- --testPathPattern=user（或对应模块名），而不是无差别跑全量测试，省时间也聚焦风险区 - 如果项目有 E2E 测试，至少跑一次关键路径（如登录 → 进首页 → 提交表单），别只信单元测试
为什么本地编译+测试都过了，CI 还是失败？
典型原因是环境差异。你本地用 Node.js v18，CI 用 v20；你本地数据库是 SQLite，CI 跑的是 PostgreSQL；甚至只是 .env 文件里某个开关值没同步。
快速定位方法：
- 看 CI 报错的第一行：如果是
ReferenceError: process is not defined，大概率是构建配置漏了 polyfill - 对比 CI 和本地的
git diff HEAD~1 -- package-lock.json，确认依赖版本一致 - 在 CI 日志里搜
conflict或你修改的文件名，看是不是有其他地方（比如 Dockerfile、webpack.config.js）也引用了同一段逻辑，但没同步更新
最常被跳过的验证动作：人工走查冲突块上下文
Git 只标出冲突行，但从不告诉你“为什么这里会冲突”。你删掉 和 <code>>>>>>>> 很容易，但未必理解同事 A 为什么加了 if (user?.role === 'admin')，而同事 B 为什么改成 if (hasPermission('manage_users'))。
务必打开原始提交：
- 用
git log -p -n 5 -- path/to/conflicted/file.js看最近几次修改动机 - 去 Git 服务器（GitHub/GitLab）点开两个冲突分支的 diff，读对方 commit message 里的 “why”，不只是 “what”
- 如果涉及业务规则变更（比如价格计算逻辑），直接找相关人语音对齐，别靠猜
冲突解决不是终点，而是协作意图对齐的起点。跳过上下文验证，等于把技术债打包进主干。
