关键在于从代码边界、作用域控制和接口契约三方面同步发力：明确按业务能力组织模块、封闭内部状态、通过抽象接口通信，并利用语言特性强化封装。
要利用模块化强封装特性构建高内聚业务模块、防止变量和逻辑外溢，关键在于从代码边界、作用域控制和接口契约三方面同步发力。不是简单拆分文件，而是让每个模块真正“自洽”——内部能闭环处理一件事，外部看不见也不需要知道它的中间状态。
明确模块边界，按业务能力而非技术角色组织
避免把 controller/service/dao 按层横向切开导致业务逻辑被撕裂。例如订单相关功能应全部收拢在 com.example.order 包下，包含：
- 领域模型（Order、OrderItem）
- 核心服务（OrderService，只暴露 Create、Cancel、Query 等语义明确方法）
- 本地仓储接口（OrderRepository）及内存/DB 实现（不对外暴露 SQL 或 ORM 细节）
- 事件定义（OrderPlacedEvent）及其发布机制（不暴露 EventBus 实例）
模块内部可自由分层，但对外仅通过一组精炼接口通信，所有中间变量、临时状态、转换逻辑都封闭在模块内部。
用封装机制切断变量外泄路径
变量外溢往往源于暴露了不该暴露的字段或返回了可变对象。实战中需主动拦截：
- 实体类字段一律 private，提供不可变 getter（如返回 List.copyOf(items) 而非直接返回 ArrayList）
- 禁止 public static 变量或全局配置对象跨模块引用；统一由模块内 Configuration 类加载并缓存
- 避免在接口中返回 Map
这类弱类型结构；改用具名 DTO 或 record 类型（如 OrderSummary） - 使用 final 修饰模块内核心状态对象，构造后不再允许外部修改
靠接口契约约束跨模块协作
模块间交互必须经过抽象接口，且该接口只承诺“做什么”，不透露“怎么做”或“用什么做”。例如支付模块对外只声明：
interface PaymentGateway {PaymentResult charge(ChargeRequest request);
void refund(RefundRequest request);
}
订单模块调用时，完全不感知是调用了支付宝 SDK、还是本地模拟实现、或是异步消息队列。所有支付相关的变量（如支付宝的 alipayRequestId、签名密钥、重试次数）都被锁死在 PaymentGateway 的具体实现里，无法穿透到订单模块。
借助语言特性强化封装强度
不同语言有对应工具，用好能天然抑制外溢：
- Java 9+：用 module-info.java 声明 exports 仅限于 API 包，隐藏 internal.* 和 impl.*
- Go：将非导出标识符（小写首字母）用于内部变量与函数，包外不可见
- TypeScript：用 private/protected 修饰成员，配合 --noImplicitAny 和 strict 编译选项堵住类型逃逸
- JavaScript（ESM）：默认模块作用域封闭，不 export 即不可访问；避免在顶层声明 var/let
封装不是为了隐藏而隐藏，而是为了让变化可控。当一个模块的变量和逻辑不再“漏”出去，它才真正拥有了独立演进的能力。
