ESLintno-self-compare规则详解：禁止无意义的自身比较
【免费下载链接】eslintFind and fix problems in your JavaScript code.项目地址: https://gitcode.com/GitHub_Trending/es/eslint
导读
no-self-compare是 ESLint 内置的一条「问题类（problem）」规则，用于在代码中检测「变量/表达式与自身进行比较」这类几乎必然是笔误或重构残留的写法。本文以该规则的官方文档为主体，结合本仓库 规则源码、单元测试 与 规则元数据 中的实际实现，完整讲解规则的触发条件、源码实现原理、无选项特性、已知局限与测试覆盖，帮助你准确理解并在项目中正确启用这一规则。
为什么需要禁止「与自身比较」
将变量与自身进行比较，通常是两种错误的产物：
- 笔误（typo）：本意是比较两个不同的变量，却写成了
x === x； - 重构残留：代码重构后变量被重命名或合并，比较双方意外指向同一标识符。
这类代码对读者极具迷惑性——它读起来像是在表达某种判断，实际上恒为真（或恒为假），还可能掩盖真实的逻辑缺陷，甚至引入运行时错误。规则文档明确指出，这是「一种潜在的令人困惑且毫无意义的代码」。
唯一的例外场景是检测NaN：因为NaN不等于任何值（包括它自己），x !== x曾经是判断NaN的惯用写法。但即便如此，ESLint 也强烈建议改用语义更明确的写法：
typeof x === 'number' && isNaN(x)；- 或 ES2015 提供的
Number.isNaN(x)函数。
与其让读者去猜测自比较代码的意图，不如直接使用语义自明的NaN检测手段。
Rule Details：何时触发告警
no-self-compare的官方定义非常直接：只要比较运算符两侧的 token 在结构上完全一致，规则就会报告错误。规则文档给出的错误示例为：
/*eslint no-self-compare: "error"*/ let x = 10; if (x === x) { x = 20; }覆盖的比较运算符
从 规则源码 可以看到，规则监听的是BinaryExpression（二元表达式）节点，并对以下 8 个比较运算符全部生效：
| 运算符 | 语义 | 示例 |
|---|---|---|
=== | 严格相等 | x === x |
== | 宽松相等 | x == x |
!== | 严格不相等 | x !== x |
!= | 宽松不相等 | x != x |
> | 大于 | x > x |
< | 小于 | x < x |
>= | 大于等于 | x >= x |
<= | 小于等于 | x <= x |
单元测试 逐一验证了这 8 种运算符的告警行为，均以comparingToSelf消息 ID 报错。需要特别注意的是，规则不检查instanceof、逻辑运算符或其他非比较型二元运算符。
触发条件与判断算法
规则的判断核心是hasSameTokens(nodeA, nodeB)函数（lib/rules/no-self-compare.js#L41-L53）：
function hasSameTokens(nodeA, nodeB) { const tokensA = sourceCode.getTokens(nodeA); const tokensB = sourceCode.getTokens(nodeB); return ( tokensA.length === tokensB.length && tokensA.every( (token, index) => token.type === tokensB[index].type && token.value === tokensB[index].value, ) ); }其算法要点：
- 分别取出左右两侧表达式对应的全部 token 序列（token 是源码的最小词法单元，如标识符、字面量、运算符等）；
- 先比较两侧 token 数量是否一致；
- 再逐位比较每个 token 的
type（如Identifier、Numeric）与value（如x、10）是否完全相同。
由于比较的是token 序列而非原始源码字符串，因此书写格式的差异（空格、换行等）不会影响判定。测试用例foo.bar().baz.qux >= foo.bar ().baz .qux（tests/lib/rules/no-self-compare.js#L142-L148）正是验证了这一点：即便两侧空格排版完全不同，只要 token 序列一致，仍会被判定为自比较并报错。
类似地，ES2022 的私有字段也支持识别，例如类中this.#field === this.#field会被告警（tests/lib/rules/no-self-compare.js#L150-L157）。
不会触发的情况
测试中还覆盖了若干「合法」场景（tests/lib/rules/no-self-compare.js#L22-L35）：
- 不同变量的比较：
if (x === y) { } - 不同字面量的比较：
if (1 === 2) { } - 乘法等非比较运算：
y = x * x（运算符不在白名单内，且不属于比较语义） - 不同成员访问路径：
foo.bar.baz === foo.bar.qux（两侧 token 不同） - 私有字段与字符串键名的形式差异：
this.#field === this['#field']（token 序列并不相同）
这些用例共同界定了规则的精确判定边界：只关心 token 层面的结构一致性，不关心表达式的运行期求值结果。
Options：无配置项
原文档明确说明：本规则没有任何配置选项（This rule has no options）。这一结论在源码中得到印证——规则的meta.schema为空数组[]（lib/rules/no-self-compare.js#L25），意味着它不接受任何参数，只能以"error"、"warn"或"off"三种级别启用：
// eslint.config.js（扁平配置） export default [ { rules: { "no-self-compare": "error", }, }, ];由于没有选项，使用上只需要决定启用与否，不存在调参空间。
规则元数据速览
根据 docs/src/_data/rules.json#L300-L307 与 规则源码，该规则的元数据如下：
| 元数据字段 | 值 | 说明 |
|---|---|---|
type | problem | 可能引发错误或混乱的「问题类」规则 |
recommended | false | 不在eslint:recommended预设中，需手动启用 |
fixable | false | 不提供自动修复（autofix） |
hasSuggestions | false | 不提供手动应用的建议修复 |
frozen | false | 规则尚未冻结，未来可能演进 |
| 消息 ID | comparingToSelf | 文本为 “Comparing to itself is potentially pointless.” |
正因为它不在eslint:recommended中，且自比较代码比较罕见，你需要在项目配置中显式声明启用才能生效。
Known Limitations：已知局限与误报场景
原文档着重强调了该规则的一个重要局限：它直接比较运算符两侧的 token，如果两侧 token 在结构上完全相同，就会被标记为问题，但规则并不考虑可能的副作用，也不考虑函数即使以相同参数调用也可能返回不同对象。这会导致某些场景下的误报（false positives），典型示例如下：
/*eslint no-self-compare: "error"*/ function parseDate(dateStr) { return new Date(dateStr); } // 两个调用都会创建新的 Date 对象，严格相等恒为 false， // 但两侧 token 完全相同，仍会被规则报告 if (parseDate('December 17, 1995 03:24:00') === parseDate('December 17, 1995 03:24:00')) { // do something } let counter = 0; function incrementUnlessReachedMaximum() { return Math.min(counter += 1, 10); } // 每次调用都有副作用（counter 递增），两次调用结果不同 if (incrementUnlessReachedMaximum() === incrementUnlessReachedMaximum()) { // ... }对第一个例子，两侧都是parseDate('December 17, 1995 03:24:00')这一函数调用表达式——token 完全一致，因此会被规则告警。但实际上每次调用new Date(...)都会产生全新对象，===比较恒为false，这段代码并非「自比较」语义。第二个例子同理：函数内部修改了外部状态，两次调用的返回值并不相同，并非「无意义比较」，而更像潜在的逻辑缺陷，规则无法区分这种语义差异。
这正是 token 级静态分析的固有边界：规则只做词法层面的结构比对，不做数据流分析、不执行代码，因此无法感知副作用与运行期求值结果。了解这一局限，有助于在使用规则时正确解读告警——对于纯函数调用形式的「自比较」，通常确实是代码错误；但对于带副作用或每次返回新对象的调用，需要结合上下文人工判断。
测试验证与消息输出
规则的每条行为都有对应的测试佐证（tests/lib/rules/no-self-compare.js），覆盖维度包括：
- 运算符全量覆盖：
===、==、!==、!=、>,<、>=、<=各至少一条 invalid 用例； - 表达式形态覆盖：简单标识符（
x === x）、字符串字面量（'x' > 'x'）、do...while循环条件（do {} while (x === x)）、顶层表达式语句（x === x）； - 复杂成员链：
foo.bar().baz.qux >= foo.bar ().baz .qux（排版差异不影响判定）； - 语法兼容性：私有字段用例声明了
languageOptions: { ecmaVersion: 2022 }，说明规则与较新的语言特性兼容。
所有 invalid 用例都断言了messageId: "comparingToSelf"，对应源码中定义的消息文本（lib/rules/no-self-compare.js#L27-L29）：
Comparing to itself is potentially pointless.
运行测试命令（在仓库根目录执行）：
npm test -- tests/lib/rules/no-self-compare.js或使用仓库统一的测试脚本按需执行该规则测试文件，即可验证上述全部行为。
实用建议
综合文档、源码与测试，在项目中使用no-self-compare时建议：
- 显式启用：该规则不在
eslint:recommended预设中，需要在 eslint.config.js 或eslintrc中手动声明为"error"（或"warn"）； - 警惕误报边界：当告警出现在函数调用、成员访问等复合表达式两侧时，先确认两侧 token 相同是否真的意味着「同一对象」；对每次返回新对象的函数调用（如
new Date包装、工厂函数），需要人工复核； - 修复方式：多数情况下直接修正笔误、让两侧指向不同的变量即可；若是检测
NaN的意图，请改用Number.isNaN(x)或typeof x === 'number' && isNaN(x)，语义更清晰； - 配合相邻规则：与
no-self-assign（禁止自身赋值）同理，no-self-compare属于「自我指涉」问题族，可将两者一并启用，共同拦截这类重构残留类错误。
总而言之，no-self-compare是一个零配置、低误报率（局限场景集中在带副作用的函数调用）的轻量规则，花最小的成本即可拦截一类真实存在的笔误与重构错误，值得加入你的 ESLint 规则集。
【免费下载链接】eslintFind and fix problems in your JavaScript code.项目地址: https://gitcode.com/GitHub_Trending/es/eslint
创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
