MinIO纠删码模式下AWS CLI s3 cp报InvalidRequest，因强制v4签名且需x-amz-content-sha256头，旧版CLI未默认启用；须升级CLI或手动配置签名版本与校验头。
MinIO 的纠删码模式下，为什么 AWS CLI s3 cp 会报 InvalidRequest？
因为 MinIO 启用纠删码（erasure coding）后，默认强制要求客户端使用 v4 签名，且必须携带 x-amz-content-sha256 头；而旧版 AWS CLI（
- 检查 CLI 版本：
aws --version，低于aws-cli/2.0.0建议升级 - 强制启用 v4 签名：在
~/.aws/config中添加signature_version = s3v4 - 确保上传时计算并发送 SHA256：AWS CLI v2 默认开启，v1 需加
--expected-size或改用aws s3 cp --sse AES256触发校验逻辑（间接生效） - MinIO 服务端不能降级签名验证：关掉
MINIO_DISABLE_HTTP_TRACE并查日志，常见错误是"The authorization mechanism you have provided is not supported"
如何确认 MinIO 集群是否真正运行在纠删码模式？
仅看启动命令或配置文件不够——MinIO 启动时若磁盘数不满足纠删码最小要求（如 4 节点集群只挂了 2 块盘），它会自动 fallback 到单节点模式，此时 mc admin info 显示的仍是 Erasure: enabled，但实际无分片、无冗余。
- 执行
mc admin info myminio，重点看每个节点下的Drives数量和状态；纠删码生效需满足：total drives >= 2 * parity drives，且所有 drive 路径可读写 - 用
mc admin heal myminio --dry-run查“heal summary”，若提示No errors found且Objects repaired: 0，不代表健康，要看Drives online是否等于你声明的总盘数 - 真实写入测试：上传一个 >1MB 文件后，登录任一 MinIO 节点，进对应 bucket 的磁盘路径（如
/data/mybucket/myobject），应看到多个带.part.后缀的碎片文件，而非单一完整文件
MinIO S3 兼容性调优：哪些 S3 SDK 参数必须设，哪些可忽略？
不是所有 AWS SDK 的 S3 配置项都对 MinIO 有效；关键在于绕过 AWS 特有行为，对齐 MinIO 的 HTTP 层约束。
- 必须设置：
endpoint（含协议和端口）、region（任意非空字符串，如us-east-1）、signatureVersion（明确为s3v4） - 必须禁用：
s3ForcePathStyle: false（MinIO 不支持 path-style，只认 virtual-hosted-style，即bucket.endpoint） - 可忽略：
s3DisableMultiRegionAccessPoints、useAccelerateEndpoint等 AWS 专属功能开关 - Java SDK 示例中易错：
AmazonS3ClientBuilder.standard().withPathStyleAccess(false)必须显式调用，否则默认为true，导致 404
纠删码集群扩容时，为什么新节点加入后数据没自动重平衡？
MinIO 的纠删码集群不支持在线动态扩盘或增节点——所谓“扩容”实际是重建集群。官方文档写的 mc admin cluster expand 仅适用于分布式模式（distributed mode），而纠删码（erasure-coded mode）本质是部署时确定的静态拓扑。
- 确认当前模式：
mc admin info myminio | grep Mode，输出Mode: distributed才能扩；若是Mode: standalone却启用了多盘，那其实是伪分布式，无法扩 - 真纠删码集群扩容唯一方式：停服 → 备份元数据（
minio server --console-address :9001 /data{1...N}启动前先cp -r ~/.minio /backup）→ 用新磁盘列表重启服务 → 用mc mirror迁移数据 - 容易被忽略的点：新集群的
MINIO_ROOT_USER和MINIO_ROOT_PASSWORD必须与旧集群一致，否则mc认证失败，mirror会卡在 list bucket 阶段
