JavaScript中不存在“字符串常量池”概念，Deno、Node.js和浏览器均基于V8引擎的隐式字符串驻留机制，对静态字面量做内存共享优化，但非强制保证；Symbol、BigInt、number等原始值的相等性由语言规范或IEEE标准决定，与运行时无关。
原始类型本身没有“常量池”概念——这是 Java 等语言的术语。JavaScript（包括 Deno、Node.js 和浏览器）对原始值（string、number、boolean、symbol、bigint、null、undefined）的处理基于 值语义 和 V8 引擎的内部优化机制，而非显式的常量池管理。所谓“差异”，其实是运行时底层引擎（主要是 V8）在不同宿主环境中的内存管理策略、字符串驻留（string interning）强度、以及是否暴露底层细节所致，并非语言规范定义的行为。
字符串字面量的驻留行为（最常被误称为“常量池”）
V8 对字符串字面量会做 隐式驻留（interning）：相同内容的字符串字面量通常共享同一内存地址，以节省空间。但这不是强制保证，且各环境表现略有浮动：
-
浏览器（Chrome / Edge）：驻留较激进，
"hello" === "hello"为true，且Object.is("a".repeat(1000), "a".repeat(1000))在多数情况下也返回true（短字符串几乎总驻留） -
Node.js：行为与 Chrome 基本一致，因共用同版 V8；但长期运行的大应用中，V8 可能因内存压力释放部分驻留字符串，导致极少数情况下两次相同字面量的
Object.is返回false（实践中极少遇到） -
Deno：同样基于 V8，驻留逻辑与 Node.js 几乎无差别。Deno 2.7 起对长字符串和动态拼接（如
`${x}${y}`）的驻留更保守，避免影响启动性能；但对静态字面量，行为与浏览器一致
Symbol 和 BigInt 的唯一性保障
Symbol 和 BigInt 的“唯一性”是语言规范强制要求的，与运行时无关：
Java 接口排错助手
下载
在调试 Java 后端 API 故障时使用此技能，尤其适用于以下任务：分析日志、跨 Controller、Service 和 Mapper 层追踪请求、定位异常根因、检查 SQL 执行或参数流转，以及生成简洁的诊断结论与修复方案。
-
Symbol("a") !== Symbol("a")—— 所有环境都成立，因为每次调用都创建新唯一值 -
123n === 123n—— 成立，BigInt 是值相等；但Object.is(123n, 123n)同样为true，不依赖“池” - Deno、Node、浏览器均无“Symbol 池”或“BigInt 池”；它们靠引擎内部唯一 ID 或直接值比较实现
数字和布尔值的零开销处理
number（除 NaN 外）、boolean、null、undefined 在所有 JavaScript 运行时中都是 立即数（immediate values），直接存于栈或寄存器，不涉及堆分配，更无“池”结构：
立即学习“Java免费学习笔记（深入）”；
-
42 === 42、true === true在 Deno/Node/浏览器中 100% 成立，这是 IEEE 754 和语言规范决定的，与运行时实现无关 -
NaN !== NaN同样跨环境一致，由浮点标准保证 - Deno 的 Rust 层不干预这些基础值的表示；它只负责把 V8 的结果透传给 JS 代码
为什么有人觉得“Deno 的字符串池不一样”？
常见误解来源：
-
混淆了模块缓存与字符串驻留：Deno 的
importURL 缓存是模块系统行为，和字符串值存储完全无关 -
权限沙箱干扰感知：在 Deno 中读文件后得到的字符串（如
Deno.readTextFile("a.txt")）是运行时新构造的，不会自动与字面量驻留；但这和“池”无关，而是因为它是运行时生成的值，不是字面量 -
调试器显示差异：Deno CLI 的 devtools 有时省略重复字符串的详细内存地址，让人误以为没驻留；实际可通过
Object.is()验证
