不能用k8s.io/client-go触发S3上传，因其仅操作Kubernetes资源，不提供PutObject等对象存储接口；事件触发式离线存储需监听业务事件后调用对象存储SDK异步写入，PVC和client-go只负责挂载路径，不参与文件内容流转。
不能用 k8s.io/client-go 触发 S3 上传，它根本不认识 PutObject。所谓“事件触发式离线存储”，本质是监听业务事件（如订单创建、日志落盘），然后调用对象存储 SDK 异步写入——Kubernetes 的 PVC 或 client-go 只管挂载路径，不参与文件内容流转。
为什么 event handler 里直调 s3.PutObject 会拖垮整个服务
PutObject 默认同步读取整个 Body 计算校验和和长度，传 *os.File 却没提前 Stat()？SDK 会先把几百 MB 文件全 load 进内存再发请求，goroutine 卡死、OOM、HTTP 超时全来一遍。
- 小文件（f.Stat().Size()，显式设
ContentLength，再传f - 大文件或流式来源（如 multipart.FormFile）：必须用
s3manager.Uploader，别绕开 - 所有上传必须带
context.WithTimeout(r.Context(), 30*time.Second)，否则底层 TCP 空等无感知
s3manager.Uploader 初始化时最常漏的三件事
不是“能跑就行”，而是漏一项就静默失败或限流被拒：
-
Concurrency：默认 5，内网可提至 10；别设 >20，S3 会对单 IP 并发连接数限流 -
PartSize：默认 5MB，最小 5MB；上传 2GB 文件设 10MB 比设 1MB 更稳（减少请求数 + 单块重传代价平衡） - 没配
aws.Config的Retryer：默认只重试 3 次，网络抖动时不够；建议用aws.CredentialsCache+ 自定义重试策略
事件触发后如何确保上传不丢、失败可追溯
HTTP handler 里起 go func() { ... }() 是危险操作：panic 不被捕获、error 无法回传、context 生命周期错乱。
立即学习“go语言免费学习笔记（深入）”；
- 用 channel 或消息队列（如 Redis Stream / Kafka）中转：handler 只做校验 + 入队，worker goroutine 持续拉取执行
- 上传成功后写一条
event_id → s3_key到数据库，供后续审计或 CDN 预热 - 失败时记录完整 error（含
err.Error()和awserr.Error.Code()），别只打 “upload failed” - 特别注意
InvalidSignatureException：90% 是 region 和 bucket 实际 region 不一致，或本地时间偏差 >15 分钟
真正难的不是写通第一个 PutObject，而是让上传在高并发、断网、磁盘满、凭证过期等各种边界下依然可观察、可重试、不阻塞主流程——这些细节藏在 s3manager.Uploader 的选项里，不在文档首页。
