JavaScript代码规范核心是提升可读性、可维护性与协作效率，依赖ESLint（逻辑质量）与Prettier（样式格式）协同，配合husky、lint-staged、CI等流程卡点及轻量团队约定，实现自动化、可持续的风格统一。
JavaScript 代码规范是一套约定俗成或团队强制的编写规则，核心目标是提升可读性、可维护性和协作效率。风格统一不靠自觉，而靠工具链 + 明确约定 + 持续执行。
用 ESLint + Prettier 做自动检查和格式化
这是目前最主流、最落地的方案。ESLint 负责逻辑和质量规则（比如禁止 var、要求 return 语句、检测未使用变量），Prettier 负责代码样式（缩进、分号、引号、换行等）。两者配合，各司其职：
- 在项目中安装
eslint、prettier和插件（如eslint-config-prettier关闭与 Prettier 冲突的规则） - 配置
.eslintrc.js（定义规则）和.prettierrc（定义格式） - 把 ESLint 集成到编辑器（如 VS Code 的 ESLint 插件），保存时自动修复可修复项
- 在
package.json中加脚本："lint": "eslint src/"和"format": "prettier --write src/**/*.{js,jsx,ts,tsx}"
制定轻量但关键的团队约定
不必事无巨细，聚焦高频引发分歧的点。例如：
- 使用
const优先，仅在重新赋值时用let，禁用var - 函数名用小驼峰（
handleClick），组件名首字母大写（ModalHeader） - 字符串统一用单引号，除非内容里有大量单引号
- 对象/数组字面量的最后一个元素后加逗号（
trailingComma: "es5"） - 箭头函数体单表达式不写花括号（
x => x * 2），多语句必须写
把规范“嵌入”开发流程
靠人提醒不如靠机制卡点：
立即学习“Java免费学习笔记（深入）”；
- Git 提交前用
husky+lint-staged自动检查暂存区文件，不通过则拒绝提交 - CI 流水线（如 GitHub Actions）中加入
npm run lint步骤，PR 合并前必须通过 - 新成员入职时提供配置好的模板仓库，或一键初始化脚本，避免从零配环境
定期回顾与渐进改进
规范不是一成不变的法律。每季度快速过一遍 ESLint 报警最多的几条规则，看是误报、需调整，还是团队确实没适应。新增规则尽量设为 warn 级别起步，给过渡时间；重大变更（如切换模块语法）提前同步，留出升级窗口。
基本上就这些。工具搭好、关键点对齐、流程卡住、小步迭代——代码风格一致这件事，不复杂但容易忽略执行细节。
