使用 ESLint `no-eq-null` 规则：杜绝无类型检查的 `null` 比较

使用 ESLintno-eq-null规则：杜绝无类型检查的null比较

【免费下载链接】eslintFind and fix problems in your JavaScript code.项目地址: https://gitcode.com/GitHub_Trending/es/eslint

在 JavaScript 中，foo == null这类比较看似无害，却会因抽象相等比较算法的隐式类型转换而同时匹配undefined，带来难以察觉的运行时 Bug。本文基于 ESLint 仓库中的规则文档 no-eq-null 规则说明 及其 源码实现 与 测试用例，系统讲解该规则的设计动机、触发条件、配置方式、底层实现原理，以及与 eqeqeq 规则的协同关系。读完本文，你将掌握如何在 ESLint 中启用该规则、理解其工作原理，并能结合团队规范做出合理的开启/关闭决策。

为什么== null是个隐患：隐式类型转换

JavaScript 的==（宽松相等）运算符遵循 ECMAScript 规范中的抽象相等比较算法（Abstract Equality Comparison Algorithm），在比较前会对操作数进行隐式类型转换。其中最容易踩坑的一条是：

null == undefined的结果为true。

这意味着，当你写下if (foo == null)并期望“仅在foo确实为null时进入分支”时，实际行为却是“foo为null或undefined时都进入分支”。很多情况下这并非开发者本意——例如函数参数未传入时值为undefined，此时foo == null会被错误地判定为真。

eslint 规则文档 no-eq-null.md 开篇即点明了这一核心问题：

在没有类型检查运算符（==或!=）的情况下与null比较可能产生意外结果，因为该比较不仅匹配null，还会匹配undefined，从而计算为true。

与===（严格相等）相比，严格相等运算符不会进行类型转换，null === undefined恒为false，因此只有foo === null才能精确表达“仅为null”的语义。

规则细节：no-eq-null究竟检查什么

no-eq-null规则的目标是：确保与null的比较只匹配null，而不误伤undefined。因此，凡是使用宽松运算符==或!=与null字面量进行的比较，都会被该规则标记为错误。

规则类型为suggestion（建议类，通常指示代码中可能存在的坏味道或潜在风险），且不在 ESLint 的recommended推荐配置中（recommended: false），这一点在规则源码 lib/rules/no-eq-null.js 的meta定义以及 rules_meta.json 中均有明确记录。需要单独显式启用。

错误的代码（会被规则标记）

规则文档 no-eq-null.md 中给出的错误示例：

/*eslint no-eq-null: "error"*/ if (foo == null) { bar(); } while (qux != null) { baz(); }

上述两处分别使用了== null与!= null，都会同时把undefined纳入（或排除在）匹配范围之外，是该规则要拦截的对象。

正确的代码（不会被规则标记）

改用严格相等运算符后的正确写法：

/*eslint no-eq-null: "error"*/ if (foo === null) { bar(); } while (qux !== null) { baz(); }

源码级解析：规则是如何实现的

规则的完整实现非常精炼，位于 lib/rules/no-eq-null.js，核心逻辑只有 20 余行：

create(context) { return { BinaryExpression(node) { const badOperator = node.operator === "==" || node.operator === "!="; if ( (node.right.type === "Literal" && node.right.raw === "null" && badOperator) || (node.left.type === "Literal" && node.left.raw === "null" && badOperator) ) { context.report({ node, messageId: "unexpected" }); } }, }; },

从源码结构可以拆解出其工作原理：

1. 监听BinaryExpression节点：规则注册了一个BinaryExpression访问器，凡是形如A == B、A != B的二元表达式都会进入检查逻辑。
2. 判断宽松运算符：badOperator仅在运算符为==或!=时为真，===、!==以及其他二元运算符（如+、<）不会被触及。
3. 定位null字面量：分别检查右操作数（node.right）和左操作数（node.left），要求其 AST 节点类型为Literal且raw原始文本恰为字符串"null"。这里用raw而非value判断，是为了精确匹配源代码中字面书写的null关键字（null的raw和value都是null的表示，但通过raw可避免与"null"字符串字面量等形态混淆）。
4. 报告问题：一旦满足“宽松运算符 + 一侧为null字面量”的条件，即调用context.report，并引用meta.messages中定义的unexpected消息——“Use '===' to compare with null.”（建议改用===与null比较）。

值得注意的细节是，该规则同时覆盖操作数位于左侧的情况（如null == x）。判断逻辑对左右两侧都做了检查，因此不论null写在等号左边还是右边，都会被一致地拦截。

规则的元数据与注册方式

• 规则通过 lib/rules/index.js 中的"no-eq-null": () => require("./no-eq-null")以惰性加载方式注册，只有实际启用该规则时才会加载其模块，避免无谓的开销。
• 规则没有配置选项，其schema为空数组（schema: []），因此无法传入任何参数，详见 lib/rules/no-eq-null.js。
• 该规则从 ESLint 早期版本（0.0.9）就已存在，见 rule_versions.json，属于历史悠久的经典规则之一。

测试用例如何验证规则行为

仓库中的测试文件 tests/lib/rules/no-eq-null.js 使用 ESLint 自带的RuleTester框架对规则进行了全面验证：

合法（valid）用例——严格相等比较不会触发规则：

valid: ["if (x === null) { }", "if (null === f()) { }"]

注意第二个用例null === f()是null在左侧的严格比较，同样被视为合法。

非法（invalid）用例——宽松比较全部被标记：

invalid: [ { code: "if (x == null) { }", errors: [{ messageId: "unexpected", line: 1, column: 5, endLine: 1, endColumn: 14 }], }, { code: "if (x != null) { }", errors: [{ messageId: "unexpected", line: 1, column: 5, endLine: 1, endColumn: 14 }], }, { code: "do {} while (null == x)", errors: [{ messageId: "unexpected", line: 1, column: 14, endLine: 1, endColumn: 23 }], }, ]

从断言信息可以进一步确认两个实现细节：其一，错误消息通过messageId: "unexpected"关联，与源码中的meta.messages一一对应；其二，报告的错误位置覆盖整个比较表达式（如x == null从第 5 列到第 14 列），方便在编辑器与命令行输出中精准定位问题代码。

如何启用与配置该规则

该规则没有可配置选项，配置时只需要指定严重级别即可。在 ESLint 9+ 的扁平配置（flat config）中，于eslint.config.js内添加：

export default [ { rules: { "no-eq-null": "error", }, }, ];

在旧版.eslintrc风格的配置中，则写入：

{ "rules": { "no-eq-null": "error" } }

若希望以警告级别（"warn"）而非错误级别（"error"）提示，可相应调整严重级别。

需要注意的是，由于该规则不在recommended推荐集中（见 rules_meta.json），仅靠eslint:recommended配置不会启用它。不过，如果使用 ESLint 的eslint:all配置（即启用全部规则），该规则会被一并开启并设为"error"，这一点可以从 packages/js/src/configs/eslint-all.js 中的"no-eq-null": "error"得到印证。eslint:all仅适合作为探索全部规则的调试手段，不建议在真实项目中直接使用。

与eqeqeq规则的协同：更精细的null策略

规则文档在“何时不使用”一节明确指出：如果你希望总体上强制类型检查运算，应使用功能更强大的 eqeqeq 规则。两条规则都被归类为suggestion类型，且no-eq-null在 frontmatter 中将eqeqeq声明为关联规则（related_rules）。

eqeqeq的能力远超no-eq-null：它默认（"always"模式）要求所有比较一律使用===/!==，同时通过第二个参数对象中的null属性提供细粒度控制：

• null: "always"（默认）——与null比较也强制使用===/!==；
• null: "never"——允许==/!=与null比较（即显式容忍null == undefined的语义，常用于刻意同时匹配null与undefined的场景）；
• null: "ignore"——不对null比较应用eqeqeq规则。

典型组合示例：

/*eslint eqeqeq: ["error", "always", {"null": "never"}]*/ if (foo == null) { // 允许：eqeqeq 的 null:never 放行 bar(); }

因此，从规则定位上看：no-eq-null是专门针对null宽松比较的“单点”规则，而eqeqeq是覆盖全部相等比较的“全局”规则。如果项目已有eqeqeq且配置为"always"（默认null: "always"），则no-eq-null覆盖的场景已被其完全包含；反过来，如果项目希望严格禁止所有==/!=，则直接使用eqeqeq更为合适。

何时不使用该规则

规则文档 no-eq-null.md 给出了明确的停用建议：

• 如果你希望全面强制类型检查运算：应改用更强大的 eqeqeq（配置"always"），此时no-eq-null的功能是其子集；
• 如果你有意识地利用== null同时匹配null与undefined的语义：例如某些框架代码中value == null被当作“值为空”的惯用检查（这是 JavaScript 社区中一种被接受的模式，因为undefined与null常被视为等价“空值”），则不应启用本规则，或改用eqeqeq的null: "never"显式放行此类比较；
• 如果你的团队对相等运算符的使用有明确、统一的风格约定：可以在代码规范中自行约束，规则仅作为自动化兜底手段。

兼容性说明

根据规则文档 no-eq-null.md 的 Compatibility 部分，该规则对应 JSHint 中的eqnull规则。这意味着从 JSHint 迁移到 ESLint 的团队，可以直接用no-eq-null无缝替换原有的eqnull检查，行为语义基本一致：均用于禁止无类型检查的null比较。

小结

no-eq-null是 ESLint 中一个目标单一、实现轻量的建议类规则：

维度	说明
规则类型	suggestion，非recommended，需显式启用
检查对象	==/!=与null字面量的比较（左右两侧均覆盖）
配置选项	无（schema: []）
默认消息	"Use '===' to compare with null."
首次出现版本	0.0.9（见 rule_versions.json）
关联规则	eqeqeq
JSHint 对应	eqnull

其实现要点在于通过BinaryExpression访问器识别宽松运算符，并以Literal+raw === "null"精确匹配null字面量，配合 tests/lib/rules/no-eq-null.js 中的完整用例验证了左右操作数位置、==/!=两种运算符的覆盖情况。对于追求精确语义、不希望null比较误伤undefined的代码库，启用该规则（或直接使用更全面的eqeqeq）是低成本的健壮性保障；而对于依赖== null惯用写法的项目，则应在明确团队共识的前提下选择性地放行。

【免费下载链接】eslintFind and fix problems in your JavaScript code.项目地址: https://gitcode.com/GitHub_Trending/es/eslint