1. ESLint 配置要点
1.1 环境与全局变量管理
在构建 JavaScript 代码规范全攻略 的过程中，环境配置（env）是第一道门槛。通过 env 可以针对浏览器、Node.js、ES2021 等运行环境启用全局变量与全局对象，避免误报与遗漏。正确的设置能让静态分析与实际运行环境保持一致，提升早期发现问题的效率。
常见的实践是同时开启浏览器和 Node 的能力，并将 ES 版本向前或向后兼容。通过 env 配置，你也能让某些全局变量在特定场景下生效，例如 window、document、module、require 等等，从而避免不必要的报错干扰。
// .eslintrc.js 示例
module.exports = {"env": {"browser": true,"node": true,"es2021": true}
};在正式的团队使用中，这一部分通常与 extends 与 plugins 搭配，为后续的规则覆盖提供稳定的基础。
1.2 规则集与扩展
要实现可维护的 JavaScript 代码规范，extends 是核心。它可以把基础规则集、风格指南和第三方工具整合起来，避免重复配置。常见组合包括 eslint:recommended、eslint-config-airbnb-base、以及与 Prettier 的整合。
通过合理的 extends，你可以确保常见的错用、潜在错误得到覆盖，同时让团队有统一的风格。注意 插件 的组合可能带来冲突，因此需要借助 eslint-config-prettier 清理格式冲突。
// .eslintrc.js 示例
module.exports = {"extends": ["eslint:recommended","plugin:prettier/recommended" // 将 Prettier 与 ESLint 结合，避免冲突],"plugins": ["prettier"],"rules": {"no-var": "error","prefer-const": ["error", { "destructuring": "all" }],"eqeqeq": ["error", "smart"]}
};在这一步，rules 的设置决定了项目的严格程度。保持合理的严格性能鼓励良好实践，同时避免在初期造成团队阻力。
1.3 忽略文件与性能优化
面对庞大的代码库，.eslintignore 的配置同样重要。将不需要 lint 的生成产物、依赖包目录等排除在外，可以显著提升 lint 的速度与准确性，避免无意义的检测。
通过合理的忽略策略，性能与 准确性并行提升，确保关键源码始终处于良好的检查之下。
# .eslintignore 示例
node_modules/
dist/
build/2. 自定义规则实战
2.1 自定义插件的基本结构
在 JavaScript 代码规范全攻略 的实践中，团队往往需要覆盖一些公司内部的专用约束。此时自定义规则插件成为提高效率的关键途径。一个基本的插件包含入口文件与若干规则实现，提供可复用的检查逻辑。
自定义插件的核心是 rules 模块，它们以函数形式在 AST 节点上执行业务检查。将规则打包成插件后，通过 plugins 和 rules 就可以在项目中按需开启或禁用。
// eslint-plugin-myutils/index.js
module.exports = {rules: {'no-console-prod': require('./rules/no-console-prod')}
};通过这种结构，可以把“生产环境禁用 console”的逻辑单独抽离成一个规则，降低主配置的复杂度，并便于在不同项目之间复用。
2.2 自定义规则示例：no-console-prod
下面给出一个简单的自定义规则实现示例，用于在生产环境中拒绝使用 console.log。该规则通过检测 CallExpression 的调用对象是否为 console，且环境变量 NODE_ENV 为 production 时触发报错。
// eslint-plugin-myutils/rules/no-console-prod.js
module.exports = {meta: {type: "problem",docs: {description: "Disallow console.log in production",category: "Possible Errors",recommended: true}},create(context) {return {CallExpression(node) {const callee = node.callee;if (callee &&callee.type === 'MemberExpression' &&callee.object &&callee.object.name === 'console' &&callee.property &&callee.property.name === 'log' &&process.env.NODE_ENV === 'production') {context.report({ node, message: "禁止在生产环境使用 console.log" });}}};}
};接着在主配置中启用该规则，使其生效。示例展示了如何通过 plugins 引入本地插件并在 rules 中声明具体的报错等级。
// .eslintrc.js 示例
module.exports = {plugins: ["myutils"],rules: {"myutils/no-console-prod": "error"}
};2.3 测试与发布自定义规则
在正式发布自定义规则前，进行本地测试是不可或缺的环节。通过 eslint 命令可以快速验证规则的行为是否符合预期，确保在不同用例下不会误报或漏报。
测试要点包括：构造包含触发点的测试文件、使用 lint 命令执行并观察报错信息，以及在不同 NODE_ENV 设置下的行为差异。通过自动化测试，可以提升规则的稳定性与可维护性。
# 测试样例
npx eslint test/production-console.js若要将自定义插件对外分发，通常会把插件作为 npm 包发布，或在私有仓库内发布。此时要确保在 package.json 的 peerDependencies 与 exports 配置中对 ESLint 的版本进行约束，避免版本冲突。
// package.json 片段
{"name": "eslint-plugin-myutils","version": "1.0.0","peerDependencies": {"eslint": ">=7.x <=8.x"}
}3. 统一风格与团队协作
3.1 Prettier 与 ESLint 的协同
实现一致的代码风格是 JavaScript 代码规范全攻略 的核心目标之一。将 Prettier 与 ESLint 联合使用，可以在语法正确性与代码风格之间建立清晰的边界，避免重复冲突与多轮修复。
推荐的做法是使用 eslint-config-prettier 解除 ESLint 与 Prettier 间的风格冲突，并通过 plugin:prettier/recommended 一键开启推荐配置。
// .eslintrc.js 示例
module.exports = {extends: ["eslint:recommended","plugin:prettier/recommended"],plugins: ["prettier"],rules: {"prettier/prettier": "error"}
};4. 持续集成中的 ESLint 实践
4.1 在 CI/CD 的集成
将 ESLint 融入持续集成流程，是确保代码规范在长期开发中持续生效的关键步骤。通过在 CI 任务中运行 lint，可以在合并前拦截不符合规范的提交，提升代码质量与团队协作效率。
常见做法包括在 CI 配置中执行 lint 脚本，以及在分支策略中将通过 lint 的结果作为合并条件之一。
name: Linton:- push- pull_requestjobs:lint:runs-on: ubuntu-lateststeps:- uses: actions/checkout@v3- name: Setup Node.jsuses: actions/setup-node@v4with:node-version: '18'- name: Run ESLintrun: npm run lint另一个重要环节是本地脚本的定义，确保团队成员在本地就能快速验证代码是否符合规范。例如，以下 lint 脚本常见于 package.json：
{"scripts": {"lint": "eslint 'src/**/*.{js,jsx}'"}
}通过在工程化环节中持续执行这些规则，可以将 JavaScript 代码规范全攻略 的目标落地到日常开发流程中，保持代码的一致性、可维护性与可读性。
