箭头函数适合简单单一操作，复杂分支应避免；多层三目运算超两层需改用switch或策略对象；守卫逻辑宜提前返回并独立成行，函数名应自解释。
箭头函数本身不提升也不削弱分支逻辑的可读性，关键在于怎么用。它适合表达简单、单一意图的操作；一旦塞进多层 if/else 或嵌套三目，反而会让逻辑更难追踪。
避免在箭头函数里写复杂条件分支
把一堆判断塞进一个箭头函数体里，比如：
const handle = x => { if (x > 0) { if (x
这看起来“简洁”，实则掩盖了控制流，调试和修改都费劲。箭头函数没有函数名、没有堆栈标识，出错时难以定位。
- 超过 2 行逻辑或含 if/else/switch 的，就该用普通函数声明或函数表达式
- 箭头函数适合做“执行器”——接收参数、调用已有逻辑、返回结果，而不是“决策器”
- 想保持简洁？把分支逻辑抽到独立函数里，箭头函数只负责组合调用
用箭头函数配合策略对象提升可读性
真正提升可读性的不是箭头函数本身，而是它和数据驱动结构的配合。比如状态分发：
- 用对象字面量或 Map 做映射表，每个 key 对应一个清晰语义的处理函数
- 这些处理函数可以用箭头函数定义（如果逻辑简单），例如：
const handlers = {
draft: () => saveDraft(),
submit: () => validateThenSubmit(),
reject: () => notifyAndArchive()
}; - 主流程变成：handlers[status]?.() —— 语义明确、增删分支不碰主干
三目运算符 + 箭头函数需谨慎嵌套
像 x => x > 90 ? 'A' : x > 80 ? 'B' : x > 70 ? 'C' : 'D' 这类写法，初看紧凑，但超过 3 层就容易漏括号、误读优先级，也难加注释或调试断点。
- 两层以内且逻辑稳定（如枚举映射）可用
- 涉及计算、副作用、或未来可能扩展，一律改用 switch 或策略对象
- 别为了“一行”牺牲可维护性——编辑器折行、代码格式化工具都能解决视觉长度问题
早期返回比嵌套箭头更有效
与其写：
const process = data => {
if (!data) return null;
if (!data.id) return { error: 'missing id' };
if (data.status === 'archived') return { skip: true };
return doRealWork(data);
};
不如拆成清晰的守卫式判断。这种写法本身和箭头函数无关，但箭头函数常被误用于“强行扁平化”，结果让守卫逻辑藏在大括号里。
- 每个判断独立成行，提前结束，主流程自然落在底部
- 函数名自解释（如 validateInput、skipArchived），比靠箭头函数缩写更有意义
- 需要复用？把守卫逻辑封装为普通函数，箭头函数只作胶水
