try-catch仅用于分片上传中可预期且需干预的异常环节，如文件读取、HTTP请求、JSON解析；须记录日志、标记待重试、交由上层决策，配合try-with-resources防泄漏，并依托幂等、状态管理和预检实现真正恢复。
在大文件分片上传场景中，try-catch 不是用来兜底所有失败的“万能开关”，而是针对可预期、可恢复的异常环节做精准响应——比如网络抖动导致某一片上传失败、临时磁盘写入失败、服务端返回 503 等。它本身不提供重试或断点续传逻辑，但为这些逻辑提供了安全执行的前提。
只在明确可能出错且能干预的环节加 try-catch
分片上传流程通常包含：读取本地文件 → 切片 → 计算校验和 → 发起 HTTP 请求 → 接收响应 → 本地记录完成状态。其中真正需要 try-catch 的，仅限以下几处：
- 调用
Files.readAllBytes()或FileChannel.map()读取单个分片时，可能触发IOException（如文件被占用、权限不足） - 使用
HttpURLConnection或OkHttpClient发送分片请求时，捕获SocketTimeoutException、UnknownHostException、IOException等受检异常 - 解析服务端返回的 JSON 响应（如
{"success":true,"offset":1048576}）时，捕获JsonParseException或NullPointerException（若未判空）
不要包裹整个 for 循环或整个 upload() 方法——那样会让失败分片无法单独重试，也掩盖了哪一片出了什么问题。
catch 中必须做三件事：记录、标记、交由上层决策
每个分片失败后，不能静默跳过，也不能直接抛出新异常中断整个上传。推荐做法是：
立即学习“Java免费学习笔记（深入）”；
- 用 SLF4J 记录带上下文的日志：
log.warn("Upload failed for chunk #{} (size: {}B), retrying...", index, chunkSize, e) - 将该分片索引加入待重试队列（如
ConcurrentLinkedQueue<Integer>），避免重复上传成功分片 - 不吞异常也不 throw new RuntimeException(e)，而是让调用方根据重试策略（如指数退避）决定是否立即重试或延后处理
配合 try-with-resources 确保资源不泄漏
每个分片读取都涉及 InputStream、BufferedInputStream 或 RequestBody（OkHttp），必须自动释放：
- 用
try (InputStream is = Files.newInputStream(path)) { ... }替代手动 close - OkHttp 的
Response必须在 try-with-resources 或 finally 中调用response.close()，否则连接池会耗尽 - 避免在 catch 块里再嵌套 try-catch 关流——这容易引发二次异常掩盖主因
不靠 try-catch 实现“错误恢复”，而是靠状态+重试+幂等
真正的错误恢复能力来自设计，而非异常处理语法：
- 服务端对同一分片 ID 的多次上传需幂等（接收并返回已存在，不重复存储）
- 客户端本地维护上传状态表（如 SQLite 或 JSON 文件），记录每片的 offset、hash、status
- 上传前先发一个 “check-chunks” 请求，服务端返回已成功接收的分片列表，客户端只补传缺失部分
try-catch 只是让这些机制能在异常发生时继续运行，而不是崩溃或卡死。
