minio客户端初始化报invalid endpoint因url格式错误，须带http(s)://且无路径后缀；大文件上传应避免全量读入内存，改用文件句柄或io.pipe流式处理；客户端应全局复用并正确配置transport；listobjectsv2需注意prefix、recursive及分页循环。
MinIO客户端初始化为什么总报invalid endpoint
常见错误是把http://或https://前缀漏掉，或者端口写错（比如用9000却配了443）。MinIO SDK对endpoint校验很严格：必须是完整URL格式，且不能带路径后缀（如/minio）。
- 正确写法：
"http://localhost:9000"或"https://minio.example.com" - 错误写法：
"localhost:9000"、"minio.example.com:443"、"https://minio.example.com:443/minio" - 如果服务启用了TLS但没配证书验证，得显式传
ssl=True并设certifi=False（Python SDK），Go里对应的是minio.Options{Secure: true, CertFile: ""}，空字符串表示跳过验证（仅开发）
上传大文件时为什么卡住或内存暴涨
Go的minio.PutObject默认把整个io.Reader读进内存再分块上传，遇到GB级文件极易OOM。真正该用的是minio.PutObjectWithContext配合流式io.Pipe或直接传文件句柄。
- 别用
os.ReadFile加载大文件到[]byte再传给PutObject - 优先打开文件：
f, _ := os.Open("big.zip")，然后传f作为io.Reader - 若需预处理（如加密/压缩），用
io.Pipe链式处理，避免中间全量缓存 - 注意
minio默认分块大小是5MiB，小文件无需改；大文件可调minio.PutObjectOptions{PartSize: 10 * 1024 * 1024}减少HTTP请求数
如何安全复用MinIO客户端实例
minio.Client是线程安全的，但初始化开销大（DNS解析、TLS握手），绝不该每次请求都new一个。全局单例最稳妥，但要注意Transport配置泄漏风险。
- 在
init()或main()里一次构建：minioClient, _ := minio.New(...) - 别手动改
minioClient.SetCustomTransport——它会覆盖底层http.Transport，导致连接池失效；真要定制，应在minio.New时通过minio.Options{Transport: myTransport}传入 - 如果服务地址动态变化（如K8s Service），别用
minio.New硬编码，改用minio.NewWithOptions+ 自定义Resolver，否则DNS变更不生效
ListObjectsV2返回空结果但明明有文件
典型原因是prefix或delimiter用错，或未处理分页。S3兼容接口默认只返回1000个对象，且prefix匹配的是“路径前缀”，不是文件名模糊搜索。
立即学习“go语言免费学习笔记（深入）”；
- 检查
prefix是否多写了/开头（如"/logs/"应为"logs/"） - 确认
minio.ListObjectsOptions{Recursive: true}已启用，否则只列一级 - 必须循环调用：
for object := range minioClient.ListObjects(...) { ... }，SDK内部自动处理ContinuationToken - 调试时加
UseSSL: false和Debug: true选项，看真实HTTP请求的prefix和max-keys参数是否符合预期
分布式文件系统客户端最难的不是连上，而是把重试、断点续传、元数据一致性这些细节藏在minio.Client背后还不出错——你得亲手压测并发上传+网络抖动，不然上线第一天就发现PutObject失败时不触发重试逻辑。
