显式传参比依赖 this 更可控、易读、少出错；函数定义时声明所需数据，如 greet(user, city)，避免 this 绑定问题，提升可测试性与纯函数特性。
直接用参数传对象，比依赖 this 更可控、更易读、更少出错。
显式传参让逻辑一目了然
把上下文对象作为明确参数传入，函数行为不再隐含依赖调用方式。别人一眼就能看出“这个函数需要谁的数据”，也避免了因绑定规则变化导致的静默错误。
- 函数定义时就声明所需数据，比如 function greet(user, city)，而不是 function greet(city) 且内部用 this.name
- 调用时主动传入，如 greet(me, 'Beijing')，语义清晰，无需猜测 this 指向
- 单元测试更容易：直接构造 mock 对象传入，不用模拟调用上下文或使用 call/apply
适合哪些场景优先改用显式传参
不是所有地方都要弃用 this，但以下情况强烈建议显式传参：
- 工具函数（如格式化、校验、计算类），它们本就不该绑定到某个实例上
- 事件回调中容易丢失 this 的地方，比如 btn.addEventListener('click', handler)，handler 独立执行时 this 会变，不如写成 btn.addEventListener('click', () => handler(userData))
- 高阶函数返回的函数，或被解构后单独调用的方法（如 const { sayHi } = obj; sayHi()），此时隐式绑定已失效
箭头函数不是万能解药
有人用箭头函数“修复” this，但本质是回避问题——它只是继承外层 this，若外层本身没绑定好，照样出错。而显式传参不依赖任何绑定规则，从源头消除不确定性。
- 箭头函数无法用 new 调用，也不支持 call/apply/bind，灵活性受限
- 嵌套多层时，外层 this 可能已是意外值，箭头函数反而掩盖了真正的问题
- 显式传参让函数彻底无状态、无上下文依赖，天然支持纯函数思维
渐进式改造小技巧
不必重写全部代码，可逐步优化：
- 新写的工具函数默认用参数接收上下文，不碰 this
- 对已有方法，加一层薄包装：原 obj.doSomething()，改为 doSomething(obj)
- 团队协作时，在 ESLint 中启用 no-invalid-this 和 prefer-arrow-callback（仅限确实需要继承外层 this 的回调）
