什么是 404
404 标准的 http code 状态码，代表用户请求的资源在服务端不存在， 404 并不是一个异常状态码？而是一个正常的响应。换句话说 404 已经成为了一个结果，这种响应常见在 client 端下载 OSS 的资源时出现。
做好预防
很多情况如果服务端的历史日志保存时间有限，那么出现问题时也无法查证，所以建议使用 OSS 先把日志功能开启，将 OSS 每天的数据都自动备份到用户指定的目录下，费用低廉。
why 404
- 检查 客户端提供的
objectname是否正确，确保不存在低级的拼写错误。 - 客户端之前上传是否成功，如果成功 OSS 会返回
requestid，凡事没有 requestID 的并不能保证已经上传到 OSS 成功。 - 客户端可以根据开启的 log 查询下对应时间点 OSS 出现 404 的情况。
- OSS 是否开启过
生命周期功能，开启这个功能，触发生命周期管理规则后，会将满足条件的 URL 完全上除掉。
客户端上传成功，但是下载返回 404
首先这种情况是不存在，如果已经上传到 OSS 的文件，除了会冗余写多份，也受到权限的严格限制，匿名非法的访问是不可能直接删除的，除非使用者自己把 bucket 设置为公共读写（高危权限）
一般对上传成功有个误区，认为返回 200 就代表文件已经上传成功其实这并不准确。会造成两种情况
- 收到状态码 200 的情况后立刻取请求 OSS ，返回了 404 ，等一会再访问就 200 ，怀疑到 OSS 返回 200 和真实的写入成功不同步。
- 上传成功收到 200 状态码，但访问一直都是 404
- 分片上传或者断点续传已经收到了 200 并切有 requestID 的情况下，访问 OSS 仍然返回 404。
其实以上两种情况都是对返回状态的判断不准确导致，可靠的判断方式是，if result.status==200 && result.requestID != None 的情况下才是上传成功。有的 http 请求被 http 劫持的情况下会收到一个伪造的 200 状态码并不是真实的返回。
另外分片上传或者断点续传比叫特殊，是采用将原文件切片的形式上传，每一个分片 multipart 上传成功都会返回 200 和 requestID，这种情况应该以 complete 合并分片后返回的 200 & requestID 为准。
极特殊的情况是客户端使用分片上传时对用的 uploadID 凭证是 A，但是完成合并时用的 uploadID 凭证是 B，OSS 找不到原始的 A 凭证，所以报 404 无法完成上传。
文件之前一直存在，突然访问 404
有以下几个原因
- 客户端的子账号有权限，把 OSS 的文件删除了。
- 具备客户合法的 AK SK 通过 API 删除了。
- 具备合法账号密码的人在控制台删除了。
- 拥有者设置过生命周期过期被删除了。
- bucket 和其他 bucket 有跨区复制的关系，其他的 bucket 执行了删除操作，同步到当前的 bucket，所以文件被删除。
