minio.new 初始化失败的三个硬性条件是：endpoint 必须为纯主机+端口格式（如"localhost:9000"），secure 参数必须显式指定true或false，凭证必须用credentials.newstaticv4构造且与服务端一致；初始化后必须立即调用bucketexists探活；上传大文件需用os.open和带timeout的context；getobject必须先判err再读取并defer close。
minio.New 初始化失败的三个硬性条件
客户端初始化不是“填完参数就完事”，漏掉任意一个，后续所有操作都会 panic 或静默失败。
-
endpoint必须是纯主机+端口格式：不能带http://或https://，也不能有尾部斜杠；正确写法是"localhost:9000"或"minio.example.com:9000" -
Secure参数必须显式指定：false对应 HTTP 本地开发，true对应 HTTPS 生产环境；默认为true，连本地 HTTP 地址会直接报x509: certificate signed by unknown authority - 凭证必须用
credentials.NewStaticV4构造，且accessKey和secretKey要与 MinIO 服务启动时一致（默认是"minioadmin"/"minioadmin"）
初始化后必须立刻调用 BucketExists 探活
minio.New 只做参数解析，不发任何网络请求。endpoint 写错、TLS 配置反了、AccessKey 权限不足、服务端禁用 v2 签名……全都不会在初始化时暴露。
- 推荐立即调用
client.BucketExists(ctx, "test")或client.ListBuckets(ctx)——哪怕桶不存在，也能暴露认证/网络/签名问题 -
BucketExists在桶不存在时返回false, nil；但权限错误、超时、签名不匹配等都会返回err != nil - 别用
MakeBucket替代探活：它在桶已存在时会返回minio.BucketAlreadyOwnedByYou，不是幂等操作
PutObject 上传大文件卡住或报 context deadline exceeded
这不是 SDK bug，而是 HTTP 连接池 + 服务端 Keep-Alive 配置不匹配导致的静默 hang，尤其在短生命周期服务（如 K8s Job、Lambda）里高频复用 client 时极易复现。
- 务必传入带 timeout 的
context.Context：例如ctx, cancel := context.WithTimeout(context.Background(), 5*time.Minute) - 绝对不要用
os.ReadFile加载大文件再传给PutObject；改用os.Open后直接传*os.File，SDK 内部会按需流式读取 - 第四个参数（object size）设为
-1表示未知长度，SDK 自动按 5MB 分块；若想优化吞吐，可设minio.PutObjectOptions{PartSize: 10*1024*1024} - 上传完成后务必检查返回的
minio.UploadInfo.Size是否等于源文件os.Stat().Size()，防止网络中断导致静默截断
GetObject 返回空或 EOF 的真实原因
不是文件不存在，而是你跳过了最关键的错误检查步骤。
-
client.GetObject返回两个值：obj, err；必须先判断err != nil，再读obj——对象不存在、权限不足、ETag 不匹配等场景下，常返回非 nil 的*minio.Object+err == nil，但后续Read立即 EOF - 读完必须
defer obj.Close()，否则 fd 泄露，压测时容易触发 “too many open files” - 别对大文件用
io.ReadAll(obj)；改用io.Copy(dst, obj)写入*os.File
GetObject 返回的 *minio.Object 是个“懒加载句柄”，不检查 err 就直接读，等于默认信任服务端一切正常——这在生产环境里几乎从不成立。golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
