javaScript（Node.js/Deno）的 ES 模块不支持类似 Java 的访问修饰符（如 private 或 package-private），无法原生限制某个 export 仅被特定文件导入；真正的封装应通过模块职责划分、作用域控制与架构设计来实现。
javascript（node.js/deno）的 es 模块不支持类似 java 的访问修饰符（如 `private` 或 `package-private`），无法原生限制某个 `export` 仅被特定文件导入；真正的封装应通过模块职责划分、作用域控制与架构设计来实现。
在 javascript 的模块生态系统中（包括 Node.js（v14.13+ ESM）和 Deno），export 是全局可见的公开契约：一旦使用 export 声明，该成员即对任何合法导入者（import 语句）开放，不存在语法层面的“仅限 index.js 导入”机制。你所看到的如下写法：
// config.ts export const t = { a: 'this will export for index.js only' // ❌ 语义误导：实际所有文件均可 import { t } from './config.ts' }本质上是一种逻辑误用——t 并非“只为 index.js 导出”，而是对整个模块图公开。试图用导出语法实现访问控制，违背了 ES 模块的设计哲学：模块边界即封装边界，而非导出粒度。
✅ 正确的封装策略
1. 利用作用域隔离（推荐首选）
将仅需内部使用的值定义在模块顶层作用域，不导出，仅通过受控接口暴露必要能力：
// auth/internal.ts const SECRET_KEY = 'dev-only-key-123'; // ✅ 模块内私有，外部不可访问 // 仅暴露安全封装后的函数 export function createToken(payload: object) { return btoa(JSON.stringify({ ...payload, key: SECRET_KEY })); } // ❌ 不导出 SECRET_KEY，杜绝直接引用风险// index.ts import { createToken } from './auth/internal.ts'; console.log(createToken({ user: 'admin' })); // ✅ 合法使用 // import { SECRET_KEY } from './auth/internal.ts'; // ❌ 编译/运行时报错：未导出2. 依赖注入替代硬编码依赖
当某配置或服务理应只被特定模块消费时，显式传入而非全局导出：
立即学习“Java免费学习笔记（深入）”；
// database.ts export class Database { constructor(private config: { host: string; port: number }) {} connect() { /* ... */ } } // index.ts import { Database } from './database.ts'; const db = new Database({ host: 'localhost', port: 5432 }); // ✅ 配置由使用者决定，解耦且可控3. 文件组织与命名约定强化意图
通过目录结构传递设计约束（虽无强制力，但提升可维护性）：
src/ ├── core/ # 公共可复用模块（谨慎导出） ├── app/ # 主应用逻辑 │ ├── index.ts # 入口，可导入 internal/* 下的非导出项 │ └── internal/ # 仅供 app/ 内部使用的模块（不导出关键数据） └── lib/ # 独立工具库（严格按需导出）⚠️ 注意事项
- 不要尝试 hack 导出逻辑：例如动态 export、条件导出或运行时检查 import.meta.url——这破坏静态分析、影响 Tree-shaking，且在 Deno/Node ESM 中不可靠。
- typescript 不能替代运行时封装：private 仅作用于类型检查，编译后仍为公共属性；真正的封装必须基于模块作用域。
- Deno 与 Node.js 行为一致：二者均遵循标准 ES 模块规范，无扩展性访问控制语法。
总结
JavaScript 模块的“私有性”源于不导出（const x = …）而非导出限制。若需求本质是“某配置仅被 index.js 使用”，请将其移入 index.ts 本地作用域，或通过参数/构造器注入。架构上，优先思考“谁应该拥有这个数据？”而非“如何阻止别人 import？”。这才是符合现代 JS 工程实践的健壮封装方式。