对象存储崩溃报错多为客户端调用异常，需快速区分权限认证、内存泄漏、参数越界或连接超时四类根因：权限类重在验证凭证与策略；内存类须强制try-with-resources与分块上传；参数类需URL编码与大小校验；连接类应调优连接池与超时配置。
对象存储（如 COS、OSS、S3）崩溃报错，多数不是服务端真正“崩溃”，而是客户端调用时因权限、网络、参数或资源管理不当触发的异常。关键不在重试或加日志，而在快速区分：是认证失败、资源越界，还是内存/连接泄漏导致的连锁反应。
一、权限与认证类报错：最常见却最容易误判
典型报错：“You have no write permission for this Object” 或 CosServiceException: AccessDenied。
- 这不是代码逻辑错误，而是凭证或策略配置问题——AccessKey ID/Secret 错误、RAM 子账号没授权、Bucket ACL 设置为 private 但请求未签名
- 检查 request ID（RequestId）并用 COS 自助诊断工具验证，比翻代码更快；若 request ID 为空或无效，说明 SDK 甚至没发出去，大概率是初始化失败或网络拦截
- 修复重点：统一使用 STS 临时凭证 + 最小权限策略；避免硬编码 AKSK；所有写操作前加 bucket.exists() && object.acl().isWritable() 预检（非必须但可提前暴露问题）
二、内存与流资源类报错：静默泄漏，最终引发 OOM 崩溃
典型现象：批量上传/下载几十个文件后，JVM 报 java.lang.OutOfMemoryError: Java heap space，或日志中频繁出现 "Stream closed"、"Connection reset"。
- 根本原因常是 InputStream / OutputStream / CosClient 未正确关闭，尤其在 try-catch 中漏掉 finally 或未用 try-with-resources
- COS SDK 的 PutObjectRequest 默认会缓存整个文件到内存（除非显式设置 setInputStream 并配合 setContentLength），大文件上传极易打爆堆
- 修复动作：所有文件操作强制用 try-with-resources；上传超 10MB 文件启用分块上传（UploadManager）；禁用 setInputStream(new FileInputStream(...)) 这种裸流写法，改用 FileBody 或 RepeatableFileBody
三、参数与边界类报错：看似随机，实则可预测
典型报错："InvalidObjectKey"、"EntityTooLarge"、"KeyLengthExceeded"。
- Object Key 含非法字符（如空格、控制符、长度超 1024 字节）、单次上传 Body 超过服务端限制（COS 默认 5GB，但 SDK 客户端可能因缓冲区设小而提前失败）
- URL 编码不一致：本地生成的 key 是 UTF-8 编码，但签名时未做相同处理，导致 signature mismatch
- 修复方式：上传前对 key 调用 URLEncoder.encode(key, "UTF-8")；大文件走分块上传；所有请求体大小在发送前校验，超限直接拒入并返回明确业务错误码
四、连接与超时类报错：表象是网络，根因在配置
典型报错："CosClientException: Connection timed out"、"SocketTimeoutException"。
- 不是网络不稳定，而是 SDK 客户端连接池耗尽或超时设置不合理——默认连接池大小 50，若并发上传 100 个文件且每个阻塞 3 秒，第 51 个请求就会排队超时
- HTTP 连接复用未开启，或 Keep-Alive 被中间代理关闭，导致每次请求新建 TCP 连接，放大延迟和资源消耗
- 修复建议：初始化 CosClient 时显式配置 ClientConfiguration，设 maxConnections=200、connectionTimeout=5000、socketTimeout=30000；启用 setSupportGzipCompress(true) 减少传输量
