字符串比较应使用equals而非==，因==比较引用地址；循环中修改ArrayList需用迭代器remove或延迟删除；Integer等包装类比较须用equals且注意缓存范围与空指针；异常不可裸吞，须记录日志；日期处理优先用Java 8+时间API；HashMap应预设初始容量；SimpleDateFormat不可共享；异步任务须处理异常并等待完成；浮点数比较应使用误差范围判断。
字符串比较不用 equals 却用 ==
新手常写 "abc" == str 判断内容是否相等，结果在某些情况下对、某些情况错。因为 == 比的是引用地址，而字符串字面量可能被 JVM 缓存（在字符串常量池里），但 new String("abc") 就一定不等于 "abc"。正确写法永远是 str != null && str.equals("abc")，更安全可用 "abc".equals(str) 避免空指针。
循环中修改 ArrayList 导致 ConcurrentModificationException
一边遍历 ArrayList，一边调用 list.remove()，哪怕只是删一个元素，也会直接抛异常。这不是线程问题，而是 fail-fast 机制在起作用。解决办法：用迭代器的 iterator.remove()；或先收集要删的元素，遍历完再批量删；或改用 CopyOnWriteArrayList（仅适合读多写少场景）。
忽略自动装箱拆箱的坑
写 Integer a = 128, b = 128; System.out.println(a == b); 输出 false —— 因为 Integer 缓存范围是 -128 到 127，超出就新建对象。同样，Integer c = null; int d = c; 运行时直接 NPE。比较包装类用 equals，赋值前务必判空，基本类型运算前确保非 null。
try-catch 吞掉异常却不处理也不记录
常见写法：catch (Exception e) { } 或只写 e.printStackTrace();。前者让错误静默失败，后者日志没进系统日志体系，线上根本查不到。正确做法：记录带上下文的 warn/error 日志（用 SLF4J），必要时重新抛出或封装成业务异常，绝不裸吞。
立即学习“Java免费学习笔记（深入）”；
日期处理用 Date 和 Calendar 硬刚
new Date(2023, 1, 1) 其实是 2024 年 2 月 1 日（月份从 0 开始）；Calendar 的 set 和 add 行为容易混淆；时区、夏令时、跨年计算全是雷。Java 8 起请直接用 LocalDateTime / ZonedDateTime / DateTimeFormatter，不可变、线程安全、API 清晰。
HashMap 初始化不设初始容量
默认容量 16，加载因子 0.75，意味着放 13 个元素就扩容。频繁扩容（rehash）很耗时。如果预估要存 1000 个键值对，建议初始化写成 new HashMap(1280)（1000 ÷ 0.75 ≈ 1334，向上取 2 的幂得 2048，但 1280 更省空间且够用）。
把 SimpleDateFormat 当共享变量用
声明为 static 成员、多个线程共用同一个实例，必现解析错乱或报错。SimpleDateFormat 不是线程安全的。方案有三：方法内局部创建（轻量，推荐）；用 ThreadLocal 包裹；换成线程安全的 DateTimeFormatter（Java 8+）。
异步任务忘了处理异常或等待完成
写 executor.submit(() -> { riskyCode(); }); 后不管不问，异常被吃掉，主线程也完全不知道任务失败。submit 返回 Future，必须调用 future.get()（会阻塞并抛出执行异常）；或者用 CompletableFuture 链式处理异常（.exceptionally / .handle）。
用 == 比较浮点数
double a = 0.1 + 0.2; if (a == 0.3) {...} 几乎永远为 false。浮点数有精度误差。正确方式是用差值绝对值判断：Math.abs(a - 0.3) ；金额等关键场景一律用 BigDecimal。
静态方法/变量滥用导致内存泄漏
把 Activity、Context、View 等持有强引用塞进 static Map 或 static List，Android 里极易引发 OOM；Java SE 中也可能让本该回收的对象无法 GC。原则：静态容器只存生命周期长、无依赖的对象；必须存短生命周期对象时，用 WeakReference 包裹。
JSON 序列化忽略 null 字段却没配好框架
以为 Jackson 默认不输出 null，结果发现还是打了 "field": null。其实是默认行为是输出 null；需显式配置 objectMapper.setSerializationInclusion(JsonInclude.Include.NON_NULL)。Gson 同理要 setExclusionStrategies。
流式操作（Stream）中途修改原集合
写 list.stream().filter(...).forEach(list::remove); 会抛 ConcurrentModificationException。Stream 不是“另一个 for 循环”，它背后仍基于原集合迭代。要删元素，请用 removeIf 或收集新集合再替换。
接口实现类没加 @Override 却写错了方法签名
比如接口定义 void save(User user)，实现类写了 public void save(User u)，看着像重写，其实成了重载——接口方法根本没被实现，运行时报 AbstractMethodError。加上 @Override 注解，编译器立刻报错提醒。
文件流没关闭，也没用 try-with-resources
写 FileInputStream fis = new FileInputStream("x.txt"); ... fis.close();，但中间抛异常，close 就跳过了。资源泄露长期运行必崩。Java 7+ 必须用 try (FileInputStream fis = ...) { ... }，异常时自动 close，连 finally 都不用写。
用 Arrays.asList() 返回的 List 做增删操作
List
并发修改 HashSet / HashMap 不加同步
多线程往同一个 HashMap put，即使没显式同步，也可能导致死循环（JDK 7 链表成环）、数据丢失或扩容异常。别迷信“我只读不写”——读操作也可能触发 resize。要用 ConcurrentHashMap，或 Collections.synchronizedMap()（注意迭代仍需手动同步）。
异常捕获太宽泛，掩盖真正问题
写 catch (Exception e) 处理所有异常，结果 IOException、NullPointerException、IllegalArgumentException 全被同一段逻辑吞掉，排查时完全分不清是网络超时还是参数错了。应按业务分层捕获：底层抛具体异常，上层按需 catch 并分类处理。
单元测试只测 happy path，不覆盖边界和异常分支
比如测试一个除法方法，只传 10/2，不试 10/0、null 参数、负数输入、超大数溢出。结果上线后遇到 0 除直接崩。JUnit 5 推荐用 @ParameterizedTest 覆盖多组输入，用 @Test(expected = ArithmeticException.class) 或 assertThrows 验证异常路径。
随意使用 System.out.println 调试，上线忘记删
控制台打印混进生产代码，不仅污染日志，还可能泄露敏感信息（用户 ID、token、SQL 参数）。所有调试输出必须用日志框架（SLF4J + Logback），且日志级别设为 DEBUG，并确保生产环境日志级别为 INFO 或更高。
final 字段初始化顺序搞错导致值为 null
父类构造器里调用了被子类重写的 final 方法，而该方法访问了子类的 final 字段——此时子类字段还没初始化，值为 null。根源是 Java 构造顺序：父类构造器先执行，子类字段后赋值。避免在构造器中调用可被重写的方法，尤其涉及未初始化字段时。
基本上就这些。不复杂，但容易忽略。踩过一遍，下次看到类似代码本能警觉，就是新手走向靠谱开发者的开始。
