变量名不能以下划线或美元符开头/结尾
Java编译器允许 _name 或 name_ 这类写法，但阿里规范强制禁止——不是语法错误，而是团队协作的“隐形雷”。很多IDE（如IntelliJ）默认会标黄警告，CI流水线里用alibaba-java-coding-guidelines插件也会直接报错。
- 反例：
_userId、count$、data_—— 看似无害，实则破坏命名一致性，还容易和自动生成代码（如Lombok、MyBatis动态代理）冲突 - 正例：
userId、totalCount、cacheKey—— 全部小写字母开头，后续单词首字母大写 - 特别注意：
$在字节码层面有特殊含义（编译器生成的合成变量常用），人为使用易引发反射失败或序列化异常
布尔类型变量别加 is 前缀
这是POJO里最常踩的坑，表面看 isDeleted 读起来顺，但Spring、Dubbo、Jackson等框架靠JavaBean规范推导属性名，会把 isDeleted() 方法映射成字段 deleted，而实际字段名却是 isDeleted，导致值始终为null或false。
- 反例：
private Boolean isLocked;→ getter是isLocked()→ 框架找字段locked，找不到，赋值失败 - 正例：
private Boolean locked;→ getter是isLocked()→ 字段名与方法推导一致 - 数据库字段如果是
is_deleted，用@TableField("is_deleted")或@JsonProperty("is_deleted")显式指定映射，不要迁就字段名改Java变量名
常量必须全大写+下划线，且语义完整
MAX_COUNT 看着干净，但没人知道是“库存上限”还是“重试次数上限”。阿里强调“不要嫌名字长”，因为线上出问题时，排查日志里看到 ORDER_TIMEOUT_SECONDS 比看到 TIMEOUT 少翻三页代码。
Java Maven 项目审查工作流的通用输入处理。当 Java Maven 项目以 ZIP压缩包或 GitLab 仓库 URL 形式提供且需要...时使用。
- 反例：
DEFAULT、BUF_SIZE、ERR_CODE—— 缺少上下文，多人协作时极易重复定义或误用 - 正例：
DEFAULT_HTTP_CONNECT_TIMEOUT_MILLIS、REDIS_CACHE_EXPIRE_SECONDS—— 类型+作用+单位全在名字里 - 注意：
static final才算常量；局部变量即使全大写也不受此约束，但建议统一风格避免混淆
别用拼音混搭，英文拼错比不用英文更危险
getPingfenByName() 不是“错”，而是让外国同事、开源贡献者、甚至半年后的你自己，第一眼得停顿半秒去解码。更麻烦的是，拼音容易拼错（zhuce 还是 zhuzhe？），而英文单词拼错（recieve）会导致IDE无法自动补全，还可能被当成另一个变量。
立即学习“Java免费学习笔记（深入）”；
- 反例：
shouJiHao、userZhangHu、chengJi—— 中文思维残留，团队新人上手成本陡增 - 正例：
phoneNumber、userAccount、score—— 用真实英文词，查字典/问ChatGPT都比猜拼音靠谱 - 例外：国际通用缩写可直接用，如
url、id、xml、http，但uid要写成userId（除非领域内已广泛接受uid）
最容易被忽略的其实是“包名单数”和“类名可复数”这条：写 com.example.util.DateUtils 没问题，但包不能叫 utils；而 UserServices 是错的，得是 UserServiceImpl —— 名字看着小，改起来要动import、动配置、动测试，真上线了再改就不是命名问题，是发布风险了。
