symbol.for()在同环境天然返回同一引用，验证需模块间严格相等判断；若不等，常见于polyfill污染、realm隔离或动态拼接键名；应使用静态字面量键名并集中导出。
要确认 Symbol.for() 创建的键名在跨模块中是否保持原始引用一致，核心不是“检测”，而是“验证它是否被正确使用”。因为 Symbol.for('key') 本身在同一个 JS 全局环境里天然返回同一引用，问题几乎总是出在使用方式或运行时环境上。
看两个模块拿到的 Symbol 是否真相等
最直接、不可绕过的验证方式：在模块 A 中生成并导出，模块 B 中导入后做严格相等判断。
- 模块 A（shared-symbols.js）：export const SYNC_KEY = Symbol.for('myapp:state');
- 模块 B（feature.js）：import { SYNC_KEY } from './shared-symbols.js'; console.log(SYNC_KEY === Symbol.for('myapp:state')); // 必须为 true
如果输出 false，说明模块 B 并未真正复用注册表中的实例——常见原因是模块 B 没有走统一导出路径，而是自己写了 Symbol.for('myapp:state')，但该调用发生在被 polyfill 污染或 Realm 隔离的上下文中。
检查全局注册表是否被污染或隔离
Symbol.for 的一致性依赖底层全局符号注册表（global symbol registry）。以下情况会导致“同名不同实”：
- 多个版本的 core-js 或 @babel/polyfill 被重复加载，各自维护独立 Symbol 构造函数
- 子应用运行在 iframe、Web Worker 或微前端沙箱（如 qiankun 的 proxy 模式）中，虽共享浏览器级注册表，但部分沙箱会重置或劫持 Symbol 全局对象
- Electron 主进程与渲染进程之间，globalThis 不互通，Symbol.for 无法跨进程共享
验证方法：在各模块执行 console.log(Symbol.keyFor(Symbol.for('test')))，若都返回 'test'，说明注册表可用；若某处报错或返回 undefined，则 Symbol 构造函数已被替换或隔离。
避免动态拼接和条件调用陷阱
Symbol.for 只有被执行过才会注册。以下写法看似无害，实则破坏一致性：
- ❌ if (DEBUG) { Symbol.for('debug'); } —— DEBUG 为 false 时，该键名从未注册，其他模块调用会新建一个
- ❌ Symbol.for(NAMESPACE + '_cache') —— 字符串拼接导致键名不可控，不同模块拼出的字符串稍有差异就命中不到
- ❌ const key = 'mylib:state'; Symbol.for(key) —— 表面安全，但若 key 值来自配置或环境变量，仍属动态，应固化为字面量
正确做法是所有键名字符串必须是静态字面量，并集中在一个包中定义、导出、复用。
用 WeakMap 或全局对象反向验证引用归属
Symbol 本身不可赋值，但可作为键存入对象或 WeakMap。利用这一点可间接验证是否同一引用：
- 在模块 A 中：const store = new WeakMap(); store.set(Symbol.for('data'), { value: 1 }); export { store };
- 在模块 B 中：import { store } from './module-a.js'; const key = Symbol.for('data'); console.log(store.has(key)); // true 才表示 key 是同一实例
如果返回 false，说明模块 B 的 key 和模块 A 的 key 不是同一个对象引用，根源仍在 Symbol.for 调用环境不一致。
