模块化开发中变量暴露边界的本质是按需开放访问权限：包内用default实现高内聚协作，继承体系用protected+private控制能力边界，对外服务用public配合校验与防御性拷贝，再通过module-info.java二次过滤导出包。
模块化开发中变量暴露边界的本质，是让每个模块只向需要它的对象“开一扇合适的门”，而不是把所有门都敞开或全锁死。关键不在单个修饰符怎么用，而在于它们如何组合配合业务场景——比如包内协作、继承复用、对外服务这三类典型需求。
同一业务包内：用default（无修饰符）建立高内聚协作
当订单、订单项、支付三个类同属com.example.order包时，它们之间共享中间计算逻辑或临时状态字段是合理且必要的。这时不加任何修饰符的default权限就是最佳选择：
- 字段如
BigDecimal calculatedTax可设为default，供包内其他类读取但不对外暴露 - 工具方法如
validateOrderItems()也用default，避免被跨包误调用，又不用重复实现 - 一旦有类移出该包，自动失去访问权，边界清晰，无需额外维护
继承体系中：用protected + private组合控制子类能力边界
父类不能直接暴露字段给子类，否则会把实现细节钉死；但又要让子类能复用核心逻辑。推荐做法是：
- 敏感字段保持private，如
private Connection dbConn - 提供protected方法封装操作，如
protected void executeWithRetry(Runnable task) - 子类可调用或重写该方法，但无法绕过重试逻辑直接操作连接
- 避免使用protected字段——它会让子类和父类强耦合，改一个就可能崩一片
对外服务接口：public方法必须带校验与防御性拷贝
public不是“放行章”，而是“守门员”。哪怕只是一个getter，也要考虑外部是否能借此破坏内部状态：
-
public List<orderitem> getItems()</orderitem>要返回Collections.unmodifiableList(items)，而非原始引用 -
public void setDiscount(BigDecimal discount)必须检查discount != null && discount.compareTo(BigDecimal.ZERO) >= 0 - 不为private字段机械生成getter/setter，只暴露真正需要被外部读写的语义属性
- 校验失败抛
IllegalArgumentException，不静默吞掉错误
模块级封装：结合module-info.java做二次过滤
即使类内部用了public，模块系统也能再拦一道。在module-info.java中精确导出接口包：
- 只
exports com.example.order.api;，隐藏com.example.order.internal所有实现 - 即便某public类意外暴露了不该有的方法，只要没导出所在包，外部模块连类名都加载不到
- 运行时反射访问非导出包会触发
IllegalAccessError，安全边界更硬
