minio.new 初始化不探活，需立即调用 bucketexists 或 listbuckets 验证连接；endpoint 不带协议前缀，secure 控制协议；putobject 要用带超时 context 和流式读取；getobject 必须先检 err、再读、最后 close。
minio.New 初始化后不探活，90% 的连接失败都藏在 silent fail 里
minio.New 只解析参数，不发任何网络请求。返回非 nil 的 client 不代表能用，endpoint 写错、TLS 配置反了、AccessKey 权限不足、服务端禁用 v2 签名……全都不会报错。
必须立刻执行一次真实请求来“探活”：
- 推荐用
client.BucketExists("dummy-bucket-name")—— 桶不存在时返回false, nil；权限错、超时、签名不匹配则err != nil - 或用
client.ListBuckets()，它对认证失败、网络不通等错误更敏感 - 别用
MakeBucket替代探活：桶已存在会返回minio.ErrBucketAlreadyOwnedByYou，这不是健康检查
endpoint 和 secure 参数配错，直接 EOF 或空响应
endpoint 必须是纯主机+端口，不能带 http:// 或 https:// 前缀，也不能有尾部斜杠。协议由 secure 参数控制，不是拼在字符串里。
常见错误组合：
- MinIO 启动在
http://localhost:9000→ client 初始化时传"localhost:9000"+false - MinIO 启动启用了 TLS（如
--address :9001+ 自签证书）→ 传"localhost:9001"+true - 本地开发没配证书却传
true→ TLS 握手卡死，表现常为EOF或 context timeout - 生产环境反向代理了 HTTPS，但 MinIO 实际监听 HTTP → endpoint 写成
proxy.example.com+true，结果因证书校验失败静默失败
PutObject 卡住或 context deadline exceeded 的真实原因
这不是网络问题，而是 HTTP 连接池复用 + MinIO 服务端 Keep-Alive 配置不匹配导致的静默 hang，尤其在 K8s Job、Lambda 等短生命周期服务中高频复用 client 时极易复现。
关键实操点：
- 务必传带超时的
context.Context：ctx, cancel := context.WithTimeout(context.Background(), 5*time.Minute)；上传完记得defer cancel() - 大文件（>50MB）别传
[]byte或os.ReadFile结果——全量进内存可能 OOM；改用os.Open返回的*os.File，SDK 内部会流式读取 -
contentType不能为空字符串，建议设为"application/octet-stream"或按扩展名推断（如".jpg"→"image/jpeg"） - 若想控制分块大小，用
minio.PutObjectOptions{PartSize: 64 * 1024 * 1024}，避免默认 5MiB 在弱网下频繁重试
GetObject 读不到数据？先检 err，再读，最后 Close
GetObject 返回的是 *minio.Object，本质是 io.ReadCloser。对象不存在、权限不足、ETag 不匹配、服务端临时故障，都可能返回非 nil 的 obj + err == nil，但后续 Read 立即 EOF 或 panic。
安全读取三步不能少：
- 永远先判断
err：if err != nil { /* 处理错误 */ }，不要只看obj != nil - 读取时优先用
io.Copy(dst, obj)（写入*os.File）或io.ReadAll(obj)（小文件），别手动obj.Read(buf)循环——容易漏读或误判 EOF - 必须
defer obj.Close()；不关会导致 fd 泄露，压测时很快触发"too many open files"
真正容易被忽略的是：obj.Stat() 本身是一次独立 HTTP 请求，它不影响后续 GetObject 调用，但如果你只调了 Stat 就以为“对象存在”，然后跳过 GetObject 的 err 检查，就会掉进静默失败的坑里。
