企业官网建设流程全解析

1. 从一段真实代码说起：为什么你的this又丢了

先看一段我上周帮同事排查的代码，场景很典型：一个对象里定义了计时器，回调里想访问对象自身的属性，结果打印出来是undefined。

const counter = { count: 0, start() { setInterval(function () { this.count++; console.log(this.count); }, 1000); } }; counter.start(); // NaN，因为 this 指向了全局或 undefined

这段代码跑起来，this.count不是NaN就是报错，取决于运行环境。同事的第一反应是"我明明在对象方法里写的，this 怎么会丢"。问题就出在setInterval接收的是一个普通函数，普通函数的this在调用时才确定，而定时器回调执行时，调用者已经不是counter了。

改成箭头函数，一行就解决：

const counter = { count: 0, start() { setInterval(() => { this.count++; console.log(this.count); }, 1000); } }; counter.start(); // 1 2 3 4 ...

这就是箭头函数最核心的价值：它没有自己的 this，它的 this 继承自外层作用域，在定义时就已经确定，之后永远不会变。这一条规则，能解释你遇到的 90% 以上的箭头函数 this 问题。

但事情没这么简单。我见过太多人把箭头函数当成"万能 this 修复器"，结果在对象方法、原型方法、事件监听里乱用，反而制造了新的 bug。这篇内容就把箭头函数 this 的来龙去脉、适用边界、常见误区和排查方法一次讲透，不管你是刚学 JS 的新手，还是写了几年代码偶尔还会被 this 绕晕的老手，都能从中找到能直接用的结论。

2. 普通函数的this到底是怎么"丢"的

要搞懂箭头函数，必须先搞懂普通函数的 this 规则。很多人对 this 的困惑，本质上是没搞清楚"this 到底由谁决定"。

2.1 this的绑定发生在调用时刻，而不是定义时刻

这是理解一切 this 问题的总纲。普通函数的 this 是动态的，它取决于函数被怎么调用，而不是被在哪里定义。

function showThis() { console.log(this); } const obj = { name: 'A', showThis }; const other = { name: 'B', showThis }; obj.showThis(); // { name: 'A', showThis } other.showThis(); // { name: 'B', showThis } showThis(); // 全局对象或 undefined

同一个函数，三种调用方式，三个不同的 this。函数体一个字没改，this 却变了。这就是"动态绑定"的含义。

2.2 四条绑定规则，按优先级从高到低

普通函数的 this 绑定可以归纳为四条规则，判断时按优先级从高到低套用：

用一个例子串起来：

function foo() { console.log(this.tag); } const o1 = { tag: 'o1', foo }; const o2 = { tag: 'o2' }; o1.foo(); // 'o1'，隐式绑定 o2.foo = o1.foo; o2.foo(); // 'o2'，隐式绑定，看调用者 o1.foo.call({ tag: 'x' }); // 'x'，显式绑定 new o1.foo(); // undefined，new 绑定，this 是新对象

2.3 隐式绑定丢失的经典场景

隐式绑定最容易出问题的地方，是函数被"传递"出去之后。看这个：

const user = { name: 'Tom', greet() { console.log(this.name); } }; const g = user.greet; g(); // undefined，this 丢了

user.greet被赋值给g之后，调用g()时它已经不再是user的方法了，走的是默认绑定。这就是所谓的"隐式丢失"。定时器回调、事件回调、数组方法回调里 this 丢失，本质都是这个原因——函数被当作参数传出去，调用者变了。

理解了这一点，你就明白箭头函数为什么能"救场"：它根本不参与这套动态绑定游戏。

3. 箭头函数的this：定义时锁定，永不改变

箭头函数的 this 规则只有一句话：箭头函数没有自己的 this，它内部的 this 就是定义它时外层作用域的 this。这句话展开讲，有几个关键点必须吃透。

3.1 词法作用域决定this，跟调用方式无关

普通函数看"谁调用我"，箭头函数看"我在哪定义"。这是两者最本质的区别。

const obj = { name: 'outer', arrow: () => { console.log(this.name); }, normal() { console.log(this.name); } }; obj.arrow(); // undefined（外层是全局，全局没有 name） obj.normal(); // 'outer'

obj.arrow()虽然看起来是 obj 的方法，但箭头函数的 this 在定义时就锁死为全局作用域的 this，跟 obj 一点关系都没有。这就是为什么箭头函数不适合做对象方法。

3.2 call、apply、bind对箭头函数完全无效

这是很多人不知道的细节。因为箭头函数的 this 已经锁死，你用什么方式调用都改不了它。

const arrow = () => { console.log(this); }; const obj = { name: 'test' }; arrow.call(obj); // 还是外层 this，不是 obj arrow.apply(obj); // 同上 const bound = arrow.bind(obj); bound(); // 同上，bind 也无效

实测下来，这三个方法对箭头函数的 this 没有任何影响。它们能传参数，但改不了 this。所以如果你需要动态切换 this，箭头函数直接排除。

3.3 多层嵌套时，this往上找最近的非箭头函数

箭头函数的 this 是"向外层找"，如果外层还是箭头函数，就继续往外找，直到找到最近的一个普通函数或全局作用域。

const obj = { name: 'layer', method() { const a = () => { const b = () => { console.log(this.name); // 'layer' }; b(); }; a(); } }; obj.method();

这里b的 this 往外找，a也是箭头函数，继续往外，找到method这个普通函数，它的 this 是 obj。所以最终打印'layer'。这个"逐层向外找"的机制，是理解嵌套箭头函数的关键。

3.4 一个容易踩的坑：对象字面量里的箭头函数

const obj = { name: 'oops', arrow: () => this.name };

这里的箭头函数外层是全局作用域（对象字面量不构成作用域），所以 this 不是 obj。很多人以为写在对象里 this 就是对象，这是最大的误解之一。记住：只有函数才能形成 this 的作用域边界，对象字面量不行。

4. 什么时候该用箭头函数，什么时候坚决别用

知道了原理，接下来是实战判断。我总结了一套简单的决策标准，基本能覆盖日常开发。

4.1 优先用箭头函数的三种场景

第一种：回调函数里需要访问外层 this。

class Timer { constructor() { this.seconds = 0; } start() { setInterval(() => { this.seconds++; }, 1000); } }

这是箭头函数最经典的用法。回调里要访问实例的 this，用箭头函数最干净，不用写const self = this那种老套路。

第二种：数组方法链式调用。

const result = list .filter(item => item.active) .map(item => item.name) .reduce((acc, cur) => acc + cur, '');

这种短小的纯函数，箭头函数写起来简洁，而且不涉及 this，完全没问题。

第三种：需要固定 this 的场景，比如防抖节流封装。

function debounce(fn, delay) { let timer = null; return (...args) => { clearTimeout(timer); timer = setTimeout(() => fn.apply(this, args), delay); }; }

这里用箭头函数保证返回的函数 this 跟外层一致，逻辑更清晰。

4.2 坚决不用箭头函数的四种场景

第一种：对象的方法。

// 错误示范 const obj = { name: 'x', getName: () => this.name // this 不是 obj }; // 正确写法 const obj = { name: 'x', getName() { return this.name; } };

第二种：原型方法。

// 错误 Foo.prototype.bar = () => { console.log(this); // 不是实例 }; // 正确 Foo.prototype.bar = function () { console.log(this); // 实例 };

第三种：需要动态 this 的场景，比如事件处理里要用this指向触发元素。

// 如果这里用箭头函数，this 不是被点击的元素 button.addEventListener('click', function () { this.classList.toggle('active'); });

第四种：构造函数。箭头函数没有prototype，也不能被new，直接报错。

const Person = (name) => { this.name = name; // 报错：Person is not a constructor };

4.3 一张决策表帮你快速判断

5. 排查this问题的完整思路链路

遇到 this 相关的 bug，别急着乱改，按下面的链路一步步排查，基本都能定位。

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

这是分岔路口。如果是箭头函数，this 在定义时就定了，往定义处的外层找；如果是普通函数，看调用方式。

// 先看定义 const fn1 = () => {}; // 箭头，this 看外层 function fn2() {} // 普通，this 看调用 const fn3 = function () {}; // 普通，this 看调用

5.2 第二步：普通函数就找"谁调用了它"

在调用处打断点，看调用栈。重点看函数名前面有没有对象，有没有用 call/apply/bind，有没有 new。

obj.fn(); // 隐式，this = obj fn(); // 默认，this = undefined/全局 fn.call(x); // 显式，this = x new fn(); // new，this = 新实例

5.3 第三步：箭头函数就往上找最近的非箭头函数

从箭头函数定义的位置开始，一层层往外看，找到第一个普通函数或全局作用域，那个 this 就是答案。

function outer() { // 这里的 this 就是下面箭头函数的 this const inner = () => { console.log(this); }; inner(); } outer.call({ tag: 'found' }); // { tag: 'found' }

5.4 第四步：用最小复现验证你的判断

把可疑代码抽出来，单独跑一遍，打印 this。这一步能快速证伪你的猜测。

function test() { console.log('this is:', this); } test(); // 看默认绑定 test.call({ a: 1 }); // 看显式绑定

5.5 一个真实排查案例

之前有个同事写了个类，方法里用了箭头函数，结果 this 指向了模块顶层。

class Widget { constructor() { this.name = 'widget'; } render = () => { console.log(this.name); // 这里没问题，class field 箭头函数 this 是实例 }; badRender() { const inner = () => { console.log(this.name); // 这里也没问题，this 是实例 }; inner(); } }

但如果是这样：

const config = { name: 'config', handler: () => { console.log(this.name); // undefined，外层是模块作用域 } };

问题就出在对象字面量里的箭头函数。排查时先确认箭头函数的外层是什么，答案立刻清晰。

6. 几个高频误区与实测结论

这一节把我踩过的坑和验证过的结论集中列出来，都是文档里不常写、但实际开发中经常遇到的。

6.1 误区一：箭头函数让this"更安全"

不是安全，是"固定"。固定有好处也有坏处。需要动态 this 的地方用箭头函数，反而会引入 bug。它不是银弹，是一个有明确适用边界的工具。

6.2 误区二：class里的箭头函数和普通方法一样

不一样。class field 形式的箭头函数，this 绑定到实例，而且每个实例都会创建一份函数副本，内存开销更大。

class A { method() {} // 在原型上，所有实例共享 arrow = () => {}; // 在每个实例上，各一份 }

实测下来，如果一个类有大量实例，且方法很多，全用箭头函数会明显增加内存占用。原型方法该用普通函数就用普通函数。

6.3 误区三：bind之后再用箭头函数能改this

前面说过，bind 对箭头函数无效。这个坑我在封装工具函数时踩过，写了个bind包装，结果 this 死活改不了，排查半天才发现被包装的是箭头函数。

6.4 误区四：严格模式对箭头函数没影响

严格模式影响的是普通函数的默认绑定（从全局变成 undefined），对箭头函数没影响，因为箭头函数压根不走默认绑定。但外层如果是严格模式下的普通函数，箭头函数继承的 this 就是 undefined。

6.5 实测对比表

7. 把规则内化成肌肉记忆

写了这么多年 JS，我对箭头函数 this 的最终体会是：别去背规则，去理解"作用域"和"调用"这两个词。普通函数的 this 跟"调用"绑定，箭头函数的 this 跟"作用域"绑定。每次写代码时问自己一句：这个函数需要跟着调用者走，还是需要跟着定义位置走？答案自然就出来了。

再分享一个我个人的小习惯：在不确定 this 指向时，我会在函数第一行写console.log(this)，跑一遍看结果，比在脑子里推演快得多。尤其是嵌套多层、混用箭头和普通函数的时候，肉眼推演很容易出错，直接打印是最省时间的办法。

还有一个细节值得注意：箭头函数没有arguments对象，如果你在函数里用了arguments，又改成了箭头函数，会直接报错。这时候要用 rest 参数...args替代。这个坑我在重构老代码时遇到过好几次，改的时候顺手把arguments一起处理掉，能省下不少调试时间。

最后说一个判断口诀，我自己总结的："对象方法用普通，回调传参用箭头，需要 new 用普通，需要 call 用普通"。这四句话覆盖了日常开发 95% 的场景，剩下的边角情况，回到"作用域 vs 调用"这个根本原则上推一遍，基本不会错。