公司去年底来了两个后端同事，项目里的前端部分也要他们一起改。问得最多的问题是「这个要不要配」「那个是不是必须做」，我就把平时跟他们口头说的整理成了这份清单。清单本身没什么新鲜东西，网上到处都是，我觉得它有用的地方在于把「哪些可以先不做」也标了出来——对我们这种两三个人的内部项目，不做什么比做什么更重要。

一、这几项我认为必做

  • TypeScript 的 strict: true。新建项目直接开，别想着以后再开。老项目想开的话，建议先只开 noImplicitAny，把报出来的错清完再一步步往上加。noUncheckedIndexedAccess 我开了两次又关了两次，它让 arr[0] 的类型变成 T | undefined，写起来确实啰嗦，内部项目里我没坚持下来。
  • ESLint。现在用的是 ESLint 9 的 flat config，配置文件叫 eslint.config.js，老的 .eslintrc 已经不推荐了。规则集我直接用官方推荐的，只额外关掉了两条跟我们代码风格冲突的。类型相关的规则要配合 typescript-eslint，光装 ESLint 不装它是查不出类型问题的。
  • CI 里跑 tsc --noEmit 和 npm run build。这一条比前面两条都重要，因为前面两条靠自觉，这一条是机器卡着。我们的流水线里这两步一共不到三分钟，成本可以接受。
  • 锁文件进仓库，CI 用 npm ci 而不是 npm install。npm ci 会严格按 package-lock.json 装，装之前先删 node_modules，能挡掉一部分「我这儿是好的」。
  • .env.example 要提交，把需要的变量名写全，值留空或写成示例。新人拉下项目不知道要配哪些环境变量，是我见到最高频的卡点。

二、这几项我们暂时没做

  • 单元测试覆盖率门槛。我们只对几个纯函数（金额计算、日期解析）写了测试，没设覆盖率要求。两个人维护的内部系统，我觉得把覆盖率当 KPI 意义不大。这一条争议很大，只是我们的做法。
  • monorepo / pnpm workspace。就两个前端项目，各自一个仓库反而清楚。
  • 自己封装组件库。试过，维护成本超过收益，后来退回「复制粘贴 + 需要时再抽」。
  • 微前端。没有任何一个场景需要我们这么做。
  • 复杂的类型体操。能读出意思就行，我见过为了类型完美把业务代码写得没人看得懂的。

顺便说一句，上面这些「没做」不代表它们不好，只是成本收益在当前规模下不划算。哪天团队变成十个人，结论大概率要改。

三、commit 规范

我们用的是 Conventional Commits 的简化版，只允许这几种前缀：

feat: 新增导出按钮
fix: 修复筛选条件清空后列表不刷新
chore: 升级 vite 到 6.0.7
docs: 补充部署说明
refactor: 拆分工单详情的 composable

好处主要是回头看 git log 的时候能一眼找到东西，另外出事的时候好定位是哪次改动引入的。格式本身不重要，重要的是统一。

还有一条我自己执行的规矩：一次提交只做一件事。把「改个 bug 顺手格式化了整个文件」拆成两次提交，review 的人（通常是我自己几天后）会轻松很多。

注意

提交前的 husky + lint-staged 我们配了，但只跑 ESLint，没跑完整的类型检查——后者在这个项目上要十几秒，卡在提交这一步大家会想办法绕过。类型检查交给 CI。

四、一句提醒

清单是死的。我自己的经验是，加一条规则之前先问一句「它挡住过什么真实发生的问题」，如果答不上来，就先别加。这条标准让我删掉了不少当初觉得很有必要、其实从没起过作用的约定。

（2026-07 补充：上面提到的 ESLint 9 flat config，我到现在还是没完全搞清 files 匹配和 ignores 的优先级，遇到不生效的时候基本靠试。这点如果有更清楚的讲法，欢迎写信告诉我。）