在 JavaScript 中处理原始类型（如字符串、数字、布尔值）看似简单，但你有没有意识到，稍有不慎就可能踩入隐式转换错误、类型误判、原型污染甚至 XSS 攻击的陷阱？真正的安全并不依赖“运气”，而需要明确的类型边界、可预测的校验逻辑以及防御性设计来兜底。以下几条原则，正是保障 JavaScript 原始类型安全操作的核心要点。
用 typeof + 显式 null/undefined 分离做基础类型断言
typeof 是 JavaScript 里检测原始类型的运行时利器，但它有个众所周知的缺陷——null 居然返回 'object'。这个坑必须特别留神。安全的做法是先过滤掉 null 和 undefined，再使用 typeof 进行判定：
- 别写
if (typeof x === 'string')后就立刻调用x.trim()，因为你完全不清楚x是否为null或undefined。 - 正确写法是：
if (x != null && typeof x === 'string')。这里的!= null能同时把null和undefined挡在门外。 - 更严谨的做法是封装成工具函数，例如
const isString = x => x != null && typeof x === 'string'，避免重复编写相同的判断逻辑。
禁止隐式转换，所有比较一律用 ===
原始类型之间的松散比较（==）会触发不可控的类型转换，极易导致逻辑混乱。比如 '0' == false 的结果是 true（字符串先转数字再转布尔），0 == '' 结果也是 true，但 0 === '' 则返回 false——严格相等才符合我们编码时的直觉。在函数参数校验、配置项判断、状态比对等场景中，必须使用 === 或 !==。ESLint 规则中的 valid-typeof 和 no-eq-null 也能在编译阶段提前阻止这类不安全写法。
输入校验前置，拒绝“信任传入值”思维
凡是接收外部数据的地方——例如 API 响应、表单字段、URL 参数——在操作原始类型之前，都必须先校验再处理。
- 数字操作前，添加一层
!isNaN(Number(input)) && isFinite(Number(input))检查，防止NaN或Infinity污染后续计算。 - 字符串处理前，确保它非空且长度合理：
isString(input) && input.length > 0 && input.length < SOME_MAX_LENGTH。 - 布尔值的转换，不依赖
!!value这种隐式方式，而采用显式映射：const toBoolean = x => x === true || x === 'true' || x === 1 || x === '1'，逻辑清晰且更安全。
冻结原生原型，堵住全局污染入口
第三方脚本或恶意代码可能篡改 String.prototype 等内置原型，导致所有字符串方法失效——这个风险不容小觑。有效的预防措施是在应用初始化的最早阶段执行：Object.freeze(String.prototype); Object.freeze(Number.prototype); Object.freeze(Boolean.prototype)。注意：冻结后无法新增或修改方法，但原有功能（如 'a'.trim()）调用不受影响，它仅阻止覆盖。搭配严格模式（"use strict"）一起使用，还能进一步限制全局变量的意外创建。
纯函数封装校验逻辑，隔离副作用
将所有原始类型的安全操作收拢为不可变、无状态的工具函数，形成可复用、可测试的防护层。例如：Str.safeTrim = s => isString(s) ? s.trim() : ''。这样的设计不抛错、不中断流程，遇到非法输入则返回兜底值。所有函数只接收原始值并返回新值，不修改入参，也不读取 localStorage 或 document 等全局对象。最好统一导出为一个命名空间，比如 export const Types = { isString, isNumber, safeParseInt, safeTrim }，避免校验逻辑散落在各处。
