核心是通过模块边界、显式导出控制和构建时约束协同实现非公开API变量“不可见”。严格限制export仅含稳定契约，禁用default导出，用函数替代可变变量导出，配合ESLint、TS配置及门禁文件统一管控出口。

核心是让非公开api变量“不可见”，而非仅靠命名约定或文档提醒。真正有效的限制依赖模块边界、显式导出控制和构建时约束三者协同，而不是寄希望于开发者自觉。

只暴露契约，不暴露实现路径

非公开API变量（如内部状态、临时缓存、调试开关、未完成的实验性函数）必须严格保留在模块内部，不参与任何 export 声明。哪怕只是临时写个 const DEBUG = true，只要没被明确需要跨模块使用，就不该出现在导出列表里。

• 检查每个 export 语句：它导出的是稳定接口，还是某个中间态的配置对象？后者极易被业务层直接读取并强依赖
• 避免导出带副作用的变量：例如 export let currentUser 或 export const paymentConfig = {...} —— 这类变量一旦被业务模块 import 并修改，会破坏封装性且难以追踪
• 用函数替代变量导出：需动态获取的配置，应导出 export function getPaymentConfig()，而非导出原始对象

禁用默认导出，强制命名导出

默认导出（export default）会让调用方随意重命名，掩盖其真实用途；而命名导出要求调用方使用统一标识符，便于代码审查与自动化识别。

• 把所有导出项改为具名形式：export const validateOrder、export type OrderInput
• 在顶层 api.ts 中只做 re-export，不新增逻辑；禁止在 api.ts 里写 export default { ... }
• 配合 TypeScript 的 declare module 或 JSDoc @public 标记，进一步声明哪些类型/函数属于对外契约

构建时拦截未授权访问

语法层面的限制无法阻止运行时反射或误导入，必须靠工具链在构建阶段卡住。

• 启用 ESLint 插件 import/no-unused-modules，自动报出未被任何外部模块 import 的导出项——这些往往是“本不该导出却误写了 export”的变量
• CI 流程中加入模块图扫描（如 depcheck 或自定义 AST 分析），检测是否出现 reporting 模块 import 了 payment/internal 下的变量
• 配置 TypeScript 的 noUnusedExports: true 和 isolatedModules: true，让编译器拒绝构建含冗余导出的代码

用顶层门禁文件统一管控出口

不许业务模块直接 import 底层路径，所有访问必须经过 src/api/index.ts（或 api.ts）这一道门禁。

• 底层目录（如 ./core/、./utils/）全部设为私有，禁止在 package.json 中声明 "exports" 映射到它们
• api.ts 只写白名单式 re-export：export { submitOrder } from './core/order-flow';，不暴露 ./core/order-flow/internalHelpers
• 必要时加轻量包装层：export const safeSubmitOrder = wrapWithTimeout(submitOrderRaw)，把风险隔离在门禁内