箭头函数适合简化单一表达式逻辑，但不适合多层判断、状态变更或需动态this的场景；应避免在对象方法、类组件handler及需arguments/prototype的业务中使用。
在复杂业务逻辑中用箭头函数，关键不是“能不能写”，而是“该不该用”。它适合简化明确、职责单一的表达式，但不适合承载多层判断、状态变更或需要动态上下文的场景。
看 this 是否必须动态绑定
如果函数要作为对象方法、类实例方法，或需被 call/apply/bind 调用，就别用箭头函数。它不绑定自己的 this，永远继承外层词法作用域——这在业务逻辑里容易导致隐性错误。
- ✅ 适合：定时器回调、Promise.then 回调、事件监听器（需保持外层 this）
- ❌ 避免：对象字面量里的方法、Vue/React 类组件中的 handler、工具类中需复用的方法
看逻辑是否超过单表达式
箭头函数天然倾向“一行一结果”。一旦涉及变量声明、条件分支、副作用（如 console、API 调用、状态更新），就必须加花括号 + 显式 return，此时语法优势消失，可读性反而下降。
- ✅ 推荐写法：users.map(u => u.name)、items.filter(i => i.status === 'active')
- ❌ 不推荐写法：data.map(item => { if (item.type === 'A') { ... } else { ... }; return result; }) —— 直接换成命名函数更清晰
看是否需要构造实例或访问 arguments
箭头函数不能用 new 调用，没有 arguments 对象，也没有 prototype。如果业务模块涉及工厂模式、插件扩展、或需兼容老式参数处理逻辑，普通函数更稳妥。
立即学习“Java免费学习笔记（深入）”；
- 普通函数能：new Service()、fn.apply(ctx, args)、console.log(arguments[0])
- 箭头函数会报错：new (() => {})、() => { console.log(arguments) }
看团队协作与长期维护成本
大厂和成熟项目常限制箭头函数在复杂逻辑中的使用，不是因为它不好，而是因为“简洁”不等于“易懂”。当一个箭头函数嵌套三层、混着三元运算和解构，新人理解成本远高于一个语义清晰的 function calculatePrice() {}。
- 建议：把多行逻辑抽成具名函数，箭头函数只留作调用入口或高阶函数参数
- 示例：const orderTotal = (order) => calculateTotal(order);，其中 calculateTotal 是独立、可测试、带注释的普通函数
