MinIO Go SDK 初始化报错 invalid endpoint因endpoint含协议头，应仅传"localhost:9000"并用secure参数控制；上传需显式设context超时；GetObject须Close()且用io.ReadAll或io.Copy读取；ListObjectsV2性能差应改用ListObjects流式遍历。
MinIO Go SDK 初始化报错 invalid endpoint
常见于用本地 MinIO 服务却填了带 http:// 或 https:// 的 endpoint。MinIO Go SDK 的 endpoint 参数只接受纯主机+端口（如 "localhost:9000"），协议由 secure 布尔参数控制，不是拼在字符串里。
- 正确写法：
minio.New("localhost:9000", "Q3AM3UQ867SPQQA43P2F", "zuf+tfteSlswRu7BJ86wekitnifILbZam1KYY3TG", false) - 错误写法：
minio.New("http://localhost:9000", ...)→ 直接 panicinvalid endpoint - 如果启用了 TLS（比如用
minio server --console-address :9001 /data配了反向代理），才设true，否则一律false
上传文件时卡住或返回 context deadline exceeded
默认客户端没有设置超时，但实际网络或 MinIO 后端响应慢时，PutObject 会无限等待。Go 的 context 必须显式传入，否则底层 HTTP 客户端用的是零值 context.Background()，不带超时。
- 务必用
context.WithTimeout包一层再传给PutObject - 示例：
ctx, cancel := context.WithTimeout(context.Background(), 30*time.Second); defer cancel(); client.PutObject(ctx, "mybucket", "key.txt", reader, size, minio.PutObjectOptions{}) - 注意：如果
size传-1（流式上传），MinIO 会尝试分块上传，此时超时需更宽松，且要确保reader稳定可读，别是临时 pipe 或已 close 的bytes.Reader
GetObject 返回空内容但没报错
典型原因是没读完响应体（object.Object 是一个 io.ReadCloser），或者读取后没调用 Close() 导致连接复用异常，后续请求可能静默失败。
- 必须用
defer object.Close()，不能只靠 GC - 读取建议用
io.Copy或io.ReadAll，别用object.Read(...)手动循环——容易漏读或误判 EOF - 小文件可直接
data, _ := io.ReadAll(object)；大文件务必流式处理，例如io.Copy(dstFile, object) - 如果用
object.Stat()先查元信息，记得它也会消耗一次 HTTP 请求，且不影响后续GetObject调用
ListObjectsV2 遍历大量对象性能差
MinIO 默认每页最多返回 1000 个对象，ListObjectsV2 是分页接口，但很多人写成“取一页 → 处理 → 取下一页”串行逻辑，网络 RTT 累积明显。尤其跨机房或高延迟环境，几百页就卡几秒。
立即学习“go语言免费学习笔记（深入）”；
- 用
client.ListObjects（注意不是ListObjectsV2）配合recursive: true和prefix，SDK 内部会自动翻页并返回chan流式推送，避免手动轮询 - 示例：
for object := range client.ListObjects("mybucket", "logs/", true, ctx, false, false) { ... } - 如果必须用 V2（比如需要
StartAfter精确断点续传），至少把每页 size 改成 1000（默认就是），别留默认值还自己设 100 - 注意：
prefix不是正则，是路径前缀，结尾不加/可能漏匹配子目录
MinIO Go SDK 行为高度依赖你传的 secure、context 和对象体生命周期管理，这三个地方出问题，不会报错但结果不可控。尤其是 Close() 和 context，容易被当成“可选”，其实它们是稳定性的锚点。
