单条数据独立try-catch是批量容错核心，即每条数据包裹独立try-catch块，捕获后记录失败详情（id、错误类型、消息、时间戳）并continue；按错误分级响应：可恢复错误跳过或重试，数据级错误归类校验失败，系统级错误立即中断；结构化返回failures列表，http 200返回整体成功状态。
单条数据独立 try-catch 隔离失败
不要把整个 for 循环或批量处理逻辑包在一个大 try-catch 里。每条数据的处理必须包裹自己的 try-catch 块，确保一条出错不影响其余数据执行。例如：
- 对每个 process(data) 调用单独捕获异常，记录后直接 continue
- 避免在循环外 catch 异常并 throw，否则整批中断
- 推荐记录：数据唯一标识（如 ID）、错误类型（如 SQLState）、简要消息、时间戳
按错误语义分级响应
不是所有异常都该跳过。需结合业务判断是否可恢复、是否脏数据、是否系统级故障：
- 可恢复错误：网络超时、锁冲突、下游抖动 → 记录后跳过，或加入延迟重试队列
- 数据级错误：邮箱格式非法、主键重复、字段为空 → 明确归类为“校验失败”，不入库，保留原始输入（脱敏）便于排查
- 系统级错误：数据库连接断开、磁盘满、内存溢出 → 立即终止批次，触发告警，防止雪崩
结构化返回失败详情
调用方需要知道“谁没干成、为什么没干成”，不能只返回模糊统计：
- 定义统一响应结构，例如：{"successCount": 997, "failures": [{"id": "U1001", "reason": "email_invalid", "message": "邮箱格式不合法"}]}
- Web 接口仍用 HTTP 200 状态码（因整体请求成功），失败详情放在响应体中；避免用 500 混淆语义
- 对 SQLException，善用 getSQLState() 和 getErrorCode() 区分约束冲突（如 23000）、语法错误（42000）等
配合底层机制降低失败扩散
代码层容错需与数据库、中间件能力协同：
- MySQL 写入时用 INSERT IGNORE 或 ON DUPLICATE KEY UPDATE，避免单条主键冲突导致整批回滚
- Elasticsearch bulk 请求必须遍历 response 中每个子项的 error 字段——HTTP 200 不代表全成功
- 大事务慎用长循环+单事务提交；建议每 50–100 条分段 commit，控内存、限影响范围
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
