ESLint no-invalid-this 规则详解：在 JavaScript 与 TypeScript 中捕获值为 `undefined` 的 `this`-二趣网

ESLint no-invalid-this 规则详解：在 JavaScript 与 TypeScript 中捕获值为`undefined`的`this`

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

本篇技术指南以 ESLint 官方规则文档 no-invalid-this.md 为核心，结合当前仓库中该规则的完整实现源码与测试用例，系统讲解no-invalid-this规则的设计动机、判定逻辑、全部选项与典型配置。读完本文，你将掌握如何用该规则在严格模式下精准定位指向undefined的this使用，理解其"构造函数/方法/回调"白名单判定机制，并能在 JavaScript 与 TypeScript 工程中正确配置与使用这一规则。

规则简介：为什么要检查`this`

在 JavaScript 中，this的值由函数的调用方式决定，而不是由定义位置决定。在严格模式（strict mode）下，如果一个普通函数被当作独立函数调用（而非作为对象方法、构造函数或通过call/apply/bind显式指定接收者），其内部的this会是undefined——此时访问this.a会直接抛出TypeError，这是运行时最常见的隐性崩溃来源之一。

no-invalid-this规则的作用正是在静态分析阶段标记这类this使用：它旨在标记那些this值为undefined的上下文中的this关键字。该规则在仓库中的元数据声明如下（lib/rules/no-invalid-this.js）：

类型（type）：suggestion（建议类规则，不会直接报运行错误）
适用方言（dialects）：JavaScript、TypeScript
是否推荐（recommended）：false，默认不包含在 eslint:recommended 中
默认选项（defaultOptions）：{ capIsConstructor: true }

该规则自 ESLint 1.0.0-rc-2 起便已存在（见 docs/src/_data/rule_versions.json），是 ESLint 历史最悠久的规则之一。

Rule Details：核心判定规则

本规则的核心逻辑是对"this所在上下文是否为默认绑定（defaultthisbinding）"进行判断。规则的完整实现位于 lib/rules/no-invalid-this.js，其核心判定委托给工具函数isDefaultThisBinding（定义于 lib/rules/utils/ast-utils.js）。

顶层`this`：脚本与模块截然不同

脚本（script）顶层的this永远有效。因为无论是否处于严格模式，脚本顶层this都指向全局对象。
ECMAScript 模块（module）顶层的this永远无效。因为模块顶层this的值恒为undefined。

这一点在源码中有直接体现（lib/rules/no-invalid-this.js）：当代码路径起点是program时，规则根据node.sourceType判定有效性——sourceType === "module"时this无效，脚本模式（或globalReturn且顶层作用域非严格时）则有效。

函数内部的`this`：构造函数 or 方法？

对于函数内部的this，规则基本检查包含该this关键字的函数是否是构造函数或方法。注意：箭头函数具有词法this（lexical this），即箭头函数自身不绑定this，因此规则会检查其外层上下文。源码中通过isCodePathWithLexicalThis（lib/rules/no-invalid-this.js）识别箭头函数产生的代码路径——若代码路径起源于箭头函数，则直接跳过，交给外层代码路径判断。

规则从以下条件判断一个函数是否为构造函数（满足其一即视为构造函数，this有效）：

条件	说明
函数名以大写字母开头	遵循命名约定，如`function Foo()`，对应源码中的`isES5Constructor`（lib/rules/utils/ast-utils.js）
函数被赋值给以大写字母开头的变量	如`const Bar = function() { ... }`（仅对匿名函数生效）
函数是 ES2015 Class 的构造函数	即`class Bar { constructor() { ... } }`

规则从以下条件判断一个函数是否为方法（满足其一即视为方法，this有效）：

条件	说明
函数位于对象字面量上	如`const obj = { foo: function() {...} }`或简写方法`foo() {...}`
函数被赋值给某个属性	如`obj.foo = function() {...}`、`Foo.prototype.foo = function() {...}`
函数是 ES2015 Class 的方法/getter/setter	包括实例方法、静态方法、getter、setter

允许`this`的特殊函数场景

以下场景中，函数虽然形式上可能是普通函数，但规则仍然允许其中使用this：

函数的call/apply/bind方法被直接调用，且传入了非null/undefined的接收者参数。源码中通过bindOrCallOrApplyPattern = /^(?:bind|call|apply)$/u（lib/rules/utils/ast-utils.js）匹配这类调用。
函数是数组方法（如.forEach()）的回调，且提供了thisArg参数。源码中的匹配模式为arrayMethodWithThisArgPattern = /^(?:every|filter|find(?:Last)?(?:Index)?|flatMap|forEach|map|some)$/u（lib/rules/utils/ast-utils.js），覆盖every、filter、find、findLast、findIndex、findLastIndex、flatMap、forEach、map、some等带thisArg的方法。
函数的 JSDoc 注释中包含@this标签。源码通过thisTagPattern = /^[\s*]*@this/mu匹配（lib/rules/utils/ast-utils.js），并且不仅检查函数自身的 JSDoc 注释，还会检查回调函数前的行内注释，例如sinon.test(/* @this sinon.Sandbox */function() { this.spy(); });这种写法（见 hasJSDocThisTag）。

永远允许`this`的上下文

以下上下文中的this规则始终放行：

脚本的顶层（top level of scripts）
类字段初始化器（class field initializers）
类静态块（class static blocks）

源码中，类字段初始化器（PropertyDefinition#value）和StaticBlock被显式视为"非默认绑定"（lib/rules/utils/ast-utils.js），因为字段初始化器与静态块中的this分别指向实例与类本身，永远是有效的。此外，规则还针对AccessorProperty做了专项处理（lib/rules/no-invalid-this.js），保证accessor字段（TypeScript 的 auto-accessor）的取值初始化中this不被误报。

除以上情况外，其余上下文中的this均被视为问题。

严格模式：本规则的生效前提

本规则仅在严格模式下生效。在非严格函数中，this会退化为全局对象，永远不为undefined，因此规则对非严格函数不做检查——源码中可以看到，非严格函数的代码路径在入栈时就直接标记为init: true, valid: true（lib/rules/no-invalid-this.js），即跳过检查。

让代码进入严格模式的常见方式有两种：

在文件或函数顶部添加"use strict";指令；
在 ESLint 配置中将languageOptions.sourceType设为"module"，此时代码隐式处于严格模式（即使没有"use strict"指令）。

因此，如果你在配置中使用了模块模式，规则会自动对全部代码生效，无需额外添加"use strict"指令。

严格模式下的错误示例

以下代码在严格模式下均属于不正确用法（会触发Unexpected 'this'.报告，消息 ID 为unexpectedThis，定义于 lib/rules/no-invalid-this.js）：

/*eslint no-invalid-this: "error"*/ "use strict"; (function() { this.a = 0; baz(() => this); })(); function foo() { this.a = 0; baz(() => this); } const bar = function() { this.a = 0; baz(() => this); }; foo(function() { this.a = 0; baz(() => this); }); const obj = { aaa: function() { return function foo() { // 虽然在方法 `aaa` 内部，但 `foo` 本身不是方法。 this.a = 0; baz(() => this); }; } }; foo.forEach(function() { this.a = 0; baz(() => this); });

其中值得特别注意的是倒数第二个示例：即使函数嵌套在对象方法内部，只要它自身不是方法（这里foo是普通函数声明），其中使用this依然无效——方法与内部嵌套的普通函数在this绑定上是完全不同的。测试用例同样覆盖了这类"方法内嵌套普通函数"的误用场景（见 tests/lib/rules/no-invalid-this.js）。

严格模式下的正确示例

以下代码在严格模式下均属于正确用法：

/*eslint no-invalid-this: "error"*/ "use strict"; this.a = 0; // 顶层 this 指向全局对象 baz(() => this); // 箭头函数具有词法 this function Foo() { // OK，这是传统风格的构造函数。 this.a = 0; baz(() => this); } class Bar { constructor() { // OK，this 位于构造函数中。 this.a = 0; baz(() => this); } } const obj = { foo: function foo() { // OK，这是方法（函数位于对象字面量上）。 this.a = 0; } }; const obj1 = { foo() { // OK，这是方法（简写方法位于对象字面量上）。 this.a = 0; } }; const obj2 = { get foo() { // OK，这是方法（getter 位于对象字面量上）。 return this.a; } }; const obj3 = Object.create(null, { foo: {value: function foo() { // OK，这是方法（函数位于对象字面量的属性描述符中）。 this.a = 0; }} }); Object.defineProperty(obj, "foo", { value: function foo() { // OK，这是方法。 this.a = 0; } }); Object.defineProperties(obj, { foo: {value: function foo() { // OK，这是方法。 this.a = 0; }} }); function Foo() { this.foo = function foo() { // OK，这是方法（函数被赋值给属性）。 this.a = 0; baz(() => this); }; } obj.foo = function foo() { // OK，这是方法（函数被赋值给属性）。 this.a = 0; }; Foo.prototype.foo = function foo() { // OK，这是方法（函数被赋值给原型属性）。 this.a = 0; }; class Baz { // OK，这是类字段初始化器。 a = this.b; // OK，静态字段初始化器中的 this 同样有效。 static a = this.b; foo() { // OK，这是方法。 this.a = 0; baz(() => this); } static foo() { // OK，静态方法中的 this 同样有效。 this.a = 0; baz(() => this); } static { // OK，静态块中的 this 同样有效。 this.a = 0; baz(() => this); } } const bar = (function foo() { // OK，函数的 `bind` 方法被直接调用。 this.a = 0; }).bind(obj); foo.forEach(function() { // OK，`.forEach()` 提供了 `thisArg`。 this.a = 0; baz(() => this); }, thisArg); /** @this Foo */ function foo() { // OK，函数带有 `@this` JSDoc 标签。 this.a = 0; }

Options：配置项详解

本规则接受一个对象选项，包含一个配置项：

capIsConstructor：布尔值，默认true。设为false时，禁用"函数名以大写字母开头即视为构造函数"的假设。

capIsConstructor

默认情况下，规则总是允许以下两类函数中使用this，因为假设它们会被当作构造函数调用：

函数名以大写字母开头的函数（如function Foo()）；
被赋值给以大写字母开头的变量的匿名函数（如const Bar = function() {}）。

如果你希望把这些函数当作普通函数处理，将capIsConstructor设为false即可。其默认值与 schema 定义可以在 lib/rules/no-invalid-this.js（defaultOptions: [{ capIsConstructor: true }]）及 docs/src/_data/rules_meta.json 中确认。

capIsConstructor: false时，以下代码会被判为不正确：

/*eslint no-invalid-this: ["error", { "capIsConstructor": false }]*/ "use strict"; function Foo() { this.a = 0; } const bar = function Foo() { this.a = 0; } const Bar = function() { this.a = 0; }; Baz = function() { this.a = 0; };

而以下代码在capIsConstructor: false时依然是正确的——因为函数被赋值给属性（属于方法）：

/*eslint no-invalid-this: ["error", { "capIsConstructor": false }]*/ "use strict"; obj.Foo = function Foo() { // OK，这是方法。 this.a = 0; };

在源码中，capIsConstructor开关体现在两处判断：isES5Constructor(node)检查（函数名大写，lib/rules/utils/ast-utils.js）以及AssignmentExpression/VariableDeclarator中对"匿名函数被赋值给大写命名变量"的检查（lib/rules/utils/ast-utils.js）。测试用例也专门验证了capIsConstructor: false时function Foo()与var Foo = function(){}均会被报错（见 tests/lib/rules/no-invalid-this.js）。

TypeScript 支持

该规则额外支持 TypeScript 类型语法（规则元数据中的dialects字段声明了JavaScript与TypeScript两种方言，见 docs/src/_data/rules_meta.json）。

不正确的 TypeScript 代码

/*eslint no-invalid-this: "error"*/ function foo(bar: string) { this.prop; console.log(bar) } /** @this Obj */ foo(function() { console.log(this); z(x => console.log(x, this)); }); function foo() { class C { accessor [this.a] = foo; } }

注意第一个示例：普通函数foo中直接使用this.prop会被标记。而accessor [this.a]（auto-accessor 的计算属性名）中的this位于普通函数体内，同样无效——这与类字段初始化器中this有效的规则形成鲜明对比。

正确的 TypeScript 代码

/*eslint no-invalid-this: "error"*/ interface SomeType { prop: string; } function foo(this: SomeType) { this.prop; } class A { a = 5; b = this.a; accessor c = this.a; }

其中值得注意的两点：

this参数（this parameter）：TypeScript 支持在函数参数列表中以this: SomeType的形式显式声明this的类型，规则识别到这种写法后允许函数体内使用this。源码中对应的判断是：函数参数中包含名为this的参数时，直接判定为非默认绑定（lib/rules/utils/ast-utils.js）。
accessor c = this.a：auto-accessor 字段的取值初始化与普通类字段初始化器一样，this指向实例，因此有效。这正是前述AccessorProperty专项处理（lib/rules/no-invalid-this.js）所覆盖的场景。

另外需注意，官方文档元数据中有一条补充说明（见 docs/src/rules/no-invalid-this.md 的 front matter）：TypeScript 自身的类型检查只有在开启了strict或noImplicitThis标志时才会捕获这类问题——这两个标志在大多数 TypeScript 项目中被视为最佳实践而默认开启。

配置示例与实战用法

在 ESLint 配置文件（flat config）中启用该规则的写法：

// eslint.config.js export default [ { languageOptions: { sourceType: "module" // 模块模式隐式开启严格模式，规则自动生效 }, rules: { "no-invalid-this": "error", // 默认选项 capIsConstructor: true "no-invalid-this": ["error", { "capIsConstructor": false }] // 关闭大写命名构造函数的豁免 } } ];

在该规则自身的仓库测试中（tests/lib/rules/no-invalid-this.js），测试框架通过四种辅助函数模拟不同的严格模式来源，与我们上文讨论的生效前提一一对应：

NORMAL：非严格模式（默认，规则不生效）；
USE_STRICT：在代码前插入"use strict";指令；
IMPLIED_STRICT：通过parserOptions.ecmaFeatures.impliedStrict = true隐式开启严格模式；
MODULES：通过languageOptions.sourceType = "module"将代码视为模块（隐式严格）。

例如"脚本顶层this有效、模块顶层this无效"这一结论，正是通过第 107–113 行的用例验证的：同一个代码片段在三种严格模式下均为合法，唯独在MODULES模式下被标记为错误。

When Not To Use It：何时禁用

如果你不希望被提醒"类或类对象之外使用this"这类问题，可以安全地禁用此规则。典型适用场景包括：

项目代码完全不使用严格模式（此时规则本就不生效，开启也无副作用）；
代码风格刻意依赖非严格模式下this指向全局对象的特性；
在迁移严格模式的过渡期，为避免大量历史代码集中报错而临时关闭。

一个实用建议是：将no-invalid-this与严格模式配合使用——既然严格模式已经让非法this变成运行期TypeError，那么在编译期用本规则提前拦截，就是"静态检查先行、运行期兜底"的双保险。

总结

no-invalid-this是 ESLint 中专注于this绑定合法性检查的建议类规则，其核心价值在于：

仅在严格模式下生效，精准针对this === undefined的高危场景；
通过"构造函数 / 方法 / 显式绑定 /thisArg/@this标签"等多重白名单机制，最大程度降低误报；
对脚本顶层、类字段初始化器、类静态块始终放行，对模块顶层始终拦截；
通过capIsConstructor选项灵活控制"大写命名即构造函数"的启发式假设；
完整支持 TypeScript 语法，包括this参数与 auto-accessor 字段。

如果你希望深入源码学习其判定细节，推荐按以下路径阅读：规则入口 lib/rules/no-invalid-this.js → 核心判定工具 lib/rules/utils/ast-utils.js（isDefaultThisBinding）→ 完整测试矩阵 tests/lib/rules/no-invalid-this.js，测试中覆盖了严格模式四种来源、方法嵌套、类静态方法、IIFE 返回值、.bind/.call/.apply、数组thisArg、Reflect.apply、Array.from等大量边界场景，是理解该规则行为的最佳参考。

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

创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考

企业官网建设流程全解析