this绑定方式本身不直接影响方法寻址性能，真正影响性能的是对象结构稳定性与访问路径一致性——这决定内联缓存（IC）是否生效；V8为obj.method()生成IC stub，一旦this指向对象形状混乱或模式跳变，IC退化致性能下降3–5倍。
直接说结论：this 绑定方式本身不直接影响方法寻址性能，真正影响性能的是方法调用时对象的结构是否稳定、访问路径是否一致——而这正是内联缓存（IC）起效或失效的关键。V8 并不为“this 是谁”做特殊优化，但它会为 obj.method() 这样的调用路径生成 IC stub；一旦 this 指向的对象形状混乱或访问模式跳变，IC 就退化，方法寻址从“直接偏移读取”退回“全量属性查找”，性能下降 3–5 倍。
点号调用 + 稳定 this → IC 高效命中
当 this 指向一个隐藏类（Hidden Class）始终一致的对象，且你用 this.method 形式调用时，V8 能在热路径中建立单态 IC：
- IC 记录：该对象的 Hidden Class +
method属性在内存中的固定偏移量 - 后续调用无需遍历原型链，直接按偏移量跳转到函数地址
- 典型场景：class 实例方法调用（
user.getName()），构造时已声明全部属性，无动态增删
bind / call / apply → 多一层间接，IC 无法穿透
func.bind(obj) 或 func.call(obj) 创建的调用，本质是绕过原始对象的属性访问路径：
-
boundFn()是新函数，其内部仍需通过闭包获取原始func和绑定的this，不走obj.method的点号路径 - V8 无法为
boundFn()建立针对obj的方法寻址 IC，因为调用目标不是obj上的属性，而是闭包内保存的函数引用 - 每次执行都触发闭包环境查找 + 参数重组，无法被 TurboFan 内联，堆内存占用更高
箭头函数与 this 无关，但影响方法归属路径
箭头函数没有自己的 this，也不参与方法寻址逻辑 —— 它根本不会出现在 obj.xxx() 的属性查找链中：
- 它不作为对象属性存在，通常定义在词法作用域内（如 class 方法体内），属于闭包变量
- 调用
handler()是直接调用函数值，不经过任何对象属性访问，IC 完全不介入 - 优势在于无 this 绑定开销，劣势在于无法被 IC 加速（因无属性访问），且不能复用对象上的方法共享机制
隐式绑定断裂 → IC 瞬间失效
看似只是 this 变了，实际是对象结构或访问模式被破坏：
-
setTimeout(obj.method, 100)：取值后obj.method成纯函数引用，调用时 this 为 undefined，但更关键的是——这次调用脱离了obj的 Hidden Class 上下文，IC 不再适用 - 混用不同形状对象：
obj1 = { method() {} }与obj2 = { method() {}, extra: true }，即使都调用objX.method()，IC 也会升级为多态甚至超态 - 动态添加属性：
obj.method = () => {}后再调用，Hidden Class 已变更，IC 缓存作废
