接入代码规范与 Git Hooks

本阶段目标

把代码风格和基础质量要求变成快速、可重复的自动化反馈。编辑器、提交钩子和 CI 应调用同一组项目脚本，避免三套配置逐渐漂移。

建立命令契约

在 package.json 提供稳定入口：

{
  "scripts": {
    "format": "prettier --write .",
    "format:check": "prettier --check .",
    "lint": "eslint .",
    "typecheck": "vue-tsc --noEmit",
    "check": "pnpm format:check && pnpm lint && pnpm typecheck"
  }
}

具体规则可以调整，但脚本职责要稳定：格式化工具只负责排版，Lint 负责静态语义问题，TypeScript 负责类型契约。

提交前反馈

使用 Git Hook 和 lint-staged 只检查暂存文件，使正常提交保持快速。Hook 不是安全边界，开发者可以跳过它，所以完整检查仍必须在 CI 重跑。

建议为生成文件、构建产物、快照和第三方代码维护统一 ignore 规则，避免每个工具扫描不同范围。

规则引入顺序

1. 先启用能自动修复且争议小的格式规则。
2. 再启用能发现真实缺陷的正确性规则。
3. 对需要类型信息的规则单独评估耗时。
4. 旧项目采用基线或分目录迁移，不要一次制造数千条无人处理的告警。

故障演练

1. 制造一个格式错误、一个未处理 Promise 和一个类型错误，确认分别由正确工具报告。
2. 使用 --no-verify 跳过本地 Hook，确认 CI 仍会阻止问题进入主线。
3. 故意让编辑器和 CLI 使用不同 Prettier 版本，观察格式往返变化，再固定项目版本。

验收标准

• pnpm check 在本地和 CI 使用相同配置
• 正常的提交前检查在合理时间内完成
• 每类失败都包含文件、位置和可执行修复建议
• 跳过 Hook 不会绕过服务端质量门禁
• 规则变更与业务改动分开提交，便于评审和回滚

下一篇：建立单元测试与端到端测试。