必须调用 w.close()，否则请求体缺少结尾 boundary，对象存储服务返回 400 或 invalidpart；需 defer w.close() 确保执行，配合 io.copy 流式上传，避免内存溢出。
用 net/http 发起 multipart 上传请求时，multipart.Writer 必须显式关闭
不调用 w.Close() 会导致请求体末尾缺少分隔边界（boundary），对象存储服务（如 AWS S3、MinIO、阿里云 OSS）通常返回 400 Bad Request 或 InvalidPart 错误，且日志里难定位。这是最常被忽略的步骤。
实操建议：
- 务必在
defer w.Close()前确保req.Body已完整写入，否则会 panic - 若需自定义字段（如
x-amz-meta-xxx），用w.WriteField()写入，而非手动拼接 - 文件流建议用
io.Copy(w, file)，避免一次性读入内存；大文件时尤其重要
签名请求失败？检查 Authorization 头是否包含正确的时间戳和签名算法
多数对象存储要求 v4 签名（如 AWS S3、MinIO 默认开启），而 Go 标准库不内置签名逻辑。直接拼 Authorization: AWS4-HMAC-SHA256 ... 极易出错：时间偏移超过 15 分钟、region 写错、canonical request 构造顺序不对都会导致 403 SignatureDoesNotMatch。
实操建议：
- 优先使用官方 SDK：
github.com/aws/aws-sdk-go-v2/config+github.com/aws/aws-sdk-go-v2/service/s3，自动处理签名与时区 - 若必须手写（如对接私有 MinIO 且禁用 SDK），用
github.com/minio/minio-go/v7，它封装了完整签名流程 - 调试时打印 canonical request 和 string-to-sign，与 AWS 文档逐行比对
上传大文件时卡住或超时？调整 http.Client 的 Timeout 和 Transport
默认 http.DefaultClient 的 Timeout 是 30 秒，上传几百 MB 文件大概率触发 context deadline exceeded。更隐蔽的问题是底层 TCP 连接复用不足，导致并发上传时连接耗尽。
实操建议：
- 设置长超时：
&http.Client{Timeout: 30 * time.Minute} - 配置
Transport：&http.Transport{MaxIdleConns: 100, MaxIdleConnsPerHost: 100, IdleConnTimeout: 30 * time.Second} - 若用分片上传（
UploadPart），每个 part 请求应复用同一*http.Client，而非每次新建
MinIO 兼容模式下上传失败？确认 endpoint 和 path-style 配置一致
MinIO 默认启用 path-style（如 http://minio:9000/mybucket/mykey），而 AWS S3 新 bucket 强制 virtual-hosted-style（http://mybucket.s3.region.amazonaws.com/mykey）。Go SDK 若未显式设置 UsePathStyle，在 MinIO 上会返回 301 Moved Permanently 或 403 Forbidden。
实操建议：
- MinIO 客户端初始化时加：
options := &minio.Options{Region: "us-east-1", Secure: false, UsePathStyle: true} - AWS S3 客户端若连 MinIO，必须设
use_path_style: true（SDK v2 中通过config.WithEndpointResolverWithOptions控制） - 用
curl -v直接发请求验证 endpoint 是否可访问，排除网络或证书问题
真正麻烦的不是写上传逻辑，而是签名、超时、路径风格这三处细节一旦配错，错误信息往往不指向根源。建议先跑通一个 1MB 文件的最小可行上传，再逐步加字段、换 endpoint、压大文件。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
