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参数、推荐解构赋值等
团队落地的关键不是配多少规则，而是怎么用
真正让规范跑起来的不是配置文件本身，而是工具链嵌入开发流程的方式：
立即学习“Java免费学习笔记（深入）”；
- 本地开发：VS Code安装ESLint插件 + 开启“保存时自动修复”
- 提交阶段：
pre-commit钩子调用npx eslint --fix，失败则拒绝提交 - CI流水线：PR合并前执行
npm run lint，不通过则阻断集成 - 新人上手：项目初始化时自带
.eslintrc.js和package.json脚本，开箱即用
