Java中不应以异常替代错误码，因二者解决不同层面问题；业务失败应统一返回Result，仅在逻辑错误无法恢复时抛特定RuntimeException。
Java里不该用异常替代错误码——错误码和异常解决的是不同层面的问题，混用反而破坏可维护性。
什么时候该抛 RuntimeException？
仅当程序逻辑出现「本不该发生、无法恢复、需要立即修正」的情况时才抛运行时异常。比如传入 null 给一个明确要求非空的参数，或调用 list.get(100) 但列表只有 3 个元素。
- 典型场景：
IllegalArgumentException、NullPointerException、IndexOutOfBoundsException - 不要为「用户输错密码」「库存不足」这类业务可预期失败抛
RuntimeException - 这类异常不强制捕获，一旦漏处理，会直接崩掉调用链，线上难定位
业务错误该用 checked exception 还是自定义返回对象？
Java 的 checked exception（如 IOException）设计初衷是强制调用方处理「系统级不可控失败」，但业务错误（如支付失败、审核驳回）不是系统异常，而是正常流程分支。
- 强行用
throws BusinessException会导致大量try-catch套壳，接口膨胀、调用方被迫吞异常或无意义重试 - 更合理的方式是统一返回
Result类型，含code、message、data字段，让上层按code分支处理 - 如果非要封装异常，应只在 service 层内部用（如 DAO 抛出
DataAccessException），绝不透传到 API 层
throw new RuntimeException("xxx") 是最危险的写法
这种写法丢失了类型信息、无法区分语义、不能被精准捕获，等于把错误诊断权交给了日志里的字符串匹配。
立即学习“Java免费学习笔记（深入）”；
- 禁止在任何正式代码中写
new RuntimeException("订单不存在") - 需要表达「订单不存在」，应定义
OrderNotFoundException extends RuntimeException，并确保它只在真正「找不到」且无法继续执行时抛出 - 注意：Spring 的
@ResponseStatus和全局@ExceptionHandler依赖异常类型，字符串一模一样也救不了你
异常不是错误码的高级替代品，它是控制流的紧急出口。用错一次，排查成本翻倍；滥用一遍，整个模块的错误边界就模糊了。
