应避免使用 new String()、new Number()、new Boolean() 创建包装对象，因其生成真实对象而非原始值，导致类型判断错误、相等比较失效、逻辑异常、性能开销大且无实际必要。
在 JavaScript 中，用 new String()、new Number() 或 new Boolean() 显式创建包装对象，会生成真正的对象实例，而非原始值。这不仅违背日常编码直觉，还会带来可观察的性能与行为问题。
包装对象与原始值的行为差异明显
包装对象是对象类型，而对应原始值（如 "hello"、42、true）是基本类型。这意味着：
-
typeof new String("a")返回"object"，而typeof "a"是"string" -
new String("a") === "a"为false（严格相等比较对象与字符串） - 包装对象在
if语句中虽为真值，但new Boolean(false)仍是真值（因非空对象），极易引发逻辑错误 - JSON 序列化时，
JSON.stringify(new String("x"))得到"x"（隐式调用toString），但其原型链、属性可枚举性等均不同于原始值
内存与运行时开销真实存在
每次调用 new String(...) 都会分配新对象，涉及堆内存分配、原型链绑定、内部属性初始化等步骤：
- V8 等引擎不会对这类对象做特殊优化，它们无法享受字符串常量池或小整数缓存（Smi）等底层优化
- 大量使用（如循环中构建
new Number(i)）会显著增加 GC 压力，尤其在长期运行的前端应用或 Node.js 服务中 - 包装对象的属性访问（如
(new String("abc")).length）需走对象属性查找路径，比原始值的内建属性访问稍慢
现代代码中几乎无正当使用场景
ECMAScript 规范明确指出：包装对象仅用于支撑原始值的方法调用（如 "abc".toUpperCase()），该过程由引擎自动完成，开发者无需也不应手动干预：
立即学习“Java免费学习笔记（深入）”；
- 需要“类字符串操作”？直接用原始字符串 —— 所有字符串方法都支持隐式装箱
- 需要区分“空字符串”和“null/undefined”？用
value == null或typeof value === "string"，而非value instanceof String - 需要自定义行为？应使用 class 封装，而非依赖易混淆的包装对象
- TypeScript 类型层面，
String构造器类型已标记为废弃（@deprecated），编辑器会发出警告
替代方案简单且更安全
遇到曾想用包装对象解决的问题，通常有更清晰的选择：
- 确保类型：用
String(value)、Number(value)、Boolean(value)进行显式强制转换（返回原始值） - 类型检查：用
typeof x === "string"，而非x instanceof String - 扩展功能：写工具函数，如
isNotBlank(str)，或用 Proxy 包裹原始值（极少数需拦截场景） - 序列化控制：自定义
toJSON()方法，而不是依赖包装对象的默认行为
不复杂但容易忽略：JavaScript 的隐式装箱机制足够健壮，手动创建包装对象既无必要，又埋下隐患。保持原始值优先，是写出清晰、高效、可维护代码的基本习惯。
