Last edited by @suen 2025-10-23T03:04:56Z
2 Likes
- 順
- 不能傳完全
- 卡卡卡但傳上去了
0
voters
1 Like
抱歉，上传 Screenshot_20251017_113056.jpg 时出错。请重试。
2 Likes
报错，挂梯子也报错
2 Likes
孫看眼teams吧，我把我截图发过去 @suen
2 Likes
誰在線，傳圖測試下
1 Like
抱歉，上传 XXX.jpg 时出错。请重试。
1 Like
看到了，謝謝！
1 Like
現在泥⋯⋯
1 Like
遇。。。
1 Like
下面这段话可以直接发给用户，讲人话、不甩锅，也把来龙去脉说清楚：
这次上传问题发生了什么？
我们为了加快附件上传，一度开启了“浏览器直传云存储”（文件从你的浏览器直接分片上传到 Cloudflare R2），理论上速度更快，也能减少服务器中转的等待。
但对北京等地区的部分网络（例如 111.203.* 段）来说，跨境链路抖动/丢包比较明显。直传模式需要浏览器不停地向云存储发起多次分片上传和预签名请求，一旦网络波动，就容易出现：
- 进度条长时间停在 0%；
- 反复“开始上传→卡住→放弃本次分片”的循环；
- 弹出“文件太大（最大 20MB）”这类误判提示（实际上不是体积问题，而是云端拒绝了某个分片，请求失败被前端误解读）。
我们在服务器日志里看到这些失败都呈现为
create-multipart → batch-presign-multipart-parts（重复多次） → abort-multipart，
并没有你文件真的超限的证据；有些请求还显示为“客户端提前断开”（即网络抖了）。
我们做了什么修复？
我们关闭了直传 ，改回“服务器中转上传 ”：
- 你的浏览器只需要把文件一次性传到本站服务器（走我们优化过的前置线路），
- 之后由服务器稳定地把文件转存到 R2。
- 这样不再依赖浏览器直连跨境云存储 ，也不再需要复杂的 CORS/分片交互 ，对高抖动网络更友好。
切换后，用户已经可以正常上传；之前那条“20MB”的提示也随之消失。
说明：最终文件仍然安全地存放在 R2，只是“先到本站，再由后台转存”，对你来说更稳定。
对你意味着什么？
- 上传会更稳；在很差的网络下，进度条可能缓慢但连续，而不是“卡 0% 不动”。
- 大文件建议在帖子里等待上传条走完再发帖，避免中途中断。
- 若仍遇到问题，给我们大概时间、帖子链接、文件大小，我们能从日志精准定位。
我们接下来的安排
- 继续观测北京等地区的上传成功率与耗时。
- 等链路情况更稳定、并且我们完成更细的分片大小/重试策略验证后，可能把“直传”作为可选加速重新开放，但默认仍以稳定优先的中转模式为主。
一句话版：
这次是“直传云存储”在部分网络下对丢包/抖动不够耐受导致分片频繁失败。我们已切回服务器中转方案，上传恢复正常，数据照样存在云端。
7 Likes
人話版本是：
本可以更快速上傳附件，但克服不了國家局域網的干擾⋯⋯
回退到一定可以上傳但速度不高⋯⋯
1 Like