颜海镜的 ESLint 插件教程：用 AST 规则统一 JavaScript 实践
首页内容与阅读入口
首页按年份和月份呈现文章，近期内容涉及自定义 ESLint 插件、函数参数默认值、JavaScript 深层数据、Node.js 与 npm 安装、图片标注工具、异步并发控制和模块化等主题。更早的文章延伸到 TypeScript、React、Git、函数式编程和 JavaScript 库开发。站点还设有作品、JavaScript 简易教程、ES5 合集、存档、分类、页面和标签等入口，读者可以从时间线浏览，也可以按专题或技术关键词继续查找。
这种组织方式适合不同阶段的前端开发者：学习语言基础时可以从简易教程或 ES5 内容入手；遇到工具链问题时，可以用文章标题判断场景是否相近；想理解工程决策时，则可以选择带有背景和实现过程的专题文章。首页列出的内容跨越多年，阅读时也应留意文章日期和所用工具版本，把较早的代码示例放回当前项目环境中核对。
为什么把实践沉淀为 ESLint 规则
自定义 ESLint 插件文章从团队协作中的代码规范问题开始。多个开发者共同维护项目时，最佳实践容易只存在于少数人的经验里；代码审查可以发现部分问题，但它发生在开发之后，也依赖审查者逐行识别。把可机械判断的约定写进检查工具，就能在代码编写过程中给出反馈，让团队更早发现某些重复出现的写法。
文章用 JavaScript 类型判断作为示例背景：typeof 对数组和普通对象都会返回 object，而 instanceof 在一些场景下也有适用边界。项目如果已经沉淀出更合适的工具函数，可以通过 ESLint 自定义规则识别特定表达式，并提示开发者采用一致的实现。规则的作用不是替代全部代码审查，而是把明确、重复、适合自动识别的实践变成持续可执行的约束。
从插件骨架到一条规则
教程先介绍创建插件的准备工作，包括使用 Yeoman 和对应的 ESLint 插件模板生成项目骨架。随后说明规则对象中的元信息：规则类型、文档描述、分类、是否可自动修复、参数 schema 等字段分别帮助工具和使用者理解规则。文章特别提醒，元信息需要与规则真实行为一致；例如只有确实提供修复逻辑时，才应声明自动修复能力。
核心逻辑放在 create 函数中。ESLint 会将 JavaScript 源码解析为抽象语法树，规则通过访问器接收感兴趣的节点。文章示例关注二元表达式：当节点左侧涉及 typeof、比较运算符符合预期、右侧常量为 object 时，就进一步判断表达式是否属于希望提示的情况。这样，规则不是用字符串搜索源码，而是根据语法结构理解代码片段，减少注释、空格或相似文本造成的误判。
把局部判断接到团队工作流
写出规则函数只是插件开发的一部分。要让它在项目中发挥作用，还要把规则放到插件导出结构中，在使用项目里安装和配置插件，并确认代码检查命令能够执行它。教程围绕一个实际规则示例讲解从插件生成、元数据填写、语法节点判断到项目集成的路径，使读者可以把一个具体的代码约定转化为可复用的检查项。
实践时可以先从范围清晰的规则开始：选取团队已有共识、输入输出明确、容易用语法结构判断的模式；为规则提供准确描述和必要的参数定义；再用代表性代码片段确认规则在应提示和不应提示的情况下表现一致。若规则可能改变源码，还需谨慎定义修复逻辑并检查是否会改变原有语义。文章展示了插件的基本组成，具体适用范围仍需要结合项目代码和团队约定决定。
AST 方法带来的思考
抽象语法树把源码表达为节点及其关系。访问器可以关注特定类型的节点，再检查操作符、左右操作数和字面量等结构。与直接查找文本相比，这种方式更接近 JavaScript 语法本身，也便于把检测范围控制在明确的表达式形态。文章展示的判断链说明，写规则时要把“我们想阻止什么”转化为可检查的语法条件，而不是把自然语言规范直接当成代码。
同时，规则越具体，误报和漏报的边界越清楚。一个检查若只覆盖特定表达式，就不应被理解成解决了所有类型判断问题；规则说明、示例和自动修复能力都应限定在实际实现范围内。对于团队而言，插件的收益在于稳定执行已经认可的约定，前提是约定本身清晰，且检查结果不会制造过多无效提示。教程提供了理解这一实现模式的起点。
站点适合怎样使用
正在开发 ESLint 规则的读者，可以沿着文章中的插件脚手架、规则元数据和 AST 访问器逐步阅读，再根据自己的规范替换示例条件。学习 JavaScript 的读者可以通过简易教程、ES5 合集和基础文章梳理语言知识；处理前端项目问题的读者则可以从 Node.js、React、TypeScript、并发控制或模块化等专题中寻找相近背景。
颜海镜的博客把语言知识、工程实践和工具开发放在同一个长期文章库中。它适合作为学习和排查时的参考目录：先从标题或分类定位问题，再结合文章日期、代码上下文和自身依赖版本判断是否适用。遇到团队内部约定时，可以借鉴文章展示的规则设计方式，但最终的规则条件仍应由项目需求定义，并用自己的代码样例验证。