iris.UploadHandler中不能直接用client.PutObject传文件，因UploadFormFiles返回*multipart.FileHeader，而PutObject需io.Reader或路径；须fh.Open()后defer关闭、校验Size、sanitize Filename、显式设ContentType、超5GB切分片上传、AccessKey禁硬编码。
iris.UploadHandler 里不能直接用 client.PutObject 传文件
因为 iris.Context 的 UploadFormFiles 返回的是 []*multipart.FileHeader，而阿里云 Go SDK 的 PutObject 接收的是 io.Reader 或本地文件路径（string），不能直接把 FileHeader 塞进去。常见错误是调用 fh.Open() 后没关文件句柄，或没处理 multipart 的内存/磁盘临时缓冲逻辑。
正确做法是：先用 fh.Open() 获取 io.ReadCloser，再传给 client.PutObject；同时必须用 defer f.Close() 确保关闭——否则高并发下会快速耗尽文件描述符。
-
fh.Size要检查，避免超限（比如前端绕过限制传 2GB 文件） - 别用
fh.Filename直接当 OSS object key，需 sanitize（去掉../、控制字符等） - OSS 的
PutObject默认不校验 MD5，如需完整性保障，得手动算并传options
用 oss.PutObject 上传时必须显式设置 ContentType
iris 默认不解析 Content-Type 到 FileHeader，而 OSS 控制台或 CDN 回源依赖这个字段决定浏览器是否 inline 展示（如图片）还是强制下载（如 zip）。如果漏设，OSS 会默认存为 application/octet-stream，导致图片无法直接在网页打开。
应该从 fh.Header.Get("Content-Type") 取值，若为空则用 mime.TypeByExtension 推断：
contentType := fh.Header.Get("Content-Type")
if contentType == "" {
contentType = mime.TypeByExtension(filepath.Ext(fh.Filename))
if contentType == "" {
contentType = "application/octet-stream"
}
}
然后传入 oss.ContentType(contentType) 选项。
大文件（>5GB）不能走 PutObject，得切分 + InitiateMultipartUpload
iris 本身不限制单次上传大小，但阿里云 OSS 的 PutObject 接口硬性限制 5GB。超过就报错：EntityTooLarge: Your proposed upload exceeds the maximum allowed size.
实际项目中，用户可能拖拽一个 10GB 视频进来，后端必须检测 fh.Size 并自动降级到分片上传流程：
- 小于 5GB：走
PutObject（简单、快、少代码） - 大于等于 5GB：调
InitiateMultipartUpload→ 拆成 10MB+ 分片 → 并发UploadPart→ 最后CompleteMultipartUpload - 注意：分片上传需要维护
uploadId和每个 part 的ETag，不能丢
iris 不提供分片逻辑封装，得自己基于 io.Seeker + io.LimitReader 切流，或用 github.com/aliyun/aliyun-oss-go-sdk/oss 自带的 Bucket.PutObjectFromFile（但它会先写临时文件，失去流式优势）。
AccessKey 决不能写死在 iris handler 里
有人图省事，在 iris.RegisterHandler 闭包里 new 一个 oss client，把 accessKeyId 和 accessKeySecret 写死——这是严重安全风险。一旦代码泄露或被反编译，整个 bucket 权限就丢了。
正确方式只有两种：
- 用 RAM 子账号 + 最小权限策略（只允许
PutObject到指定 prefix，禁止DeleteObject） - 通过环境变量加载：
os.Getenv("OSS_ACCESS_KEY_ID")，启动时由运维注入
另外，region 和 bucket 也建议配置化，别硬编码。否则换地域或换 bucket 得改代码、重部署。
最易被忽略的是：OSS 的 endpoint 必须和 bucket 所在 region 完全匹配，比如 bucket 在 oss-cn-hangzhou，却配了 oss-cn-beijing 的 endpoint，上传会卡住或报 InvalidEndpoint，且错误信息不明确。调试时先用 curl -v 手动发个简单请求确认 endpoint 可达。
