Java命名规范是协作与工具兼容的基石：类名用PascalCase，方法变量用camelCase，常量用UPPER_SNAKE_CASE，布尔方法必须isXxx()，包名全小写+域名倒序，缩写需明确，否则引发可读性下降、工具推断错误及运行时绑定失败。
命名不规范直接导致团队协作卡壳
Java里变量、方法、类名不是“能跑就行”，而是影响别人能不能在5秒内看懂你这段逻辑。比如看到 getUserInfoById 立刻知道是查用户，而 getU 或 gub 得停下来猜三遍——这在Code Review或紧急修Bug时就是时间黑洞。
IDE和静态检查工具依赖命名做语义推断
IntelliJ 的自动补全、SonarQube 的规则扫描、甚至 Lombok 的 @Data 生成 getter/setter，都严格按 JavaBeans 规范解析命名。如果写个字段叫 XMLConfigFile，Lombok 可能生成出 getXMLConfigFile()，但部分框架（如 Spring Boot 的 @ConfigurationProperties）会期望 xmlConfigFile，结果绑定失败且报错不提示命名问题。
- 类名必须 PascalCase：
UserRepository✅，user_repository❌ - 方法/变量必须 camelCase：
isEmailValid✅，IsEmailValid❌（首字母大写会被当成类） - 常量必须 UPPER_SNAKE_CASE：
MAX_RETRY_COUNT✅，maxRetryCount❌（编译不报错，但违反约定且易被误用为变量）
缩写和布尔方法名是高频翻车点
很多人以为缩写省事，实际大幅降低可读性。比如 usrMgr 是 user manager？upload manager？USB manager？没人敢确定。布尔方法更危险：user.isActive() 自然，但 user.isAct() 或 user.getIsActive() 会让调用方怀疑自己记错了API。
public class User {
private String usrName; // ❌ 缩写模糊，IDE警告：'usr' is ambiguous
private boolean isActive; // ✅ 清晰表达状态
public boolean getIsActive() { // ❌ 违反 isXxx() 惯例，应改用 isActive()
return isActive;
}
}
包名小写+域名倒序不是教条，是避免冲突的硬约束
com.example.auth 看似多此一举，但一旦项目接入第三方 SDK（比如某支付库也用了 auth 作包名），没域名前缀就可能引发类加载冲突或 IDE 导包混乱。内部模块也建议细分：com.example.auth.jwt 和 com.example.auth.oauth2 比全塞进 auth 包里更利于定位问题。
真正容易被忽略的是：包名里出现大写字母（如 com.example.AuthService）会导致某些构建工具（如 Maven Shade 插件）路径处理异常，打包后类找不到。
