大家好，我是晚安code。

说到 Ja va编程规范，很多同学第一反应是"条条框框，烦死了"。但阿里《Ja va 开发手册》里的【强制】规约，几乎每一条都是拿线上故障换来的（以 1.7.1 黄山版、2022 年 2 月版本为准）。

这篇我把手册里最容易让项目翻车的 15 条【强制】规约筛出来，按命名、日期数值、集合、并发、数据层五类整理成一份避坑清单，每条都配反例和事故场景。建议先收藏，下次 code review 前翻一遍。

一、命名：别让名字埋雷（Ja va命名规范）

命名不只是好不好看的问题——名字起错，框架解析都可能翻车。这套 Ja va 命名规范里有三条最致命：

坑 1：Boolean 字段加 is 前缀。 反例是 private Boolean isDeleted，getter 自动生成 isDeleted()，序列化时框架反解析"误以为"字段叫 deleted，结果字段直接丢失，前端拿到的 JSON 里永远少这一个。正确写法是 private Boolean deleted。

坑 2：拼音和英文混排。 反例 DaZhePromotion（打折）、getPingfenByName()（评分），读代码跟猜谜一样。手册明确要求：命名用完整英文单词组合，纯拼音也不行。

坑 3：魔法值直接写死。 有次我 debug 一个缓存查不到的 bug 查了一下午，最后发现是两个 key 一个带了下划线一个没带——开发者 A 写 "Id#taobao_" tradeId，开发者 B 复制时少了个下划线。这就是魔法值的代价：

// 反例：魔法值直接写死，复制时少个下划线就出事故String key = "Id#taobao_"   tradeId;// 正确：定义成常量public static final String CACHE_KEY_PREFIX = "Id#taobao_";

魔法值（Magic Number）：直接硬编码在代码里、没有任何说明的常量。就像卷子上随手写的中间结果，只有出题人自己看得懂。

二、日期与数值：翻车率最高的两类（Ja va日期格式化、Ja va浮点数精度）

日期和数值是 Ja va 里翻车率最高的两类，而且坑都很"安静"——不报错，就是结果不对。尤其是 Ja va 日期格式化，跨年那几天必现。

坑 4：YYYY 和 yyyy 别混。 小写 yyyy 是"当天所在的年"，大写 YYYY 是"当天所在周属于的年份"。2017 年 12 月 31 日用 YYYY-MM-dd 格式化，得到的是 2018-12-31，线上日志和报表日期全线错位。正确写法是：

new SimpleDateFormat("yyyy-MM-dd HH:mm:ss") // 正确new SimpleDateFormat("YYYY-MM-dd HH:mm:ss") // 反例：跨年必翻车

坑 5：SimpleDateFormat 线程不安全。 这个类不是线程安全的，别定义成 static 共享，多线程下偶发解析错乱。JDK8 之后直接换 DateTimeFormatter，官方评价就是 immutable、thread-safe。

坑 6：浮点数别用 == 比较。 二进制没法精确表示大部分小数，1.0F - 0.9F 和 0.9F - 0.8F 用 == 比，结果是 false。这就像用十进制写 1/3，永远是 0.333… 写不完。要么给个误差范围，要么用 BigDecimal：

// 反例if (a == b) {} // a=1.0F-0.9F，b=0.9F-0.8F，结果为 false// 正确：指定误差范围if (Math.abs(a - b) < 1e-6F) {}

坑 7：BigDecimal 比较数值时，务必用 compareTo 而非 equals。equals 方法不仅比较数值，还比较精度，这会导致 new BigDecimal("1.0").equals(new BigDecimal("1.00")) 返回 false，而 compareTo 则忽略精度差异，符合常规数值比较的预期。此外，构造 BigDecimal 时严禁使用 double 参数（如 new BigDecimal(0.1)），因为 double 本身存在精度损失；正确做法是使用字符串构造函数或 valueOf 方法。

三、集合操作：一半事故出在这（Ja va集合遍历）

集合操作贡献了 Ja va 运行时异常的一大半，而且大部分是同一个套路——边遍历边改。这一节的坑全是【强制】级：

再来看第 8 个坑：在 foreach 循环中直接删除元素。很多人没意识到，foreach 的底层实现其实是 Iterator。如果在遍历过程中直接调用 list.remove，轻则导致部分元素被跳过，重则直接抛出 ConcurrentModificationException。正确的处理方式应该是使用 Iterator 自带的 remove 方法，或者借助 JDK8 提供的 removeIf 功能。

// 反例for (String item : list) { if ("1".equals(item)) list.remove(item);}// 正确list.removeIf(item -> "1".equals(item));

坑 9：Integer 别用 == 比较。 -128 到 127 之间有 IntegerCache 复用对象，这个区间用 == 碰巧没问题；一旦超出，每次都是新对象，== 比的是引用，两个 128 直接不相等。统一用 equals 或 Objects.equals：

Integer a = 128;Integer b = 128;a == b;// false！别问，问就是踩过a.equals(b); // true

坑 10：Arrays.asList 不能增删。 它返回的是 Arrays 内部类，add、remove、clear 一律抛 UnsupportedOperationException，而且它只是数组的"视图"，改数组或改 list 会互相影响。

坑 11：subList 不能强转 ArrayList。 subList 返回的是内部类 SubList，强转会抛 ClassCastException；它是对原列表的视图，之后你再动父集合，子列表遍历就会 ConcurrentModificationException。

四、并发：线程池和锁的坑（Ja va线程池）

并发场景下用 Executors 图省事，是 Ja va 里性价比最高的"自杀方式"。

坑 12：别用 Executors 创建线程池。 newFixedThreadPool 的队列容量是 Integer.MAX_VALUE，newCachedThreadPool 的线程数上限也是 Integer.MAX_VALUE——高并发一冲进来，任务只进不出，内存直接打爆 OOM。正确姿势是用 ThreadPoolExecutor 手写参数，配有界队列和拒绝策略：

线程池（Thread Pool）：预先创建一批线程复用来执行任务的技术。可以理解为「工地上随时待命的搬运工」。

坑 13：ThreadLocal 用完要清理。 线程池里的线程会被复用，ThreadLocal 存的值就像贴在公司工位上没撕的便签，下一个任务照样看得见。轻则数据串线，重则内存泄漏。规范要求用 try-finally 包起来，最后 remove()。

五、POJO 与接口：数据层的细节

POJO 里用基本类型，等于给 NPE 留了一扇随时会开的大门。

坑 14：POJO 属性必须用包装类型。 数据库查出来可能为 null，用基本类型 int 接收，自动拆箱当场 NPE；RPC 失败返回 null，用包装类型还能表达"调用失败"这个额外信息，页面显示一个中划线而不是错误的 0%。所以规约是：POJO 属性和 RPC 参数返回值用包装类型，局部变量才用基本类型。

POJO（Plain Old Ja va Object）：普通 Ja va 对象，通常指 DO、DTO、VO 这类承载数据的类。可以理解为「专门装数据的快递箱」。

坑 15：超大整数返回前端用 String。 Ja va 的 Long 最大能到 2^63-1，但 Ja vaScript 的 Number 只能精确表示 2^53 以内的整数。订单号 16 位以上直接丢精度——后端传 362909601374617692，前端收到 362909601374617660，前后端对不上账。有次同事调我接口，前端说订单号对不上，最后定位到就是这个原因。服务端一律用 String 返回这类超长 ID。

看这张表就明白了：很多人被 HashMap 带偏，以为 ConcurrentHashMap 也能存 null，实际存了直接 NPE。

说白了，这套 Ja va编程规范里的强制规约不是给你添麻烦，而是把别人花真金白银踩过的坑提前标了出来。写代码前多问一句"这名字规范吗、这个比较能用 == 吗"，就能省下大半年排查线上故障的时间。

我是晚安code，持续分享编程干货。觉得有用的话记得点赞收藏和关注~也欢迎在评论区聊聊：这 15 条规约里，你亲自踩过哪一个？踩的时候排查了多久？

《夸克》非常好用的免费AI浏览器

下载APP查看