node.js 中无法真正封禁访问，但可通过运行时校验调用来源实现白名单控制：1. 解析 error.stack 获取调用方路径比对白名单；2. 白名单模块主动注册 id；3. 检查 module.parent（仅 commonjs）；4. 基于 package.json name 查找比对。
在 Node.js 模块系统中，exports 本身只是 module.exports 的一个引用别名，它不能直接控制“谁可以访问”，但可以通过封装 + 条件校验 + 模块标识机制，实现逻辑上的“仅白名单模块可调用核心变量接口”。关键不在于阻止 JS 层面的访问（JS 无法真正封禁），而在于运行时主动识别调用来源并拒绝非授权模块。
1. 使用 require.cache 和 __filename 追溯调用栈
通过 Error.stack 或 new Error().stack 获取当前调用位置，解析出调用方模块的绝对路径，再与预设白名单路径比对：
- 在核心模块（如
core.js）中导出接口时，不直接暴露变量，而是包裹一层校验函数 - 校验逻辑读取
new Error().stack，提取第二帧（即调用方）的文件路径 - 将该路径标准化（
require.resolve()或path.resolve()），检查是否在白名单数组中 - 若不在白名单，抛出
TypeError或返回undefined/ 空对象
2. 基于模块标识符（Module ID）的白名单注册
Node.js 中每个被加载的模块在 require.cache 中有唯一键（即其绝对路径）。可让白名单模块在首次 require 核心模块后，主动向其注册自身身份：
- 核心模块导出一个
registerWhitelist(id)方法，只允许被特定模块（如通过硬编码路径或 package.json name 校验）调用 - 白名单模块在顶层执行时调用
core.registerWhitelist(__filename)或core.registerWhitelist('my-app') - 后续所有接口调用前，先检查当前调用栈中是否存在已注册的模块 ID
- 避免依赖
stack解析，更稳定（尤其在 minify 或 source map 场景下）
3. 利用 module.parent 做静态调用链判断
适用于严格单层调用场景（如插件必须直接 require 核心模块，不能经由中间包转发）：
- 在接口函数内检查
module.parent && module.parent.filename - 对比
module.parent.filename是否匹配白名单路径（注意：ESM 不支持module.parent，此法仅限 CommonJS） - 优点是开销极小；缺点是易被伪造（如手动设置
module.parent），仅作辅助校验
4. 结合 package.json name 实现语义化白名单
比路径更健壮——路径可能因软链接、pnpm store 等变化，而 package.json name 更稳定：
- 在核心模块中，根据调用方文件路径向上查找最近的
package.json - 读取其
name字段（可用find-up库或手动遍历） - 白名单维护为
['@myorg/auth', 'my-admin-ui', 'legacy-migration-tool']等字符串集合 - 适合组织内多包管理（monorepo）或明确第三方合作方的场景
真正安全的隔离需结合编译期约束（如 TypeScript 路径映射 + 模块解析限制）和运行时校验。纯靠 exports 无法实现访问控制，但通过主动识别 + 拒绝策略，可让非白名单模块“能 import，但拿不到有效值”，达到工程意义上的受控暴露。
