企业官网建设流程全解析

在实际 JavaScript 开发中，箭头函数几乎成了每个项目的默认选择，很多团队甚至会在 ESLint 配置里强制要求const fn = () => {}。但箭头函数真正的作用并不是把function关键字缩短成=>，而是改变了this的解析方式。理解这一点，是彻底解决 JS this 绑定难题的关键；不理解这一点，就会在对象方法、事件回调、类方法、定时器回调等场景里遇到各种莫名其妙的this丢失问题。

这篇文章会围绕“箭头函数为什么能解决 this 绑定问题”和“箭头函数在哪些场景不能乱用”两条主线展开，先讲清楚普通函数的this绑定规则，再解释箭头函数的词法 this 机制，最后给出实际开发中最容易踩的坑、选型判断标准以及排查方法。学完之后，你不仅能在代码里正确使用箭头函数，还能在面试和日常排错中快速判断一个this到底指向哪里。

1. this 到底是什么：先弄清楚绑定规则，再谈箭头函数

很多文章把箭头函数和 this 放在一起讲，但箭头函数解决的只是 this 绑定问题的一部分。要想真正理解箭头函数为什么能“解决”问题，先得知道普通函数的 this 是怎么确定的。

1.1 为什么 this 会成为 JS 初学者的难点

传统的面向对象语言里，this通常指向当前实例，规则比较固定。JavaScript 的this则不同，它不是在函数定义时确定的，而是在函数被调用时确定的。同一个函数，用不同的方式调用，this可能是完全不同的对象。初学者最容易踩的坑，就是把this理解为“函数本身”或者“函数所在的对象”，这两个理解都不准确。

看一个最小示例：

function showThis() { console.log(this); } const obj = { name: 'demo', show: showThis }; showThis(); // 非严格模式：window；严格模式：undefined obj.show(); // obj

同一个showThis，直接调用时this是全局对象；通过obj.show()调用时，this是obj。这说明this由调用方式决定，而不是由函数定义位置决定。

这里的关键是：普通函数的this是“运行时绑定”，和“谁来调用它”强相关。

1.2 四种 this 绑定规则速览

普通函数的this绑定，常用规则归纳为四类：

四条规则并不复杂，复杂的是它们组合出现时的优先级。优先级从低到高是：默认绑定低于隐式绑定，隐式绑定低于显式绑定，显式绑定低于 new 绑定。

function say() { console.log(this.name); } const objA = { name: 'A', say }; const objB = { name: 'B' }; objA.say.call(objB); // B，显式绑定优先于隐式绑定

1.3 绑定规则冲突时怎么判断优先级

判断优先级可以按照下面顺序走一遍：

1. 函数是否通过new调用？如果是，this指向新实例。
2. 是否通过call、apply、bind调用？如果是，this指向显式传入的对象。
3. 是否通过一个对象属性调用，例如obj.fn()？如果是，this指向该对象。
4. 以上都不是，则走默认绑定。严格模式下是undefined，非严格模式下是全局对象。

function identify() { return this.name; } const user = { name: 'user' }; const admin = { name: 'admin', identify }; admin.identify.call(user); // user，显式绑定优先于隐式绑定

注意，bind绑定后无法再被call/apply修改this，因为bind返回的是“已经绑定死 this”的新函数。这一点在使用箭头函数后也会遇到，很多人会把两者混淆，后面会专门说明。

2. 箭头函数的诞生：它改变了 this 的解析方式

理解了普通函数的四条绑定规则，再看箭头函数就容易了。箭头函数刻意绕开了这套动态绑定规则，采用“词法 this”的机制。

2.1 箭头函数的词法 this 是什么意思

词法作用域是根据函数定义的位置决定变量能访问哪些作用域，而不是根据调用位置。箭头函数把这种“看定义位置”的思路搬到了this上：箭头函数没有自己的this，它向外层最近一层普通函数或全局作用域借用this。

换句话说：普通函数问的是“谁在调用我”，箭头函数问的是“我在哪里被定义”。

const obj = { name: 'outer', run: function () { const arrow = () => console.log(this.name); arrow(); } }; obj.run(); // outer

这里arrow是在run函数内部定义的，run被obj.run()调用时this指向obj，arrow没有自己的this，所以沿作用域链取到外层run的this，也就是obj。

箭头函数的this在函数创建时就已经锁定，无论之后怎么调用，都不会改变。这是它与普通函数最本质的区别。

2.2 箭头函数写法演变：从 function 到 =>

箭头函数在语法上经历了从 ES5 回调写法到 ES6 简洁写法的变化。先看一个最典型的回调场景：

// ES5 写法 [1, 2, 3].map(function (item) { return item * 2; }); // ES6 箭头函数完整写法 [1, 2, 3].map((item) => { return item * 2; }); // 单表达式省略 return [1, 2, 3].map((item) => item * 2); // 单参数省略括号 [1, 2, 3].map(item => item * 2);

写法的简化是有取舍的：

• 单参数可以省略括号，多参数或零参数必须加括号。
• 函数体只有单个表达式时，可以省略大括号和return，返回该表达式的值。
• 如果函数体是对象字面量，需要用括号包裹，例如() => ({ name: 'x' })，否则大括号会被解析成代码块。

const getConfig = () => ({ env: 'development' }); console.log(getConfig()); // { env: 'development' }

这里最容易写错的是省略return时返回一个对象，不加括号会得到undefined，因为{}被当成了函数体代码块。

2.3 箭头函数与普通函数的核心差异对比表

这段差异是箭头函数的完整边界。很多人只记住了“箭头函数没有自己的 this”，却忽略了 arguments、构造函数、generator 这些限制。实际开发中，正是因为这些限制，箭头函数并非所有场景都适合。

3. 箭头函数真正的边界：能做什么，不能做什么

箭头函数不是普通函数的语法糖。它是一种行为不同的函数，必须在理解边界的前提下使用。

3.1 不能作为构造函数，没有 prototype

箭头函数没有[[Construct]]内部方法，所以不能使用new调用。

const Person = (name) => { this.name = name; }; // TypeError: Person is not a constructor // const p = new Person('tom');

为什么设计成这样？因为箭头函数的this是词法绑定，它自己都没有this，自然没办法在新对象实例上绑定属性。另外箭头函数也没有prototype属性，这一点会让依赖prototype的旧式封装失效。

const fn = () => {}; console.log(fn.prototype); // undefined

如果确实需要创建构造函数，必须使用普通函数或 class 语法。

3.2 没有 arguments 对象，用剩余参数代替

普通函数内置arguments对象，它是一个类数组对象，包含调用时传入的所有参数。箭头函数没有自己的arguments，如果在箭头函数内部直接写arguments，实际上访问的是外层作用域的arguments。

function outer() { const inner = () => { console.log(arguments[0]); // 来自 outer 的 arguments }; inner(); } outer('outer-arg'); // outer-arg

当需要收集箭头函数自身的参数时，推荐使用剩余参数语法：

const sum = (...args) => args.reduce((total, current) => total + current, 0); console.log(sum(1, 2, 3)); // 6

剩余参数返回的是真正的数组，可以调用map、filter、reduce等方法，这一点比arguments更好用。平时写工具函数时，优先使用剩余参数而不是arguments。

3.3 没有自己的 super、new.target

箭头函数不仅没有自己的this，也没有自己的super和new.target。super在箭头函数中会透传到外层函数；new.target在箭头函数中也会引用外层函数的new.target。

这些限制在类继承和元编程场景里非常重要。比如在构造函数内部使用箭头函数来定义方法时：

class Example { constructor() { this.data = []; } add = (item) => { this.data.push(item); }; }

这里的add是箭头函数，它的this来自实例化时外层类构造函数的this，本质上是类字段初始化时捕获了实例。这种“实例方法自动绑定”的写法在 React 类组件中很常见，但要注意它和普通原型方法的存储位置不同。箭头函数字段是实例自身属性，普通方法在原型上，内存占用有差异。

3.4 不能用作 generator 函数

generator 函数需要用function*表示，箭头函数不支持*语法，所以不能把箭头函数作为 generator 使用。

// 不合法 // const gen =* () => { yield 1; };

如果业务里要写生成器，必须回到普通函数：

function* counter() { let i = 0; while (i < 3) { yield i++; } }

箭头函数简化了普通函数的很多细节，但这种简化是有代价的：凡是依赖运行时动态this、可构造、有独立arguments、需要生成器的场景，箭头函数都不能替代普通函数。

4. 用箭头函数重构 this 绑定的经典场景

箭头函数最大的价值，是让回调函数里的this自动继承外层作用域，避免手写var self = this或bind(this)。

4.1 场景一：setTimeout 和事件回调中的 this 丢失

看一个最常见的 this 丢失问题：

const counter = { count: 0, start: function () { setTimeout(function () { console.log(this.count); // undefined }, 100); } }; counter.start();

这里setTimeout中的普通函数由定时器回调调用，this不再指向counter，所以this.count是undefined。传统解决方法有三种：

// 方法一：保存外层 this const counterA = { count: 0, start: function () { const self = this; setTimeout(function () { console.log(self.count); }, 100); } }; // 方法二：bind 显式绑定 const counterB = { count: 0, start: function () { setTimeout(function () { console.log(this.count); }.bind(this), 100); } }; // 方法三：箭头函数，最简洁 const counterC = { count: 0, start: function () { setTimeout(() => { console.log(this.count); }, 100); } };

第三种写法之所以能工作，是因为setTimeout回调内部的箭头函数没有自己的this，它沿定义位置向上找到start函数的this，而start是counterC.start()调用的，所以this指向counterC。

4.2 场景二：数组方法回调里使用箭头函数

数组的map、filter、forEach等方法非常依赖回调函数。箭头函数让回调更简洁，同时避免了使用内部this时可能出现的指向错误。

const team = { members: ['alice', 'bob'], listWithPrefix: function (prefix) { return this.members.map(member => `${prefix}: ${member}`); } }; console.log(team.listWithPrefix('dev')); // ['dev: alice', 'dev: bob']

如果把这个回调写成普通函数：

listWithPrefix: function (prefix) { return this.members.map(function (member) { return `${prefix}: ${member}`; }); }

不涉及this时普通函数也能用。差别在于：

• 箭头函数自动绑定外层this，代码更短。
• 普通函数如果想要内部this指向外层，需要额外bind(this)或使用self变量。
• 箭头函数体为单表达式时，自动返回结果，适合map、filter这类纯回调。

4.3 场景三：对象方法中该不该用箭头函数

这个问题有很多争议。先说结论：普通对象方法最好不用箭头函数，除非你明确知道对象方法内部的this需要继承外层。

const obj = { name: 'object', show: function () { return this.name; } }; console.log(obj.show()); // object

一旦改成箭头函数：

const obj2 = { name: 'object', show: () => { return this.name; } }; console.log(obj2.show()); // undefined 或全局变量

原因是obj2.show被定义时，箭头函数捕获的是外层作用域（这里可能是全局作用域或模块作用域）的this，而不是obj2。即使通过obj2.show()调用，this也不会指向obj2。

所以在对象字面量中定义方法，应使用方法简写或普通函数：

const obj3 = { name: 'object', show() { return this.name; } };

方法简写和箭头函数看起来都短，但语义完全不同。方法简写的this仍遵循普通函数的动态绑定规则，调用者决定this。

4.4 场景四：类方法绑定 this 的三种方式对比

在类中定义方法，主流有三种方式处理回调和事件中的this：

class Toggle { constructor(text) { this.text = text; this.isOn = false; } // 方式一：普通原型方法，使用 bind 绑定 handleClickBind() { this.isOn = !this.isOn; console.log(this.text, this.isOn); } // 方式二：箭头函数类字段，定义时捕获实例 this handleClickArrow = () => { this.isOn = !this.isOn; console.log(this.text, this.isOn); }; // 方式三：内部手动 bind constructorBind() { this.handleClickBind = this.handleClickBind.bind(this); } }

三种方式对比：

实际项目中，如果不是极端性能场景，箭头函数字段的可读性最好。但要注意：箭头函数字段不是标准 ES6 class 原生语法，它依赖类字段提案，在部分旧环境需要 Babel 转译。

5. 实际开发中箭头函数最容易踩的坑

箭头函数虽然好用，但坑也不少。把高频问题集中梳理出来，方便排查。

5.1 坑 1：在对象方法里用箭头函数导致 this 指向错误

现象：对象方法里用了箭头函数，调用obj.method()后this不是obj，方法内部读不到对象属性。

原因：箭头函数在对象字面量定义时捕获外层作用域的this，而不是调用者。

检查方式：在方法内部打印this，如果输出window或模块上下文，说明被箭头函数词法绑定影响了。

处理方式：改成方法简写或普通函数。如果确实需要箭头函数的简洁性，可以把方法改为闭包返回箭头函数的写法：

function makeCounter() { let count = 0; return { increase: () => { count++; return count; } }; }

这种情况下箭头函数捕获的是闭包变量，而不是对象this，语义更清晰。

5.2 坑 2：箭头函数配合 call / apply / bind 无效

现象：对箭头函数执行fn.call(obj)，this没有变成obj。

原因：箭头函数没有自己的this，显式绑定无法覆盖词法绑定的值。

const getName = () => this.name; const user = { name: 'user' }; console.log(getName.call(user)); // undefined，而不是 user

这个特性不是 bug，而是设计。排查时不要试图通过bind修改箭头函数的this，要修改就修改外层作用域里真正提供this的函数。

推荐做法：需要动态this的地方用普通函数，需要词法this的地方用箭头函数，两者不要混用。

5.3 坑 3：箭头函数递归调用困难

现象：用箭头函数写递归时，函数体内无法直接引用函数名，因为箭头函数作为表达式通常没有名字。

const factorial = (n) => n <= 1 ? 1 : n * factorial(n - 1); console.log(factorial(5)); // 120

这个例子在const factorial声明完成后调用是可以工作的，因为箭头函数体内引用的factorial会沿作用域链找到外部变量。但这里隐藏一个风险：箭头函数体内的自引用依赖外部变量，一旦这个变量被重新赋值，函数就会崩。比如：

const factorial = (n) => n <= 1 ? 1 : n * factorial(n - 1); const copy = factorial; factorial = null; console.log(copy(5)); // TypeError: factorial is not a function

所以真正需要稳定递归时，推荐使用命名函数表达式：

const factorial = function fact(n) { return n <= 1 ? 1 : n * fact(n - 1); }; console.log(factorial(5)); // 120

命名函数表达式的函数名fact只在函数内部可访问，不受外部赋值影响，语义更可靠。

5.4 坑 4：动态绑定事件中箭头函数导致无法解绑

现象：给按钮绑定箭头函数后，想通过removeEventListener解绑，发现必须保存函数引用，否则解绑不干净。

原因：removeEventListener需要传入与绑定完全相同的函数引用。如果直接在绑定处写箭头函数，后续拿不到该引用。

// 错误思路：直接传入匿名箭头函数，解绑时无法引用 // button.addEventListener('click', () => { console.log('click'); }); // button.removeEventListener('click', ???);

推荐做法：先定义好函数，再绑定和解绑：

const handler = () => { console.log('click'); }; button.addEventListener('click', handler); button.removeEventListener('click', handler);

如果是普通函数，可以在处理函数内部用this判断是否需要解绑；箭头函数无法这样做，所以事件解绑场景要提前设计好函数引用。

5.5 坑 5：箭头函数让 this 变为静态后调试更困难

现象：打印this时，箭头函数里的this总是指向外层对象，很难通过临时修改调用方式来看出函数自身状态。

原因：词法 this 让 this 不再跟随调用点变化，这在调试时减少了一个自由度。

排查建议：在箭头函数内部不要依赖this做复杂逻辑，如果逻辑复杂，显式把需要的对象作为参数传入，或者使用普通函数并在调用处绑定。

6. 什么时候用箭头函数，什么时候别用：选型决策

把所有规则简化成一张决策表，按需选择。

6.1 推荐使用箭头函数的场景

• 回调函数里需要继承外层this，例如setTimeout、事件监听、Promise 链、数组遍历回调。
• 纯函数式操作，返回计算结果，不依赖动态this。
• 需要给一个函数绑定固定上下文，且不打算通过call/bind修改。
• 使用柯里化或高阶函数时，精简回调写法。

const fetchUser = (id) => fetch(`/api/user/${id}`).then((res) => res.json());

这里fetchUser和.then的回调都不需要自己的this，箭头函数非常合适。

6.2 必须使用普通函数的场景

• 构造函数或需要new的函数。
• 对象字面量方法，且方法内部需要使用对象自身this。
• 需要动态改变this的函数，例如公共工具函数。
• 需要arguments对象或作为 generator 的函数。
• 事件监听中需要动态解绑或用到事件回调内部this的场景。

const service = { baseURL: '/api', request(path) { // 这里必须使用普通函数，this 指向 service return fetch(this.baseURL + path); } };

6.3 团队规范的场景判断

如果把箭头函数和普通函数的选型落到团队规范，建议按这个顺序判断：

1. 这个函数会不会被new？会，用普通函数。
2. 这个函数的this是否需要跟随调用者？需要，用普通函数或方法简写。
3. 这个函数是否需要自身的arguments？需要，用普通函数或剩余参数。
4. 这个函数是否是一个纯回调，希望继承外层的this？是，用箭头函数。
5. 只是想让代码更短，没有其他需求？用箭头函数，但要先确认没有踩到边界。

生产项目里还需要考虑转译和浏览器兼容性。箭头函数是 ES6 语法，大多数现代浏览器都支持，但低版本浏览器需要 Babel 或 TypeScript 编译。如果你的项目还在兼容旧环境，箭头函数需要转译，同时注意转译后的this语义是否有差异。

注意：不要只看代码能否运行，还要看转译后的目标环境是否真的支持箭头函数。部分老旧运行环境对 ES6 的类字段支持也不一样，落地前先确认目标浏览器列表。

7. 从面试到实战：this 绑定排查工具与练习路径

前面介绍了规则和场景，这一部分给出可复用的排查方法和练习建议。

7.1 一个可以自测的 this 绑定题集

下面五道题覆盖了核心规则，建议自己先判断输出，再运行验证。

// 第 1 题 const obj1 = { name: 'obj1', say: function () { console.log(this.name); } }; obj1.say(); // 第 2 题 const obj2 = { name: 'obj2', say: () => { console.log(this.name); } }; obj2.say(); // 第 3 题 const obj3 = { name: 'obj3', say: function () { return () => console.log(this.name); } }; obj3.say()(); // 第 4 题 const obj4 = { name: 'obj4', say: function () { const inner = function () { console.log(this.name); }; return inner; } }; obj4.say()(); // 第 5 题 const obj5 = { name: 'obj5', say: function () { const inner = function () { console.log(this.name); }.bind(this); return inner; } }; obj5.say()();

参考答案：

这里的第 2 题最容易有争议，因为对象方法是箭头函数，很多人以为this会指向对象，实际不会。

7.2 排查 this 方向性问题的三步法

实际项目里遇到this不对时，按下面三步走：

第一步：确认函数是普通函数还是箭头函数。

• 箭头函数：直接找到定义位置的最近一层普通函数，看这个普通函数在被调用时this指向哪里。
• 普通函数：继续执行第二步。

第二步：找到这个普通函数的调用方式。

• 是new Fn()？
• 是fn.call(obj)、fn.apply(obj)、fn.bind(obj)？
• 是obj.fn()？
• 还是直接fn()？

按四个绑定规则的优先级确定this。

第三步：观察代码是否在严格模式。

在模块或 class 内部通常默认严格模式，直接调用普通函数时this是undefined，而不是全局对象。如果打印出undefined，先排除严格模式因素。

7.3 学习环境与生产环境注意点

学习阶段，建议用 Node.js 或浏览器控制台反复运行上面的示例。把this的每一次输出都打印出来，观察不同调用方式下的差异。这是最有效的训练方式。

开发阶段，建议在 ESLint 中开启相关规则：

• no-invalid-this：检查非法 this 使用。
• prefer-arrow-callback：推荐在回调中使用箭头函数。
• arrow-body-style：统一箭头函数体风格。

配置示例：

{ "rules": { "no-invalid-this": "error", "prefer-arrow-callback": "warn", "arrow-body-style": ["error", "as-needed"] } }

生产阶段，除了功能正确，还要关注：

• 箭头函数字段在类中的兼容性，低版本浏览器是否被正确转译。
• 大量实例化对象时，箭头函数字段每个实例都会创建新函数，内存占用比原型方法高，需要评估是否值得。
• 内存泄漏场景：如果箭头函数被保存在全局事件处理器或定时器里，需要确保能正确解绑，避免持有不再使用的对象。

8. 用一张检查清单收尾：写箭头函数前快速自检

把实践要点整理成一份可复用的检查清单，写代码的时候逐项过一遍。

技术选型没有绝对正确，核心是理解两种函数的 this 机制差别。普通函数是运行时动态绑定，箭头函数是定义时词法绑定。把这句本质记住了，再结合本文的规则、场景和排查路径，JS this 绑定难题就从“玄学”变成了“可推理的问题”。

下一步建议找一份包含事件绑定、异步请求、类组件的真实项目，把其中所有var self = this和bind(this)的代码重构成箭头函数，再故意把几个对象方法改成箭头函数观察报错，这种对照实验比单纯看语法教程更能巩固理解。