先把当时的情况摆出来。前端上传「报价单-华东.pdf」，服务端落盘后文件名变成 ??.pdf，对象存储控制台看到一排问号，后续按文件名下载全部 404。
排查方向其实有限，先把可能性排一排。multipart 头里的 filename 没有按 RFC 5987 编码。另一种情况是框架按 latin-1 解码请求头导致乱码。
还有一种情况，前端 FormData 只传 filename 没传 filename*。另外，反向代理对请求头做了二次转码。
上来先抓包确认头里到底写的什么
curl -s -o /dev/null -w '%{header_json}' -F "file=@报价单.pdf;filename*=UTF-8''%E6%8A%A5%E4%BB%B7%E5%8D%95.pdf" https://api.example.com/v1/files服务端统一按 UTF-8 解析文件名
filename = raw.encode('latin-1').decode('utf-8', 'replace')落盘时用哈希做真实名再单独存展示名
python store.py --file report.pdf --name "报价单-华东.pdf" --key sha256补一次历史文件的重命名
python rename_objects.py --bucket docs --mapping names.csv --dry-run别只看报错消失，验证要多做一步。上传后文件名正确显示为中文，按名称检索能命中，下载链接返回 200 且 Content-Disposition 里的名字不乱码。
这里还有个坑。文件名乱码是编码问题不是存储问题，落盘用哈希、展示用原名，能绕开大部分解码差异。这类问题最好一次改到位，反复小改反而容易把原因搅混。