核心是通过模块边界、显式导出控制和构建时约束协同实现非公开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)，把风险隔离在门禁内
大量免费API接口：立即使用
涵盖生活服务API、金融科技API、企业工商API、等相关的API接口服务。免费API接口可安全、合规地连接上下游，为数据API应用能力赋能！
