前端工程规范的五个执行误区工具到位不等于规范落地一、工具链齐全 ≠ 规范执行到位ESLint、Prettier、Husky、lint-staged、commitlint、TypeScript strict mode——一个规范的现代前端项目这些工具几乎成了标配。但工具链齐全和规范真正落地是两回事。在审计过的 15 个前端项目中13 个项目拥有以上全部工具但5 个项目有超过 100 条 ESLint warning 未处理。3 个项目的tsconfig.json中strict: falseTypeScript 沦为带类型注释的 JavaScript。7 个项目的commitlint配置了规则但从未执行过Husky 安装失败后无人修复。2 个项目的 Prettier 与 ESLint 规则冲突每次格式化都互相覆盖。工具是规范落地的必要条件但不是充分条件。以下是在多个团队中观察到的五个执行误区。二、误区一检查配置了但允许跳过最常见的问题是ESLint 的 error 级别规则能强制拦截但 warning 级别的规则日积月累最终被完全无视。// .eslintrc.js —— 典型的只罚酒三杯配置 module.exports { extends: [company/eslint-config], rules: { // 这些规则应该是 error但被设为 warn no-console: warn, // 150 条 warning没人看 typescript-eslint/no-explicit-any: warn, // 46 个 any 畅通无阻 react-hooks/exhaustive-deps: warn, // useEffect 缺少依赖但 warning 无害 typescript-eslint/no-unused-vars: warn, // 76 个未使用变量 }, }; // 统计平均每个中等项目有 200 ESLint warnings // 当 warning 超过 50 条时开发者就会形成warning 不用看的心理模型修复策略// 升级策略要么是 error必须修要么是 off不检查 // 不要有 warn 状态的规则 module.exports { extends: [company/eslint-config], rules: { // 关键规则 → error不允许合并 no-console: error, typescript-eslint/no-explicit-any: error, react-hooks/exhaustive-deps: error, typescript-eslint/no-unused-vars: error, // 不重要的规则 → off不要用 warn 占位置 no-console: [error, { allow: [warn, error] }], // 如果需要 console.log 做调试用 debug 库代替 }, }; // 在 CI 中强制零 warning // package.json { scripts: { lint: eslint . --ext .ts,.tsx --max-warnings 0 } } // --max-warnings 0哪怕 1 个 warning 也让 CI 失败--max-warnings 0是前端工程规范落地的最低价策略。它强制执行要么修、要么关的二元决策消除 warning 的灰色地带。三、误区二TypeScript 严格模式半开半关TypeScript 的strict: true是一个聚合开关它同时开启了 7 个子选项。很多项目只开启了部分子选项核心的strictNullChecks和noImplicitAny被关闭——这几乎让 TypeScript 的类型检查沦为摆设。// 常见的假严格 tsconfig.json { compilerOptions: { strict: false, strictNullChecks: true, // 开了 noImplicitAny: false, // 关了最大的漏洞 noImplicitReturns: false, // 关了 strictFunctionTypes: false, // 关了 skipLibCheck: true // 跳过第三方库检查但可能导致类型不匹配 } }// noImplicitAny: false 的后果 // 以下代码在 TypeScript 中不报任何错误但在运行时会崩溃 function getUser(id) { // 参数 id 隐式为 any return fetch(/api/users/${id}) // id 可以是任何类型 .then(res res.json()) .then(data { return data.name.toUpperCase(); // data 隐式为 any链式调用不检查 }); } async function processOrder(order) { // order 隐式为 any const total order.item.price * order.quantity; // 全部无检查 await submitOrder(order); return total; }修复最小化的严格 TypeScript 配置{ compilerOptions: { strict: true, noUncheckedIndexedAccess: true, noImplicitOverride: true, noPropertyAccessFromIndexSignature: true, noUnusedLocals: true, noUnusedParameters: true, exactOptionalPropertyTypes: true, noFallthroughCasesInSwitch: true } }如果迁移成本太高渐进式策略// 新项目strict: true 全开 // 旧项目分阶段开启 { compilerOptions: { // 第一阶段第 1 周 noImplicitAny: true, strictNullChecks: true, // 第二阶段第 2-3 周 strictFunctionTypes: true, noImplicitReturns: true, // 第三阶段第 4 周 strict: true, // 最终目标直接开启 strict } }四、误区三Husky lint-staged 挂掉后无人修复Husky 依赖 Git hooks但以下情况会导致 hooks 静默失效npm install后没有执行husky installGit hooks 目录未正确设置。团队成员使用git commit --no-verify绕过检查。CI 环境中node_modules被缓存后 Husky 的 hooks 路径失效。# 验证 Husky 是否真的在运行 # 1. 检查 hooks 目录 ls -la .git/hooks/ # 期望看到 pre-commit → ../../.husky/pre-commit # 2. 手动触发 pre-commit .husky/pre-commit # 如果报错或没有运行 lint-staged说明 hooks 失效 # 3. 检查团队成员是否使用了 --no-verify git log --oneline | while read hash msg; do echo $hash $msg done # 无法直接检测历史 commit 是否跳过了 hooks修复策略# .husky/pre-commit —— 防御性脚本 #!/bin/sh . $(dirname $0)/_/husky.sh # 第一步确保 lint-staged 已安装 if ! npx --no-install lint-staged --version /dev/null 21; then echo ⚠ lint-staged 未安装正在安装... npm install fi # 第二步执行 lint-staged npx lint-staged --verbose # 第三步验证 TypeScript npx tsc --noEmit # 如果任何一步失败阻止提交// package.json —— 在 CI 中做同样的检查 { scripts: { prepare: husky install, lint-staged: lint-staged, typecheck: tsc --noEmit, validate: npm run lint npm run typecheck npm run test, pre-commit-validate: npx lint-staged npm run typecheck }, lint-staged: { *.{ts,tsx}: [ eslint --fix --max-warnings 0, prettier --write ], *.{json,md,css,scss}: [ prettier --write ] } }重要在 CI 中重复执行 Husky 相同的检查。不要依赖开发者的本地 Git hooks 作为唯一的防线。CI 是最后一道关卡开发者的本地环境不可控。# .github/workflows/validate.yml name: Validate on: [pull_request] jobs: validate: runs-on: ubuntu-latest steps: - uses: actions/checkoutv4 - uses: actions/setup-nodev4 with: node-version: 20 cache: npm - run: npm ci - run: npm run lint # --max-warnings 0 - run: npm run typecheck # tsc --noEmit - run: npm run test # 单元测试五、误区四Prettier 与 ESLint 的规则冲突Prettier 负责格式化缩进、换行、引号ESLint 负责代码质量未使用变量、错误模式。但很多项目的配置中两者存在重叠规则导致每次保存文件时 ESLint 和 Prettier 互相覆盖。// .eslintrc.js —— 与 Prettier 冲突的配置 module.exports { extends: [ eslint:recommended, // plugin:prettier/recommended 放错位置会导致规则覆盖 ], rules: { // 这些规则与 Prettier 冲突 indent: [error, 2], // Prettier 也控制缩进 quotes: [error, single], // Prettier 也控制引号 semi: [error, always], // Prettier 也控制分号 max-len: [error, 100], // Prettier 有自己的行宽配置 comma-dangle: [error, always-multiline], // Prettier 也控制尾逗号 }, };修复策略// 正确的分工Prettier 管格式ESLint 管质量 // .eslintrc.js module.exports { extends: [ eslint:recommended, plugin:typescript-eslint/recommended, // prettier 必须放在最后关闭所有格式相关规则 prettier, ], plugins: [typescript-eslint], rules: { // 只保留代码质量相关的规则 no-unused-vars: off, typescript-eslint/no-unused-vars: error, typescript-eslint/no-explicit-any: error, // 不要在这里配置缩进、引号、分号等格式规则 }, }; // .prettierrc —— 所有格式配置放在这里 { semi: true, singleQuote: true, tabWidth: 2, trailingComma: all, printWidth: 100, arrowParens: always, endOfLine: lf, bracketSpacing: true } // package.json —— 分工明确的 scripts { scripts: { format: prettier --write ., lint: eslint . --ext .ts,.tsx --max-warnings 0, format:check: prettier --check . } }验证工具链一致性# 运行这个脚本确认 ESLint 和 Prettier 没有冲突 npx eslint-config-prettier src/index.ts # 如果输出 No rules that are unnecessary or conflict with Prettier were found. # 说明配置正确 # 也可以检查配置文件 npx eslint --print-config src/index.ts | npx eslint-config-prettier-check六、误区五规范只有禁止没有指导很多团队的工程规范只关注不能做什么——不能有any、不能有console.log、不能超过 100 行。但缺少应该怎么做的指导——这个组件应该放在哪个目录这个类型应该定义在哪个文件结果是开发者遵守了禁止规则但代码组织仍然混乱。// 好的规范不仅说不能还说应该 // 目录结构规范 const DIRECTORY_RULES { // ✅ 明确的模块边界 src/features/: 按业务领域组织的功能模块每个 feature 自包含, src/components/: 跨 feature 共享的通用组件, src/hooks/: 跨 feature 共享的自定义 Hooks, src/utils/: 纯函数工具不依赖 React/框架, src/types/: 共享类型定义, src/services/: API 调用和数据获取逻辑, // ❌ 禁止事项 src/common/: 禁止使用模糊的 common 目录请使用具体的 feature 名, src/helpers/: 禁止使用 helpers太模糊请使用 utils 或 services, }; // 文件命名规范 // ✅ 正确 // UserProfile.tsx —— 组件PascalCase // useUserData.ts —— Hookuse camelCase // formatCurrency.ts —— 工具函数camelCase // user.service.ts —— 服务camelCase.service // user.types.ts —— 类型camelCase.types // ❌ 错误 // userProfile.tsx —— 组件应该 PascalCase // UserData.ts —— 类型文件应该 .types.ts // helpers.ts —— 太模糊编写规范的模板## [规范名称] ### 动机 为什么要这样规定不遵守会导致什么问题 ### 正确示例 typescript // ✅ 这样写错误示例// ❌ 不要这样写 原因...例外情况什么时候可以打破这个规则需要什么审批## 七、规范落地的衡量指标 不要用有没有配置 ESLint来衡量规范落地程度。用以下可量化的指标 | 指标 | 衡量方法 | 目标值 | |:---|:---|:---| | CI 通过率 | PR 的 lint/typecheck CI 通过比例 | 95% | | Warning 数量 | npx eslint . --format json \| jq [.[].warningCount] \| add | 0 | | any 数量 | grep -r : any src/ \| wc -l | 下降趋势 | | 代码审查耗时 | PR 从创建到合并的平均时长 | 24 小时小 PR | | 规范违规修复时间 | 从 CI 检测到修复提交的时间差 | 2 小时 | bash # 一键检查脚本 #!/bin/bash echo ESLint Warnings WARNINGS$(npx eslint src --ext .ts,.tsx --format json 2/dev/null | jq [.[].warningCount] | add) echo Total warnings: $WARNINGS echo any count ANYS$(grep -r : any src/ --include*.ts --include*.tsx | wc -l | tr -d ) echo Total any usages: $ANYS echo Unused dependencies npx depcheck --quiet echo TypeScript errors npx tsc --noEmit 21 | tail -5 echo Prettier check npx prettier --check src/**/*.{ts,tsx} 21 | tail -3五、总结前端工程规范执行的避坑要点--max-warnings 0是最低价落地策略消除 warning 的灰色地带要么修要么关绝不允许积压超过 50 条的 warning 无人处理。TypeScript strict 不可半开半关noImplicitAny: false让类型检查沦为摆设渐进式开启的最终目标必须是strict: true。CI 是最后一道防线本地 Git hooks 不可控--no-verify可绕过CI 必须重复执行 lint typecheck test 三项检查。Prettier 管格式、ESLint 管质量eslint-config-prettier放在 extends 最后关闭格式冲突不要在 ESLint 中配置缩进/引号。规范要有应该怎么做的指导提供目录结构、命名约定、正确/错误示例只有禁止没有指导的规范让开发者知道不能做什么但不知道该做什么。可执行建议本周做三件事——CI 加入--max-warnings 0、开启strict: true旧项目分阶段、安装eslint-config-prettier消除格式冲突。三项改动半天可完成立即消除规范最大的执行漏洞。八、总结前端工程规范的五个执行误区误区表现修复Warning 积压200 ESLint warning 无人处理--max-warnings 0强制零 warning假严格 TypeScriptstrict: false或子选项未全开strict: true 渐进式开启Husky 失效Git hooks 静默失败无人修复防御性脚本 CI 重复执行ESLint/Prettier 冲突保存时互相覆盖Prettier 管格式, ESLint 管质量只有禁止没有指导开发者不知道应该怎么做提供正确/错误示例 目录结构规范工具到位 ≠ 规范落地。规范落地的三个标志CI 零容忍任何违规都阻止合并不允许灰色地带。团队共识规范是团队一起制定的不是一个人写完后拍给大家遵守的。渐进演进规范不是一成不变的定期回顾和更新建议每季度一次。规范的目的不是约束开发者而是让团队在怎么组织代码这件事上停止争论把精力集中在解决真正的问题上。
前端工程规范的五个执行误区：工具到位不等于规范落地
前端工程规范的五个执行误区工具到位不等于规范落地一、工具链齐全 ≠ 规范执行到位ESLint、Prettier、Husky、lint-staged、commitlint、TypeScript strict mode——一个规范的现代前端项目这些工具几乎成了标配。但工具链齐全和规范真正落地是两回事。在审计过的 15 个前端项目中13 个项目拥有以上全部工具但5 个项目有超过 100 条 ESLint warning 未处理。3 个项目的tsconfig.json中strict: falseTypeScript 沦为带类型注释的 JavaScript。7 个项目的commitlint配置了规则但从未执行过Husky 安装失败后无人修复。2 个项目的 Prettier 与 ESLint 规则冲突每次格式化都互相覆盖。工具是规范落地的必要条件但不是充分条件。以下是在多个团队中观察到的五个执行误区。二、误区一检查配置了但允许跳过最常见的问题是ESLint 的 error 级别规则能强制拦截但 warning 级别的规则日积月累最终被完全无视。// .eslintrc.js —— 典型的只罚酒三杯配置 module.exports { extends: [company/eslint-config], rules: { // 这些规则应该是 error但被设为 warn no-console: warn, // 150 条 warning没人看 typescript-eslint/no-explicit-any: warn, // 46 个 any 畅通无阻 react-hooks/exhaustive-deps: warn, // useEffect 缺少依赖但 warning 无害 typescript-eslint/no-unused-vars: warn, // 76 个未使用变量 }, }; // 统计平均每个中等项目有 200 ESLint warnings // 当 warning 超过 50 条时开发者就会形成warning 不用看的心理模型修复策略// 升级策略要么是 error必须修要么是 off不检查 // 不要有 warn 状态的规则 module.exports { extends: [company/eslint-config], rules: { // 关键规则 → error不允许合并 no-console: error, typescript-eslint/no-explicit-any: error, react-hooks/exhaustive-deps: error, typescript-eslint/no-unused-vars: error, // 不重要的规则 → off不要用 warn 占位置 no-console: [error, { allow: [warn, error] }], // 如果需要 console.log 做调试用 debug 库代替 }, }; // 在 CI 中强制零 warning // package.json { scripts: { lint: eslint . --ext .ts,.tsx --max-warnings 0 } } // --max-warnings 0哪怕 1 个 warning 也让 CI 失败--max-warnings 0是前端工程规范落地的最低价策略。它强制执行要么修、要么关的二元决策消除 warning 的灰色地带。三、误区二TypeScript 严格模式半开半关TypeScript 的strict: true是一个聚合开关它同时开启了 7 个子选项。很多项目只开启了部分子选项核心的strictNullChecks和noImplicitAny被关闭——这几乎让 TypeScript 的类型检查沦为摆设。// 常见的假严格 tsconfig.json { compilerOptions: { strict: false, strictNullChecks: true, // 开了 noImplicitAny: false, // 关了最大的漏洞 noImplicitReturns: false, // 关了 strictFunctionTypes: false, // 关了 skipLibCheck: true // 跳过第三方库检查但可能导致类型不匹配 } }// noImplicitAny: false 的后果 // 以下代码在 TypeScript 中不报任何错误但在运行时会崩溃 function getUser(id) { // 参数 id 隐式为 any return fetch(/api/users/${id}) // id 可以是任何类型 .then(res res.json()) .then(data { return data.name.toUpperCase(); // data 隐式为 any链式调用不检查 }); } async function processOrder(order) { // order 隐式为 any const total order.item.price * order.quantity; // 全部无检查 await submitOrder(order); return total; }修复最小化的严格 TypeScript 配置{ compilerOptions: { strict: true, noUncheckedIndexedAccess: true, noImplicitOverride: true, noPropertyAccessFromIndexSignature: true, noUnusedLocals: true, noUnusedParameters: true, exactOptionalPropertyTypes: true, noFallthroughCasesInSwitch: true } }如果迁移成本太高渐进式策略// 新项目strict: true 全开 // 旧项目分阶段开启 { compilerOptions: { // 第一阶段第 1 周 noImplicitAny: true, strictNullChecks: true, // 第二阶段第 2-3 周 strictFunctionTypes: true, noImplicitReturns: true, // 第三阶段第 4 周 strict: true, // 最终目标直接开启 strict } }四、误区三Husky lint-staged 挂掉后无人修复Husky 依赖 Git hooks但以下情况会导致 hooks 静默失效npm install后没有执行husky installGit hooks 目录未正确设置。团队成员使用git commit --no-verify绕过检查。CI 环境中node_modules被缓存后 Husky 的 hooks 路径失效。# 验证 Husky 是否真的在运行 # 1. 检查 hooks 目录 ls -la .git/hooks/ # 期望看到 pre-commit → ../../.husky/pre-commit # 2. 手动触发 pre-commit .husky/pre-commit # 如果报错或没有运行 lint-staged说明 hooks 失效 # 3. 检查团队成员是否使用了 --no-verify git log --oneline | while read hash msg; do echo $hash $msg done # 无法直接检测历史 commit 是否跳过了 hooks修复策略# .husky/pre-commit —— 防御性脚本 #!/bin/sh . $(dirname $0)/_/husky.sh # 第一步确保 lint-staged 已安装 if ! npx --no-install lint-staged --version /dev/null 21; then echo ⚠ lint-staged 未安装正在安装... npm install fi # 第二步执行 lint-staged npx lint-staged --verbose # 第三步验证 TypeScript npx tsc --noEmit # 如果任何一步失败阻止提交// package.json —— 在 CI 中做同样的检查 { scripts: { prepare: husky install, lint-staged: lint-staged, typecheck: tsc --noEmit, validate: npm run lint npm run typecheck npm run test, pre-commit-validate: npx lint-staged npm run typecheck }, lint-staged: { *.{ts,tsx}: [ eslint --fix --max-warnings 0, prettier --write ], *.{json,md,css,scss}: [ prettier --write ] } }重要在 CI 中重复执行 Husky 相同的检查。不要依赖开发者的本地 Git hooks 作为唯一的防线。CI 是最后一道关卡开发者的本地环境不可控。# .github/workflows/validate.yml name: Validate on: [pull_request] jobs: validate: runs-on: ubuntu-latest steps: - uses: actions/checkoutv4 - uses: actions/setup-nodev4 with: node-version: 20 cache: npm - run: npm ci - run: npm run lint # --max-warnings 0 - run: npm run typecheck # tsc --noEmit - run: npm run test # 单元测试五、误区四Prettier 与 ESLint 的规则冲突Prettier 负责格式化缩进、换行、引号ESLint 负责代码质量未使用变量、错误模式。但很多项目的配置中两者存在重叠规则导致每次保存文件时 ESLint 和 Prettier 互相覆盖。// .eslintrc.js —— 与 Prettier 冲突的配置 module.exports { extends: [ eslint:recommended, // plugin:prettier/recommended 放错位置会导致规则覆盖 ], rules: { // 这些规则与 Prettier 冲突 indent: [error, 2], // Prettier 也控制缩进 quotes: [error, single], // Prettier 也控制引号 semi: [error, always], // Prettier 也控制分号 max-len: [error, 100], // Prettier 有自己的行宽配置 comma-dangle: [error, always-multiline], // Prettier 也控制尾逗号 }, };修复策略// 正确的分工Prettier 管格式ESLint 管质量 // .eslintrc.js module.exports { extends: [ eslint:recommended, plugin:typescript-eslint/recommended, // prettier 必须放在最后关闭所有格式相关规则 prettier, ], plugins: [typescript-eslint], rules: { // 只保留代码质量相关的规则 no-unused-vars: off, typescript-eslint/no-unused-vars: error, typescript-eslint/no-explicit-any: error, // 不要在这里配置缩进、引号、分号等格式规则 }, }; // .prettierrc —— 所有格式配置放在这里 { semi: true, singleQuote: true, tabWidth: 2, trailingComma: all, printWidth: 100, arrowParens: always, endOfLine: lf, bracketSpacing: true } // package.json —— 分工明确的 scripts { scripts: { format: prettier --write ., lint: eslint . --ext .ts,.tsx --max-warnings 0, format:check: prettier --check . } }验证工具链一致性# 运行这个脚本确认 ESLint 和 Prettier 没有冲突 npx eslint-config-prettier src/index.ts # 如果输出 No rules that are unnecessary or conflict with Prettier were found. # 说明配置正确 # 也可以检查配置文件 npx eslint --print-config src/index.ts | npx eslint-config-prettier-check六、误区五规范只有禁止没有指导很多团队的工程规范只关注不能做什么——不能有any、不能有console.log、不能超过 100 行。但缺少应该怎么做的指导——这个组件应该放在哪个目录这个类型应该定义在哪个文件结果是开发者遵守了禁止规则但代码组织仍然混乱。// 好的规范不仅说不能还说应该 // 目录结构规范 const DIRECTORY_RULES { // ✅ 明确的模块边界 src/features/: 按业务领域组织的功能模块每个 feature 自包含, src/components/: 跨 feature 共享的通用组件, src/hooks/: 跨 feature 共享的自定义 Hooks, src/utils/: 纯函数工具不依赖 React/框架, src/types/: 共享类型定义, src/services/: API 调用和数据获取逻辑, // ❌ 禁止事项 src/common/: 禁止使用模糊的 common 目录请使用具体的 feature 名, src/helpers/: 禁止使用 helpers太模糊请使用 utils 或 services, }; // 文件命名规范 // ✅ 正确 // UserProfile.tsx —— 组件PascalCase // useUserData.ts —— Hookuse camelCase // formatCurrency.ts —— 工具函数camelCase // user.service.ts —— 服务camelCase.service // user.types.ts —— 类型camelCase.types // ❌ 错误 // userProfile.tsx —— 组件应该 PascalCase // UserData.ts —— 类型文件应该 .types.ts // helpers.ts —— 太模糊编写规范的模板## [规范名称] ### 动机 为什么要这样规定不遵守会导致什么问题 ### 正确示例 typescript // ✅ 这样写错误示例// ❌ 不要这样写 原因...例外情况什么时候可以打破这个规则需要什么审批## 七、规范落地的衡量指标 不要用有没有配置 ESLint来衡量规范落地程度。用以下可量化的指标 | 指标 | 衡量方法 | 目标值 | |:---|:---|:---| | CI 通过率 | PR 的 lint/typecheck CI 通过比例 | 95% | | Warning 数量 | npx eslint . --format json \| jq [.[].warningCount] \| add | 0 | | any 数量 | grep -r : any src/ \| wc -l | 下降趋势 | | 代码审查耗时 | PR 从创建到合并的平均时长 | 24 小时小 PR | | 规范违规修复时间 | 从 CI 检测到修复提交的时间差 | 2 小时 | bash # 一键检查脚本 #!/bin/bash echo ESLint Warnings WARNINGS$(npx eslint src --ext .ts,.tsx --format json 2/dev/null | jq [.[].warningCount] | add) echo Total warnings: $WARNINGS echo any count ANYS$(grep -r : any src/ --include*.ts --include*.tsx | wc -l | tr -d ) echo Total any usages: $ANYS echo Unused dependencies npx depcheck --quiet echo TypeScript errors npx tsc --noEmit 21 | tail -5 echo Prettier check npx prettier --check src/**/*.{ts,tsx} 21 | tail -3五、总结前端工程规范执行的避坑要点--max-warnings 0是最低价落地策略消除 warning 的灰色地带要么修要么关绝不允许积压超过 50 条的 warning 无人处理。TypeScript strict 不可半开半关noImplicitAny: false让类型检查沦为摆设渐进式开启的最终目标必须是strict: true。CI 是最后一道防线本地 Git hooks 不可控--no-verify可绕过CI 必须重复执行 lint typecheck test 三项检查。Prettier 管格式、ESLint 管质量eslint-config-prettier放在 extends 最后关闭格式冲突不要在 ESLint 中配置缩进/引号。规范要有应该怎么做的指导提供目录结构、命名约定、正确/错误示例只有禁止没有指导的规范让开发者知道不能做什么但不知道该做什么。可执行建议本周做三件事——CI 加入--max-warnings 0、开启strict: true旧项目分阶段、安装eslint-config-prettier消除格式冲突。三项改动半天可完成立即消除规范最大的执行漏洞。八、总结前端工程规范的五个执行误区误区表现修复Warning 积压200 ESLint warning 无人处理--max-warnings 0强制零 warning假严格 TypeScriptstrict: false或子选项未全开strict: true 渐进式开启Husky 失效Git hooks 静默失败无人修复防御性脚本 CI 重复执行ESLint/Prettier 冲突保存时互相覆盖Prettier 管格式, ESLint 管质量只有禁止没有指导开发者不知道应该怎么做提供正确/错误示例 目录结构规范工具到位 ≠ 规范落地。规范落地的三个标志CI 零容忍任何违规都阻止合并不允许灰色地带。团队共识规范是团队一起制定的不是一个人写完后拍给大家遵守的。渐进演进规范不是一成不变的定期回顾和更新建议每季度一次。规范的目的不是约束开发者而是让团队在怎么组织代码这件事上停止争论把精力集中在解决真正的问题上。
