no-unsafe-optional-chaining搭配||运算符不生效的优化方案问询

no-unsafe-optional-chaining规则的核心判定逻辑是：禁止可选链短接返回undefined/null后，直接参与算术运算、函数调用、属性访问等无法正确处理空值的操作，从静态检查层面避免非预期的运行时结果。

你之前的第二种写法不生效，本质是两个问题：

• 直接去掉了可选链操作符?.写成a.order，如果入参a/b本身是null/undefined，运行时会直接抛出属性访问错误，本身就存在逻辑漏洞
• 即便保留可选链写成+a?.order || 0，一元加号+是直接作用在可选链返回值上的，只要可选链短接返回undefined，+undefined就会得到NaN，后续的|| 0是在+运算执行完之后才做的判断，依然属于规则定义的不安全场景，自然会报错。

推荐写法（比三元写法精简60%以上） #

用ES2020的空值合并运算符??给可选链结果先做兜底，再执行转数字操作，既符合规则要求，逻辑也更严谨：

const sortComparer = (a, b) => +(a?.order ?? 0) - +(b?.order ?? 0)

写法说明 #

• 空值合并运算符??只会在左侧值为null/undefined时才返回右侧兜底值，不会把合法的0、空字符串这类假值误判为需要兜底的场景，比||更适配数字字段的处理逻辑
• 整个可选链+兜底的逻辑被包裹在括号内，保证传入一元加号+的永远是有效值（要么是order字段的原始值，要么是兜底的0），从根源上避免了可选链短接带来的不安全运算，完全符合规则校验要求
• 逻辑覆盖所有场景：入参为空、order字段为空、order是字符串数字、order是纯数字的场景都能正确处理，不会出现NaN导致排序异常的问题

如果你不习惯用一元加号转数字，也可以换成Number()做类型转换，效果完全一致：

const sortComparer = (a, b) => Number(a?.order ?? 0) - Number(b?.order ?? 0)

注：所有支持可选链?.的ESLint/JS运行环境，都原生支持空值合并运算符??，不需要额外做语法兼容配置。

内容的提问来源于stack exchange，提问作者Murtaza Hussain