JavaScript数组find方法内三元运算符运行异常原因解析

这是典型的JavaScript运算符优先级认知偏差导致的bug，你以为isBoy=true时无括号代码"运行正常"，本质是结果巧合，两种无括号写法的逻辑从一开始就是错的。

首先明确运算符优先级规则：

• 括号()优先级最高（优先级值20）
• 严格相等运算符===优先级为10
• 三元条件运算符?:优先级仅为4，远低于相等运算符

JS引擎解析表达式时会严格按优先级从高到低执行，你写的无括号回调：

v => v.name === isBoy ? "dave" : "choi"

根本不会按你预想的「先计算三元得到要匹配的名字，再和v.name比较」执行，而是会被自动解析为：

v => (v.name === isBoy) ? "dave" : "choi"

再结合Array.find的运行逻辑拆解实际执行效果：find遍历数组时，只要回调返回真值就会直接返回当前元素，不需要回调显式返回布尔值。

• 当isBoy = true时：遍历第一个元素（name为"dave"），先计算"dave" === true，字符串和布尔值严格相等结果永远为false，三元走默认分支返回字符串"choi"。非空字符串属于JS真值，find直接命中第一个元素返回dave，刚好和你预期的查找结果一致，让你误以为代码逻辑正确。
• 当isBoy = false时：遍历第一个元素（name为"dave"），计算"dave" === false结果仍然为false，三元还是返回"choi"这个真值，find依旧直接返回第一个元素dave，和你预期查找choi的结果不符，bug才暴露出来。

给三元整体加括号后，括号会强制引擎优先计算括号内的三元逻辑：

v => v.name === (isBoy ? "dave" : "choi")

执行顺序变为：先根据isBoy的值得到要匹配的目标名字（true对应"dave"，false对应"choi"），再拿当前元素的name和目标名字做严格相等比较，匹配时返回true（真值），find就会命中对应元素，完全符合预期。

主流JS linter的默认规则集中，只有三元运算符和算术、位运算等优先级差异不直观、歧义概率极高的运算符混用时才会强制告警。
相等运算符和三元的组合本身是合法写法——很多场景下开发者确实需要写「如果A等于B就返回X否则返回Y」的逻辑，静态分析无法100%判定你是想把三元作为相等比较的右值，还是想把相等判断作为三元的条件，因此不会默认给出提示。

• 运算符优先级规则：记不清优先级时直接加括号即可，括号没有任何运行时性能损耗，能彻底消除所有解析歧义。
• 数组遍历方法的判定逻辑：find、filter、some等方法的回调只判断返回值的真假，不要求必须返回布尔类型。
• JS真值/假值规则：JS中的假值只有false、0、-0、0n、空字符串""、null、undefined、NaN共8个，其余所有值（包括非空字符串、非0数字、普通对象）都会被判定为真值。

内容的提问来源于stack exchange，提问作者Ryan Southcliff