最稳组合是s3.putobject传小文件、s3manager.uploader处理>5mb大文件；region必须与bucket严格一致（如us-east-1不可写成us-east-2），否则触发跨域路由致超时或invalidsignatureexception；需显式配置region和endpoint，检查系统时间同步，并确保key编码一致。
用 s3.PutObject 上传小文件、s3manager.Uploader 处理大文件，是最稳的组合。别自己拼签名、别硬编码凭据、别忽略 region 与 bucket 的严格匹配。
为什么 s3.PutObject 总是超时或报 InvalidSignatureException
不是网络差，八成是 region 没对齐。S3 要求 client 初始化时传的 region 必须和 bucket 实际所在 region 完全一致——哪怕只差一个字符（比如 us-east-1 和 us-east-2），SDK 就会 fallback 到 global endpoint，触发跨 region 路由，延迟飙升甚至签名失败。
- 查 bucket 真实 region：运行
aws s3api get-bucket-location --bucket your-bucket-name；注意us-east-1返回空字符串，得按逻辑视为us-east-1 - 初始化 client 时显式传
config.WithRegion("xxx")，别依赖环境变量或配置文件自动推断 - 国内用户用 AWS CN 区域（如
cn-north-1）必须配endpoint为https://s3.cn-north-1.amazonaws.com.cn，且region也设成cn-north-1 - 本地时间不准也会导致
InvalidSignatureException，检查系统时间是否同步（ntpd或systemd-timesyncd）
上传大文件内存暴涨或卡死，怎么选 Upload 方法
s3.PutObject 不支持真正流式上传：它内部会尝试读取全部 Body 来算 ContentLength 和 checksum，尤其当传的是 *os.File 又没提前 Stat() 时，SDK 会先全读一遍，几百 MB 文件直接 OOM。
- 文件 > 5MB，必须用
s3manager.Uploader：它自动分块（Multipart Upload）、并发、重试、断点续传 - 初始化 uploader 时可调
Concurrency（默认 5，内网可提至 10）和PartSize（默认 5MB，最小 5MB） - 坚持用
PutObject？务必提前设置ContentLength字段（file.Stat().Size()），且确保Body支持Seek（*os.File可以，bytes.Reader不行） - 前端直传场景，优先用
s3.NewPresignClient生成预签名 URL，后端不碰文件流
GetObject 返回空内容或 NoSuchKey，但控制台明明能看到
S3 的 key 是纯字符串，严格区分大小写、URL 编码敏感，且不按“目录”解析。控制台显示的是解码后的 key，而 SDK 默认会对 key 做编码，极易误判。
- 先用
s3.HeadObject确认对象是否存在，避免白跑GetObject解包逻辑 - 检查
key是否被意外二次编码：比如存入时是%E4%BD%A0%E5%A5%BD.txt，代码里却传了原始字符串"你好.txt" - 确认
Contents.Key从ListObjectsV2拿来后，没再调url.PathEscape - 避免手动拼接
key，用path.Join后再strings.TrimPrefix开头的/；若key来自用户输入，先url.PathEscape再传给 SDK
region 对齐、ContentLength 显式设置、key 编码一致性——这三个点看似琐碎，却是线上故障最常卡住的地方。尤其是跨 region 上传失败时，错误日志里往往不报 region 问题，只显示 timeout 或 signature invalid，容易往网络或权限上错查。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
