NullPointerException最常见，由对null引用调用方法或访问字段引发，须靠预防而非try-catch：用@NonNull、Objects.requireNonNull、Optional及IDE空值分析。
NullPointerException 最常见，只要对值为 null 的引用调用方法或访问字段就会触发。比如 String str = null; str.length(); —— 不是“字符串为空”，而是“字符串变量根本没指向任何对象”。
这类异常几乎全由逻辑疏漏导致，**不是靠 try-catch 解决的，而是靠预防**：
- 方法入参加 @NonNull 注解（配合 IDE 或 Lombok）
- 使用 Objects.requireNonNull(obj, "msg") 主动校验
- 优先用 Optional 封装可能为空的返回值，避免裸露 null
硬写 if (obj != null) 容易漏、难维护；而依赖 IDE 的空值分析（如 IntelliJ 的 nullability inference）能提前标红预警。
数组/字符串下标越界：ArrayIndexOutOfBoundsException 和 StringIndexOutOfBoundsException
本质是同一个问题：索引超出了合法范围 [0, length)。
常见翻车点：
- for (int i = 0; i —— 多循环一次，<code>i == arr.length 时越界
- str.charAt(str.length()) —— 字符串最大有效索引是 length() - 1
- 用 substring(5, 10) 但原字符串只有 7 个字符
解决不靠捕获，靠**边界检查前置化**：
- 遍历用 for (int i = 0; i （死记：用 <code>，不用 <code>）
- 截取前先判断长度：<code>if (s.length() >= 10) s.substring(0, 10);
- 工具类如 StringUtils.substring()（Apache Commons）会静默截断，不抛异常
数字解析失败：NumberFormatException
典型场景：Integer.parseInt("abc") 或 Integer.parseInt("123.45")。
它不区分“非数字字符”和“格式不符”，只要不能严格转成目标类型，就炸。
别用 try-catch 做流程控制（性能差、掩盖逻辑问题），改用：
- Integer.valueOf(String) 仍会抛异常，不推荐
- 正则预判：str.matches("-?\d+") 判断是否为整数字符串
- 更稳妥：用 Apache Commons Lang 的 NumberUtils.toInt(str, defaultValue)，失败直接回退默认值
- Java 17+ 可考虑 Integer.parseUnsignedInt() 等更明确语义的方法（但依然会抛异常）
类型强转出错：ClassCastException
发生在运行时向下转型失败，例如：Object obj = "hello"; Integer i = (Integer) obj;。
编译器不报错（因为语法合法），但 JVM 运行时发现实际类型不匹配，立刻抛异常。
关键预防手段：
- **尽量避免显式强制转型** —— 多态、泛型、接口抽象能消除大部分转型需求
- 必须转时，先用 instanceof 检查：if (obj instanceof Integer) { int i = (Integer) obj; }
- 使用泛型集合（如 List<string></string>）代替原始类型 List，从源头杜绝转型
- 注意：JDK 14+ 的模式匹配（if (obj instanceof String s)）可一步完成检查+赋值，更安全简洁
真正棘手的不是这些异常本身，而是它们往往藏在深层调用链里——比如 DAO 层返回了 null，Service 层没判空，Controller 层直接调用 .toString()，堆栈一打十几层。所以防御性编程要贯穿每一层，而不是指望最外层一个 try-catch 兜底。
