命名规范是提升代码可读性、协作效率和维护性的工程实践，通过语义化命名（如userName、validateEmailFormat）、统一风格（小驼峰、大驼峰、全大写）及角色约定（类名UserService、方法isExpired、常量DEFAULT_TIMEOUT_MS），使代码自解释、降低理解成本。
因为名字不是随便起的，它直接决定别人能不能看懂你的代码、愿不愿意帮你改bug、敢不敢接手你写的模块。
让代码自己会说话
变量叫 userName，比叫 un 或 a1 清楚十倍；方法叫 calculateTotalPrice()，比 doSomething() 更让人安心。命名规范的本质，是用自然语言逻辑去映射程序逻辑——不用翻上下文，光看名字就能猜出用途。
- 类名 UserService → 知道这是个服务类，处理用户相关逻辑
- 方法名 validateEmailFormat() → 知道它干啥，也大概知道它该返回 boolean
- 常量 DEFAULT_TIMEOUT_MS → 知道是数字、是毫秒、是默认值、不能改
团队协作不靠猜，靠统一
一个人写代码可以随心所欲，十个人一起维护一个项目时，风格混乱就是灾难。命名规范就是团队的“通用词典”：看到 xxxController 就知道是 Spring Web 层，看到 xxxMapper 就想到 MyBatis 接口，看到 isExpired() 就默认返回 boolean。
- 新人第一天入职，扫一眼包结构 com.example.order.service 就能定位业务主干
- Code Review 时， reviewer 不用纠结 “这个 flag 到底代表什么”，因为规范要求它必须叫 isPaymentConfirmed
- IDE 自动补全更准，user 按 tab 出来的全是 userId、userName、userStatus，而不是一堆 u1、tmp、obj
维护成本从“改一行怕崩一片”降到“改得放心”
三年前写的 getData()，现在没人记得它查的是缓存、DB 还是远程接口；当年随手写的 list 变量，今天不确定它是 List<User> 还是 List<String>。命名含糊，等于埋雷。规范强制你把语义写进名字里，等于给未来自己留了注释。
立即学习“Java免费学习笔记（深入）”；
- 避免 list → 改成 activeUserList 或 pendingOrderIds
- 避免 handle() → 改成 handleOrderCancellation()
- 避免 config → 改成 databaseConnectionConfig
不是教条，是经过验证的工程习惯
Oracle 官方 JDK、Spring、Apache、Alibaba 的所有开源项目，都严格遵守这套命名体系。这不是某家公司拍脑袋定的，而是几十年 Java 工程实践中沉淀下来的共识：小驼峰、大驼峰、全大写下划线，每种形式对应明确的语义角色，混用就会破坏直觉。
- 包名全小写（com.example.auth）→ 表示层级和归属，大小写敏感易出错
- 接口/类名大驼峰（ReadableByteChannel）→ 强调类型身份，和文件名强绑定
- 方法/变量小驼峰（readBytes() / bufferSize）→ 强调行为或状态，首字母小写是动词/名词的自然起点
- 常量全大写（MAX_RETRY_COUNT）→ 视觉上立刻区分不可变值，避免误赋值
基本上就这些。不复杂，但容易忽略。
