要唯一项用find()，要多个或不确定数量用filter()；find()找到即停，filter()必扫全数组；find()返回undefined适配可选链，filter()返回空数组支持链式调用。
直接看结果类型和查找目标：要唯一项就用 find()，要多个或不确定数量就用 filter()。性能差异本质来自遍历行为——find 找到即停，filter 必须扫完整个数组。
返回值决定语义起点
语义抉择的第一关是“你要什么”：
- 需要一个具体对象（比如通过
id查用户、通过token查配置项）→ 返回单个值 → find() - 需要一批同类数据（比如所有
status === 'pending'的订单、所有价格低于 100 的商品）→ 返回数组 → filter() - 即使只预期一个结果，但逻辑上可能有多个（如查所有邮箱为
@example.com的用户）→ 仍属集合场景 → filter()
性能差异的核心在遍历策略
find() 是短路操作，filter() 是全量扫描：
-
find()：从索引 0 开始检查，一旦回调返回
true，立刻返回当前元素，后续元素完全不访问 - filter()：不管前几个已匹配，必须逐个调用回调，判断每个元素是否满足条件，再收集进新数组
- 在 10 万条数据中查找第一个
type === 'error'的日志，find() 可能在第 3 条就结束；filter() 一定执行 10 万次判断
空结果处理暴露设计意图
如何响应“没找到”，也反映语义倾向：
-
find() 返回
undefined：天然适配可选链（?.name）或空值合并（?? 'default'），强调“要么有，要么无” -
filter() 返回
[]：便于链式调用（.map().forEach()），也支持长度判断（if (list.length)），强调“结果是一个集合” - 若用
filter()[0]替代find()，不仅多建数组、多遍历，还掩盖了“只取首个”的业务意图
实际选用建议
别靠猜测，按明确信号选：
- 条件里含
id、uuid、username等唯一标识字段 → 用 find() - 回调中用了
break或想提前退出的念头 → 说明你真正需要的是 find() - 后续要对结果做
.length、.map()、.forEach()→ 用 filter() - 不确定是否唯一，但业务上只用第一个 → 仍优先 find()，更清晰且更省资源
