箭头函数本身不绑定自身的 this —— 这一特性你或许早已耳熟能详，但若要真正吃透它，关键在于理解“词法继承”与“动态绑定”的本质差异。简单来说，箭头函数中的 this 并非由自身决定，而是“沿着作用域链向上查找”，找到最近一层普通函数（非箭头函数）在执行时所拥有的 this 值，并且这个值在定义时已经确定，后续无论你使用 call、apply 还是 bind 都无法改变它。
换言之，普通函数的 this 遵循“运行时谁调用我就指向谁”的规则，而箭头函数则是“定义时看我外层是谁”。这一区别决定了它在某些场景下如鱼得水，在另一些场景下却可能带来麻烦。
箭头函数的 this 源自词法继承，而非动态绑定
先梳理几条具体规则，心中便有了底：
- 假如外层是全局代码（非严格模式），
this指向window；严格模式下则为undefined - 假如外层是某个对象的方法（普通函数），箭头函数会共享该方法的
this - 若嵌套多层箭头函数，所有层级都共用同一个外层普通函数的
this call、apply、bind对箭头函数无效 —— 无论你传入什么参数，它都不会理会
这里的核心在于“词法继承”：箭头函数不生成自己的 this，而是向外层“借用”一个。就像孩子没有自己的身份证，出门只能拿着父母的证件，父母不变，孩子就永远不变。
适合用箭头函数保持 this 的典型场景
哪些场景需要这种“不变的 this”？最常见的就是异步回调中，你想持续访问外层实例的属性或方法。例如：
- 定时器回调：
setTimeout(() => { this.count++ }, 1000)—— 这里的this指向外层对象，不会因定时器回调独立调用而丢失 - Promise 链回调：
.then(() => this.handleSuccess())—— 省去写const self = this或.bind(this)的麻烦 - 事件监听中的闭包逻辑：比如在类内部发起请求后更新状态，箭头函数能让代码更简洁可靠
在这些场景下，箭头函数几乎堪称“天然救星”——无需手动保存 this，也不必担心被覆盖。
箭头函数不能替代 this 动态绑定的场合
然而，箭头函数并非万能。它不适合那些需要根据调用方式动态决定 this 的情况：
- 对象方法：如果你写成
obj.method = () => { ... }，那么obj.method()中的this并不指向obj，而是指向定义时的外层上下文 —— 通常并非你期望的 - 构造函数：箭头函数无法通过
new调用，因为new需要内部绑定this，而箭头函数不具备此能力 - 需要显式控制 this 的函数：比如工具函数要支持
fn.call(context, ...)，箭头函数连修改都不允许，更谈不上动态绑定
这类需求，还是老老实实使用普通函数配合 bind，或者采用现代写法：类字段语法 handleClick = () => { ... }（本质是实例化时自动绑定，但那是另一套机制）。
事件处理器中慎用箭头函数
最后提及一个容易踩坑的地方：许多人误以为 el.addEventListener('click', () => console.log(this)) 能让 this 指向触发元素，其实并不会。箭头函数的 this 仍然是外层作用域的值（通常是 undefined 或 window），与事件本身毫无关联。
- 要获取被点击的元素，应从事件参数中获取：
event.currentTarget（绑定目标）或event.target（实际点击目标） - 如需调用实例方法，推荐提前绑定：
this.handleClick = this.method.bind(this)，再传给监听器 - 在 React 等框架中常见的
onClick={() => this.fn()}，其实是内联生成函数传给 props，与原生事件绑定逻辑不同——切勿混淆
总的来说，箭头函数的 this 特性是一把双刃剑：用对地方，代码简洁优雅；用错场合，bug 排查会让你怀疑人生。理解其词法继承的本质，你就能在合适的场景随手拿起，在不对的地方果断放下。
