解构赋值后 this 会丢失，因方法脱离原始对象上下文，调用时 this 指向取决于调用方式而非来源；推荐类字段箭头函数、bind 预绑定或调用时箭头函数包装修复。
解构赋值后 this 为什么会丢失
当从类实例或对象中解构出一个方法，例如 const { handleClick } = instance，该方法就脱离了原始对象的调用上下文。此时再调用 handleClick()，它已变成普通函数调用，在严格模式下 this 为 undefined，非严格模式下指向全局对象。这不是 bug，而是 JavaScript 的设计机制：this 绑定取决于“怎么调用”，而不是“从哪来”。
三种可靠修复方式
针对解构后调用导致的 this 丢失，推荐以下实践，按适用场景排序：
-
类字段 + 箭头函数（最推荐）：在类内部直接定义箭头函数字段，天然绑定实例 this
例：handleClick = () => { console.log(this.name); };
解构后仍可安全使用：const { handleClick } = instance; handleClick(); -
bind 预绑定（明确可控）：解构时立即绑定 this，返回新函数
例：const handleClick = instance.handleClick.bind(instance);
后续调用handleClick()始终指向 instance -
调用时包裹箭头函数（灵活传参）：不提前解构方法，而是在使用处用箭头函数包装
例：const { id } = instance; const handler = () => instance.handleClick(id);
适合需动态传参或仅单次使用的场景
需要避开的误区
有些写法看似简洁，实则引入隐患：
JavaStoryDevelop
下载
你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在
- 不要在类外用箭头函数包装解构方法，如
const handleClick = () => instance.handleClick();—— 这会丢失对原方法参数的透传能力，且每次调用都新建函数 - 避免在构造函数中对方法做 bind 并赋值给实例属性（如
this.handleClick = this.handleClick.bind(this);），虽可行但冗余；类字段语法更清晰、更符合 ES6 惯例 - 解构后不能依赖 call/apply 临时修正，因为调用方可能不知道要传什么 this —— 修复应发生在定义或获取阶段，而非每次调用时
静态方法与解构无关，但要注意 this 指向差异
静态方法中的 this 指向类本身，不是实例。若在静态方法中解构实例方法，依然会丢失 this —— 因为解构行为不改变绑定规则。正确做法是：静态方法只操作静态属性或接收显式传入的实例，避免隐式依赖 this 上下文。
立即学习“Java免费学习笔记（深入）”；
