Symbol.for() 跨包“失效”是因为不同 Realm 或 polyfill 导致全局 registry 不共享；可靠方案是统一导出权威 Symbol 实例，或退用带命名空间的字符串 key。
Symbol.for() 本身不解决跨包共享问题，它只保证在同一个全局环境（globalThis）中键名相同则返回同一 Symbol 实例；但不同 npm 包若运行在多个隔离的 Realm（如 iframe、Web Worker、或被某些打包工具错误地重复注入 Symbol polyfill），Symbol.for('my-key') 就会返回不同的 Symbol。
为什么跨包时 Symbol.for() 常常“失效”
常见现象是：A 包调用 Symbol.for('debug') 得到一个 Symbol，B 包同样调用却得到另一个——两者不相等，导致 instanceof 判断、Object.hasOwn(obj, sym) 或私有字段访问失败。
根本原因不是 Symbol.for() 有 bug，而是：
- Node.js 中多个
node_modules子树各自 require 了带 Symbol polyfill 的依赖（如 core-js），导致多个独立的 Symbol 构造函数实例 - 浏览器中通过
import加载的 ESM 模块若被不同构建产物分别打包，可能运行在不同模块作用域，而Symbol.for依赖全局 registry，该 registry 在 polyfill 场景下未必共享 - Electron 或微前端场景下，主应用与子应用运行在不同 JS 执行上下文（如不同 iframe 或 contextIsolation 环境），
globalThis不互通
真正可靠的跨包 Symbol 共享方案
必须让所有包都引用**同一个 Symbol 实例**，而非依赖 Symbol.for() 动态查找。最简方式是显式导出一个“权威 Symbol”：
在核心基础包（如 @org/shared）中定义：
export const DEBUG_KEY = Symbol.for('org:debug'); // ✅ 只在此处调用一次
export const VALIDATION_ERROR = Symbol.for('org:validation:error');
其他包统一 import 使用：
import { DEBUG_KEY } from '@org/shared';
obj[DEBUG_KEY] = true;
这样即使 Symbol.for 在各处行为不一致，只要所有包都从同一份 ESM/CJS 模块 resolve 到这个 DEBUG_KEY，就天然唯一。
关键点：
- 不要在业务包里自己写
Symbol.for('xxx')—— 这等于放弃控制权 - 确保基础包被正确 dedupe：检查
npm ls @org/shared是否只出现一个版本；否则多版本共存会导致导出的 Symbol 实例不一致 - 如果使用 pnpm/yarn PnP，确认
@org/shared没有被提升到多个 virtual store
替代方案：用字符串 key + 命名空间约定（更稳妥）
当无法控制所有包都依赖同一基础包时，退而求其次用字符串 key，但加严格命名空间和文档约束：
const DEBUG_KEY = '@org/debug'; // 字符串，非 Symbol obj[DEBUG_KEY] = true;
优势是完全无环境依赖；缺点是失去 Symbol 的“不可枚举”“不可被 for...in 遍历”特性。若需隐藏属性，可配合 Object.defineProperty 设置 enumerable: false，并在文档中明确该 key 为保留字段。
适用场景：
- 微前端子应用与主框架通信字段
- 第三方插件向宿主框架注入元信息（如 vite 插件向
config添加__vite_plugin_foo属性） - 调试工具需要识别特定对象类型，但无法要求用户统一安装某个 shared 包
真正难的不是生成 Symbol，而是确保它被所有人以同一引用方式消费。跨包时，信任 Symbol.for() 的“全局性”是最常见的误判起点。
