前端项目多层流水线操作

目标： 利用编辑器插件实现“无感知”的规范约束。

Prettier & ESLint:
- 操作： 配置 .vscode/settings.json，开启 editor.formatOnSave 和 editor.codeActionsOnSave。
- 效果： 开发者按下 Ctrl+S 时，代码自动格式化并修复简单的 Lint 错误。
React-Scan:
- 操作： 在开发环境 (process.env.NODE_ENV === 'development') 引入。
- 时机： 当你感觉页面卡顿，或者完成一个复杂组件开发后，主动观察渲染次数。不要把它集成到自动化测试中（除非你做高阶的 E2E 性能监控）。
Orval:
- 操作： 配置 package.json 脚本 "gen:api": "orval"。
- 时机： 当后端通知 Swagger/OpenAPI 文档更新时，手动运行一次，然后将生成的代码提交到 Git。
- 建议：不要在 CI 中运行 Orval，因为如果后端服务不可用，会导致你的前端发布失败。

目标： 阻止“脏代码”进入暂存区，但必须快（毫秒级或秒级）。

我们利用 Husky 触发钩子：

pre-commit (Lint-staged):
- 配置重点： 只跑 eslint --fix 和 prettier --write，千万不要跑全量 tsc (类型检查)。
- 原因： 随着项目变大，全量类型检查可能需要 10-30 秒甚至更久，这会严重破坏提交体验。
- 配置示例 (package.json):
```
 "lint-staged": {
   "*.{js,jsx,ts,tsx}": [
     "prettier --write",
     "eslint --fix" // 这一步通常不包含耗时的 type-check
   ]
 }
```
commit-msg (Commitlint):
- 操作： 检查提交信息是否符合 feat:, fix: 等规范。
- 速度： 极快，几乎无感知。

目标： 进行全量检查。这是代码合并到主分支前的最后一道防线。

当开发者发起 Pull Request (PR) 或推送到远程分支时执行。

流水线任务列表 (并行执行以节省时间):

Install: pnpm install --frozen-lockfile (利用 pnpm 的缓存和确定性)。
Lint (全量): pnpm eslint . (检查所有文件，防止 lint-staged 漏网之鱼)。
Type Check (全量): pnpm tsc --noEmit。
- 注意： 这是进行类型检查的最佳位置。如果 CI 报错，禁止合并。
Knip (瘦身检查): pnpm knip。
- 策略： 初期可以将 Knip 设置为 CI 的“警告”级别（允许失败但报错），或者只在 PR 中运行。如果设置为严格报错，可能会因为误报阻碍紧急发布。建议作为独立的一个 Job 运行。
Build: pnpm build。确保代码能正常打包。

探索