真实系统中异常管理需区分业务异常（如PaymentValidationException）与技术异常（如DatabaseConnectionTimeoutException），分别走友好提示或告警降级；资源清理优先用try-with-resources保障可靠性；异常须驱动决策闭环（如超时触发兜底、库存不足发补偿消息）；策略设计需权衡重试、熔断与用户体验。
面试官不看你会不会写 try-catch，而是看你在真实系统里怎么“管住”异常。
是否区分业务异常与技术异常
真正有经验的开发者，第一反应不是“捕获所有异常”，而是先问：这个异常是谁的责任？是用户输错了（业务异常），还是数据库连不上了（技术异常）？前者该友好提示、引导重试；后者得记录日志、触发告警、走降级流程。比如支付失败，抛出 PaymentValidationException 和 DatabaseConnectionTimeoutException 必须走不同处理路径——前者返回“银行卡余额不足”，后者返回“系统繁忙，请稍后再试”。混用 RuntimeException 一包到底，暴露的是设计意识缺失。
资源清理是否可靠且自动化
面试官会盯住你代码里资源释放的细节。手动在 finally 里 close 流？可以，但容易漏判 null 或嵌套异常；更优解是用 try-with-resources（Java）或 with 语句（Python），让语言层保障关闭。如果看到你写“catch 后 return，finally 里又 throw 新异常”，他会立刻追问：“上层拿到的是哪个堆栈？原始错误信息丢没丢？”——这直接关联线上问题定位效率。
异常是否参与系统决策闭环
高手和新手的关键分水岭：异常不只是日志里的一行红字。它要能驱动行为。例如： • 连续 3 次 Redis 超时 → 自动切换到本地缓存兜底； • 订单创建抛出库存不足异常 → 触发补偿消息，通知上游释放预占； • 调第三方 API 返回 429 → 动态调整重试间隔并上报限流指标。 如果你只说“我 catch 了然后打日志”，面试官会默认你还没进过真实高并发场景。
能否讲清异常策略背后的权衡
他可能突然问：“你们订单服务里，对 DB 异常是立即熔断，还是允许 5 秒内重试 2 次？”这不是考标准答案，而是看你有没有思考过： • 重试会不会放大雪崩风险？ • 熔断窗口设太短，误伤正常流量；设太长，故障恢复慢； • 用户感知延迟 vs 系统可用性，哪个优先级更高？ 能拿出自己项目里的监控截图、降级开关配置、A/B 测试数据来佐证判断，比背概念强十倍。
