可选链（?.）仅在访问 null/undefined 时短路，不防类型错误、运行时异常或逻辑错误；对原始值使用会报错；需与 ?? 配合提供默认值；在解构、in 操作符、promise 异常等场景无效；ts 中类型推导有陷阱，不能替代数据契约校验。
为什么 ?. 不能代替所有 . 操作
可选链不是万能的安全网。它只在遇到 null 或 undefined 时短路返回 undefined，但不会阻止类型错误（比如对非对象值调用方法）、运行时异常（比如函数内部抛错）或逻辑错误（比如误以为返回了有效值）。常见误用是写成 obj?.prop?.method()，结果 obj?.prop 是个字符串，却当成函数调用——?. 不检查类型，只检查是否为 null/undefined。
- 仅对对象、数组、函数等“可访问成员”的值生效；对原始值（
string、number、boolean）使用?.会直接报TypeError: Cannot read properties of xxx -
arr?.[index]安全，但arr?.length不等于arr && arr.length：如果arr是null，两者都安全；但如果arr是42，42?.length报错，而42 && 42.length返回42（falsy 前置判断更宽松） - 链式调用中任意一环返回
undefined，后续所有?.都跳过，但最终结果仍是undefined，容易掩盖数据缺失问题
?. 和 ?? 必须配合使用的典型场景
单独用 ?. 得到 undefined 后，若直接参与计算或渲染，常引发新问题（如 undefined + 1 → NaN，undefined.toString() → 报错）。这时候必须接 ?? 提供默认值。
- 获取嵌套配置：
config?.api?.timeout ?? 5000，比config?.api?.timeout || 5000更可靠（后者在timeout为0时也会 fallback） - React 渲染可选字段：
{user?.profile?.name ?? '匿名用户'}，避免空字符串或0被误判为 falsy - 函数调用后取默认：
getData()?.items?.[0]?.id ?? null，注意getData()若抛错，?.不捕获，仍会崩溃
哪些地方 ?. 根本不生效，必须换方案
可选链只作用于属性访问、调用、索引三类操作，对变量声明、解构、for...in、Object.keys() 等完全无效。遇到这些，得回归传统防御性写法或工具函数。
- 解构赋值不能用
?.：const { name, age } = user?.profile || {}才是正确写法，const { name, age } = user?.profile?.{}语法错误 - 动态 key 访问：
obj?.[key]安全，但key in obj或obj?.hasOwnProperty(key)中的?.无效（in和hasOwnProperty是操作符/方法，不是属性访问） - 异步操作失败：
await api.getData()?.then(...)不行——?.不处理 Promise rejection，必须用try/catch或.catch()
TypeScript 下 ?. 的类型推导陷阱
TypeScript 会把 a?.b?.c 的类型推导为 T | undefined，但这个 undefined 是“可能中途断掉”，不是“c 本身可为 undefined”。如果原类型已含 undefined，叠加后可能产生双重可选，导致后续非空断言（!）失效或类型收缩不准确。
- 接口定义中字段本身是
string | undefined，再用obj?.field?.toUpperCase()，TS 推导为string | undefined，但实际执行时若obj为空，连field都没机会读——类型安全 ≠ 运行安全 - 开启
strictNullChecks后，?.的返回值必须显式处理，不能直接传给只接受非空类型的函数，否则编译报错 - 与
!.（非空断言）混用危险：obj!.data!.items![0]!.id!完全绕过 TS 检查，而obj?.data?.items?.[0]?.id至少保证了链路安全
?. ，而在清楚每一层的数据契约：哪个字段可能空、哪个调用可能失败、哪个默认值合理。可选链只是让「显式检查」更简洁，不是免检通行证。
