一次 STS 缓存优化引发的 Android 视频上传“分片权限”问题复盘

对牛乱弹琴的秦始皇2025-12-30 10:24

原文件上传接口逻辑为获取临时key返回客户端客户端做上传操作，但生产服务器因为RTT的问题导致上传文件接口实时获取 STS变得很慢，这就导致用户在使用文件上传相关接口时非常难受，于是决定写定时任务获取STS存入Redis中，过期之前重新刷新，兜底实时获取STS同时刷新Redis缓存。编写，自测，push一气呵成，接口耗时自降到2-3ms，非常舒服！

提测后收到反馈，iOS各项正常，但Android中有一部分机型不能上传视频类文件，但有些机型又可以

非常的诡异，这说明因为iOS和Android的某些差异导致了文件上传的不确定

可以确定图片，日志，压缩包都能上传成功，只有视频有问题，那会不会和视频大小有关？

经过同一个视频上传的测试发现不是这个问题且Android上传一直403。

那么换一个方向，会不会是Android SDK 文件上传策略是否与iOS不一致？

我着重查看了过期时间剩余对Android SDK文件上传策略的影响，发现当 STS 已被使用一段时间（缓存 STS 场景）时，Android SDK 更倾向选择 分片上传（Multipart Upload），以提高成功率。

woc！！！

我没开分片上传权限添加

复制代码

allowActions:
  - name/cos:PutObject
  - name/cos:PostObject

开启下面权限

复制代码

allowActions:
  - name/cos:PutObject
  - name/cos:PostObject
  - name/cos:InitiateMultipartUpload
  - name/cos:UploadPart
  - name/cos:CompleteMultipartUpload
  - name/cos:AbortMultipartUpload

push，测试，完美通过！

这里做一个总结

缓存型 STS 会暴露客户端真实上传行为

Android + 大文件 = 必须默认支持 Multipart Upload

实时 STS 可能"掩盖权限设计缺陷"

STS 权限应覆盖"可能发生的完整行为集合"，而不是理想路径