团队开发中访问修饰符需严格对应协作意图：字段全private+final、敏感数据设校验入口；方法按调用关系分层（public/default/protected/private）；包结构即权限地图，default是模块隔离主力；顶层类与构造器权限须规范。
团队开发中访问修饰符用得随意，本质是权限边界模糊——不是语法不会用，而是没把“谁该调谁”变成可执行的协作契约。规范标准的关键，在于让每个修饰符对应明确的协作意图，而不是凭感觉加 public。
字段一律 private，改数据必须走校验入口
成员变量不设例外，全部声明为 private。这不是防同事，而是防误用和绕过业务规则。
- 敏感字段（如用户余额、token）加
final，只提供带校验逻辑的setXXX()，比如金额变动前检查是否为负数 - 纯内部状态（如重试计数器、解析缓存）连 getter 都不暴露，避免被其他类当成“可用字段”直接读写
- DTO 或 VO 中的字段若需外部读取，用
public final+ 构造器初始化，不给修改入口
方法按调用关系分层，不按“要不要写测试”定权限
方法的修饰符要反映它实际被谁调、为什么调，而不是“我先 public 着，后面再改”。
-
对外服务入口：Controller 方法、Service 主流程、工具类核心能力 →
public -
包内协作支撑：DAO 封装、DTO 转换、状态校验工具 → 不写修饰符（
default），跨包调用直接编译报错 -
继承扩展点：父类预留钩子（如
beforeSave()）→protected，且 JavaDoc 必须写明“供子类重写” -
纯本类实现细节：字符串拼接、日志格式化、参数预处理 →
private，不参与任何跨类交互
包结构即权限地图，default 才是模块隔离主力
default 不是被遗忘的默认值，而是靠包划分才能生效的协作协议。没有清晰包结构，default 就等于失效。
立即学习“Java免费学习笔记（深入）”；
- 每个业务域建独立包，例如
com.company.order.entity、com.company.order.infra - 包内通用的异常类、常量类、转换器类，统一用
default修饰，禁止导出到其他包 - 严禁出现
com.company.util这类大杂烩包；否则default失去约束力，变成“伪私有”
构造器和顶层类权限不能妥协，IDE 报错前先立规矩
这些地方权限错误会导致编译失败或隐性耦合，必须在编码规范里写死。
- 顶层类只允许
public或default；public类名必须与文件名一致，一个文件仅一个 - 普通对象构造器设为
public；仅限继承创建的设为protected；单例或 Builder 内部使用才用private - 禁止对非内部类使用
protected或private—— IDE 会标红，但规范文档要提前写明，避免新人反复踩坑
