Java访问修饰符与命名规范共同构成代码治理支柱：修饰符管控访问权限，命名体现语义意图；需遵循最小暴露原则，配合CI检查、IDE模板与代码审查等机制保障落地。
Java 中访问修饰符本身不负责命名，但它和命名规范共同构成团队代码治理的两大支柱：修饰符管“谁能用”，命名规范管“怎么叫”。二者配合得当，才能让代码既安全又易懂。
权限控制要遵循最小暴露原则
团队应统一约定字段、方法、类的默认修饰符级别，并严格限制提升权限的场景：
- 所有字段优先声明为 private，禁止裸露 public 或 protected 字段
- 需要子类扩展的方法才用 protected，且必须有明确文档说明重写契约
- default（包私有）用于同包内协作组件，比如内部工具类、缓存管理器，不对外暴露
- public仅限真正对外提供的服务入口，如 Controller 方法、SDK 核心接口、工具类静态方法
- 构造器一般与类保持相同可见性；若类是 public，构造器也应是 public，除非刻意设计为不可实例化（如工具类加 private 构造器）
命名需与修饰符语义对齐
变量或方法的名称应暗示其作用域和用途，避免名不副实：
Java 接口排错助手
下载
在调试 Java 后端 API 故障时使用此技能，尤其适用于以下任务：分析日志、跨 Controller、Service 和 Mapper 层追踪请求、定位异常根因、检查 SQL 执行或参数流转，以及生成简洁的诊断结论与修复方案。
- private 字段不加前缀（如 userName），避免旧式 mUserName 或 _userName，干扰阅读
- protected 字段若存在，可统一加 m 前缀（如 mConfig），提醒开发者这是“可能被子类依赖的共享状态”
- public 方法名体现契约性，例如 calculateTotal() 比 doCalc() 更清晰；避免使用 impl、helper 等模糊后缀
- 布尔型 private 字段推荐以 is/has/can 开头（如 isActive、hasPermission），getter 自动匹配 JavaBean 规范
- 常量（static final）必须全大写+下划线（如 DEFAULT_TIMEOUT_MS），且集中定义在专用常量类中，不散落各处
配套机制保障规范落地
光靠约定不够，需技术手段兜底：
- 在 CI 流程中接入 Checkstyle 或 SonarQube，强制校验：private 字段无 getter/setter、public 方法有 Javadoc、常量命名合规等
- IDE 模板统一配置：新建字段默认生成 private，新建方法默认不加修饰符（触发 default 检查），public 类必须带 package 声明
- 代码审查清单明确列出检查项，例如：“是否每个 public 方法都有 @param/@return 注释？”、“是否存在未封装的 public 字段？”
- 新成员入职时提供《团队 Java 规约速查卡》，含修饰符对比表、命名示例、反例截图
修饰符不是语法装饰，而是团队协作的契约信号；命名不是文字游戏，而是意图的直接传达。把这两件事做扎实，代码就自然具备可读性、可维护性和扩展韧性。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
