全局执行上下文本身不直接触发隐式类型转换，真正带来风险的是其中的宽松相等（==）、布尔上下文、算术运算和对象到原始值转换：如null==undefined为true、"0"==false为true、空数组与取反结果相等；布尔上下文中0为假值而"0"为真值；+运算符触发字符串拼接；对象参与运算时调用valueof/tostring导致难以追踪的转换。

全局执行上下文本身不直接触发隐式类型转换；真正带来风险的是在该上下文中执行的表达式、赋值、函数调用和比较操作——尤其是当涉及宽松相等（==）、布尔上下文、算术运算或对象到基本类型的转换时。

宽松相等（==）中的隐式转换最易出错

JavaScript 中 == 会按抽象相等算法自动转换操作数类型，导致反直觉结果：

• null == undefined → true（但二者与 0 或空字符串都不等）
• "0" == false → true（字符串转数字得 0，再与 0 比较）
• [] == ![] → true（空数组转空字符串 ""，取反得 false，再转为 0，而 "" 也转为 0）

这类转换发生在全局作用域的顶层表达式中，调试时难以追踪源头，建议统一使用 ===。

布尔上下文下的“假值”误判

在 if、&&、|| 等语句中，以下值被隐式转为 false：false、0、-0、0n、""、null、undefined、NaN。问题常出现在：

Javascript Sdk

用于 inference.sh 的 JavaScript/TypeScript SDK，可运行 AI 应用、构建代理、集成 150+ 模型。包名：@inferencesh/sdk（npm install），完整 TypeScript 支持。

下载

• 函数返回 0 表示“成功”，却被 if (result) 当作失败处理
• API 返回空数组 []，其布尔值为 true，但开发者误以为它等价于 false
• 数值 0 和字符串 "0" 在条件判断中行为不同："0" 是真值，0 是假值

算术运算中的意外字符串拼接

加法（+）是唯一重载运算符：任一操作数为字符串，就触发字符串拼接而非数值相加：

• 1 + 2 + "3" → "33"（先算 1+2=3，再 3 + "3" = "33"）
• "1" + 2 + 3 → "123"（从左到右，每一步都因左侧是字符串而拼接）
• 全局变量未声明即使用（如 sum = a + b），若 a 或 b 是 undefined，结果为 "undefined123" 类字符串

这种转换不可逆，且不会报错，仅在后续逻辑中暴露异常。

对象到原始值的隐式转换难追溯

当对象参与 ==、+、! 等操作时，引擎会调用 ToPrimitive，依次尝试 valueOf() 和 toString()：

• {} + [] → "[object Object]"（空对象转字符串）
• [1,2] + [3,4] → "1,23,4"（数组先 toString() 得 "1,2" 和 "3,4"，再拼接）
• 自定义类若未重写 valueOf 或 toString，默认返回 [object Object]，掩盖真实状态

这类转换发生在全局代码求值阶段，堆栈中无明确调用痕迹，只能靠严格模式警告或 ESLint 规则提前拦截。