应使用严格相等字面量守卫（如=== true）进行类型收窄，而非真值判断、in操作符或类型断言；自定义类型谓词适用于需复用或增强可读性的场景。
在布尔值参与的联合类型中（比如 true | ValidationError），直接访问对象属性会报错，因为 TypeScript 不允许从 true 这样的原始值上读取 err。类型守卫不是“绕过”限制，而是让编译器真正理解：**这个分支里，变量只剩一种可能类型**。
用 === true / === false 做字面量守卫
这是最轻量、最推荐的方式，无需额外函数，零运行时开销，且语义清晰。
- 当联合类型包含字面量布尔值（
true或false）时，TypeScript 控制流分析会自动收窄剩余分支 - 例如：
if (result === true) { ... } else { /* result 此时被推断为 ValidationError */ } - 注意：不能写
if (result)，那只是真值判断，无法触发类型收窄；必须是严格相等的字面量比较
用 in 操作符需谨慎——它不适用于布尔+对象联合
"err" in result 看起来直观，但 TypeScript 会拒绝它：
- 因为
in要求左侧操作数必须是object类型，而true是原始值，不属于object - 编译器会报错：
Type 'true | ValidationError' is not assignable to type 'object' - 所以这种组合下，
in守卫不可用，别强行尝试
自定义类型谓词：适合复用或增强可读性
当你需要多次判断、或想显式表达意图（比如团队协作、未来扩展校验逻辑），可以封装一个类型守卫函数：
- 函数签名必须是
function isValidationError(val: unknown): val is ValidationError - 内部检查应先排除原始值：
typeof val === 'object' && val !== null，再查属性 - 这样既安全又明确，调用时也能获得 IDE 提示和类型保障
避免用 as 断言代替守卫
写 (result as ValidationError).err 能过编译，但风险极高：
- 它不进行任何运行时检查，如果
result实际是true，就会在运行时抛出Cannot read property 'err' of true - 类型守卫的核心价值就是把“我猜它是”变成“我确认它是”，断言恰恰放弃了这份确认
- 除非你 100% 确保上下文不会出错（比如单元测试中 mock 固定返回值），否则不要用
