Symbol.for 能跨模块共享是因为它通过全局符号注册表返回相同字符串参数对应的同一 Symbol 实例，而非每次新建；需配合全局对象（如 globalThis）存取状态，且键名应统一管理、避免硬编码或动态拼接。
Symbol.for 为什么能跨模块共享
因为 Symbol.for 不是每次调用都新建 Symbol，而是查全局符号注册表（global symbol registry）：相同字符串参数会返回同一个 Symbol 实例。这和直接调用 Symbol('key') 完全不同——后者每次都是全新值，哪怕字符串一样。
关键点在于：所有模块只要都执行 Symbol.for('my-state-key')，拿到的就是同一个引用。Node.js 的模块缓存、浏览器的 script 加载顺序都不影响这个一致性。
注意：Symbol.for 的注册表是运行时全局的，不随模块作用域隔离；但它的键名是字符串，所以拼写错误或大小写不一致就会命中不到，变成两个独立 Symbol。
如何安全定义跨库状态键名
避免硬编码字符串，否则多个库各自写 Symbol.for('state') 看似一样，实则易冲突或难维护。推荐做法：
- 在单独的包（如
@shared/symbols）中统一导出键名 Symbol，其他库 import 使用 - 键名字符串加命名空间前缀，比如
'@myorg/state/counter'，降低撞名风险 - 不要把
Symbol.for调用放在条件分支里——它必须被执行过才能注册，未执行的分支不会“预注册” - 不建议用动态拼接字符串传给
Symbol.for，比如Symbol.for(prefix + 'state')，会导致不可预测的键名
示例（shared-symbols.ts）：
export const STATE_SYNC_KEY = Symbol.for('@myorg/state/sync');
用 Symbol.for 做状态同步的实际限制
Symbol 只是键名，不是状态容器本身。你仍需配合一个全局可访问的对象（如单例、window、globalThis）来存取值：
- 不能直接把状态挂到 Symbol 上，
Symbol是不可枚举、不可赋值的原始值 - 典型模式是：用
Symbol.for生成唯一 key，再把它作为属性名写入globalThis或某个共享对象，例如globalThis[STATE_SYNC_KEY] = { count: 0 } - 多个库读写同一 key 对应的值时，需自行处理并发更新（Symbol 本身不提供同步机制）
- ESM 环境下，
globalThis在浏览器是window，Node.js 是global，但某些打包器（如 webpack）可能污染它，建议加存在性判断
常见误用导致“看似共享实则失效”
现象：两个库都调用了 Symbol.for('x')，但状态没同步。原因往往不是 Symbol 问题，而是底层存储没对齐：
- 一个库往
globalThis[SYM]写，另一个却从module.exports.stateCache[SYM]读 —— 键名一样，容器不同 - 使用了
Symbol.keyFor(sym)反查键名，但只对Symbol.for创建的 Symbol 有效；若混用了Symbol()，返回undefined，容易引发静默失败 - 服务端渲染（SSR）场景下，Node.js 和浏览器各跑一次
Symbol.for，但globalThis不互通，需要额外序列化/反序列化逻辑 - 测试环境（如 Jest）默认隔离全局对象，
Symbol.for注册表可能被重置，单元测试间状态不延续
最稳妥的做法始终是：键名用 Symbol.for 保证唯一，状态载体明确指定且双方共用同一引用，不依赖隐式上下文。
