17370845950

JavaScript代码规范是团队约定的非语法强制性写作习惯，ESLint通过AST静态分析、错误分级、保存即修复和提交前拦截统一风格，而Prettier仅负责排版，ESLint还覆盖语义检查与逻辑风险识别。

JavaScript中的代码规范是一套关于如何写代码的约定，涵盖缩进、分号、引号、命名、空格、括号位置、变量声明方式等细节。它不是语法强制要求，而是团队为提升可读性、可维护性和协作效率共同遵守的“写作习惯”。比如：用const优先代替var、字符串统一用单引号、if后必须有空格、函数参数间加逗号空格等。

ESLint为什么能统一团队代码风格

ESLint不是靠说服或文档，而是通过静态分析把规范变成可执行的规则：

• 解析成AST检查：把源码转为抽象语法树，逐节点比对是否符合配置规则（如indent检查缩进、quotes检查引号类型），不依赖运行时，编辑器里就能实时提示
• 错误分级明确：规则可设为off（关闭）、warn（警告）、error（报错中断），团队可根据严格程度灵活控制
• 保存即修复：配合VS Code ESLint插件或编辑器自动保存格式化，开发者敲完代码、保存瞬间就完成风格修正，无需手动调整
• 提交前拦截：结合lint-staged和husky，在git commit前自动跑检查，不合规范的代码根本进不了仓库

只靠Prettier不行，为什么还要ESLint

Prettier专注“怎么排版好看”，比如换行、缩进、括号位置；但它不管代码有没有潜在问题。ESLint则能发现更深层的问题：

• 语义级检查：未定义变量、重复声明、console.log残留、debugger语句、eval调用等
• 逻辑风险识别：永远为真的条件判断、无用的return、循环中异步等待缺失等
• 最佳实践引导：强制使用===而非==、禁止修改function参数、推荐解构赋值等

团队落地的关键不是配多少规则，而是怎么用

真正让规范跑起来的不是配置文件本身，而是工具链嵌入开发流程的方式：

• 本地开发：VS Code安装ESLint插件 + 开启“保存时自动修复”
• 提交阶段：pre-commit钩子调用npx eslint --fix，失败则拒绝提交
• CI流水线：PR合并前执行npm run lint，不通过则阻断集成
• 新人上手：项目初始化时自带.eslintrc.js和package.json脚本，开箱即用