s3manager.uploader是唯一适用于真实生产环境大文件上传的方案；上传前应通过os.stat检查文件大小，超过100mb必须使用s3manager.uploader，putobject仅适合小文件。
s3manager.Uploader 是唯一能扛住真实生产环境大文件上传的方案，直接用 PutObject 传几百 MB 以上的文件，基本等于主动触发超时、OOM 或 S3 拒绝。
什么时候该切到 s3manager.Uploader
别等出问题才换——上传前用 os.Stat 检查文件大小，>100MB 就必须走 s3manager.Uploader。
-
PutObject适合小文件（ -
s3manager.Uploader自动分块（默认 5MB/chunk）、并发上传（默认 5 goroutines）、失败重试（默认 3 次），还支持context.Context控制超时和取消 - 哪怕你本地测试传 200MB 成功了，上线后网络抖动、S3 限流、实例内存波动都会让
PutObject突然崩掉
Uploader 的关键参数怎么调
默认值在开发机上跑得通，但一上生产就容易踩坑。
Golang Samber Hot
下载
在 Golang 中使用 samber/hot 进行内存缓存，支持 LRU、LFU、TinyLFU、W‑TinyLFU、S3FIFO、ARC、TwoQueue、SIEVE、FIFO 等淘汰算法，提供 TTL、缓存加载器及分片功能。
-
uploader.Concurrency：本地开发设 2–3；生产环境按 CPU 核数设（8–16），但别超过 20，否则可能被 S3 主动限流 -
uploader.PartSize：太小（如 1MB）会激增 HTTP 请求次数；太大（如 100MB）会让单块失败后重传代价过高；推荐 5–10MB - 别忽略
uploader.LeavePartsOnError：设为true可避免失败后残留未完成 multipart upload，防止 S3 存储计费泄漏
临时凭证和预签名 URL 容易漏掉的细节
硬编码密钥或漏传 SessionToken，是线上事故最高发原因。
- 永远别用
credentials.NewStaticCredentialsProvider写死 AK/SK，哪怕只在测试环境——这等于把门钥匙焊死在门上 - 临时凭证必须三元组齐全：
AccessKeyID、SecretAccessKey、SessionToken，漏掉SessionToken会直接报InvalidToken - 预签名 URL 的
Expires要按场景设：PresignGetObject下载链接设 5–15 分钟；PresignPutObject上传链接设 15–30 分钟；千万别用time.Now().Add(1 * time.Hour)硬算，单位错一点 URL 就秒失效
微服务间文件流转不能只靠 HTTP body
大文件在服务间直传，会吃光内存、拖垮整个链路。
- 前端 → 网关 → 文件服务：用预签名 URL 让前端直传 S3/MinIO，网关只校验策略、生成 URL，不碰文件流
- 文件服务 → 其他业务服务（如转码、OCR）：只传对象 key + bucket 名，让下游自己去拉；或者用消息队列异步通知，避免同步阻塞
- 所有涉及文件路径或 URL 的字段，都要做合法性校验（比如不允许
../路径遍历、bucket 名白名单），别信任何上游输入
真正难的不是写通上传逻辑，而是让每个环节都“不碰大文件”——上传归上传，处理归处理，凭证归凭证，链路里只要有一个环节把几百 MB 往内存里 load，整条流水线就脆得像玻璃。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
