我之前手动构造S3 API签名时也踩过这个坑，那种签名不匹配的报错真的让人头大。结合你遇到的情况，下面是几个高频出错点，你可以挨个排查：

1. 签名版本与请求格式不匹配 #

你提到参考了SigV4的文档，要确保全程用的是SigV4签名（S3现在多数区域已经强制要求这个版本了，旧的SigV2早就不支持）。重点检查这两步：

• Canonical Request是否正确：HTTP方法必须是DELETE，URI路径要对应你的请求样式（虚拟主机式的话，URI是/$file而不是/$bucket/$file），所有Headers要小写且按字典序排序。
• String to Sign是否符合要求：日期格式必须是YYYYMMDD'T'HHMMSS'Z'，还要包含正确的区域（比如us-east-1）和服务标识s3。

2. 请求URL与签名中的路径不一致 #

看你代码里用的是bucket.s3.amazonaws.com/file的虚拟主机式URL，那在构造签名的Canonical URI时，只能写/$file；如果写成/$bucket/$file，签名计算出来肯定和AWS验证的不一样。

3. 时间同步问题 #

AWS签名对时间差容忍度极低，超过5分钟就直接返回签名不匹配。建议：

• 确保你构造签名用的时间和请求头里的x-amz-date完全一致，格式统一用UTC时间的YYYYMMDD'T'HHMMSS'Z'。
• 同步服务器的NTP时间，避免本地时间偏差过大。

4. 权限伪装成签名错误 #

有时候看似是签名问题，实际是IAM权限不足。先确认你的IAM实体（用户/角色）有s3:DeleteObject权限，对应的Bucket策略可以参考：

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "s3:DeleteObject",
            "Resource": "arn:aws:s3:::your-bucket-name/*"
        }
    ]
}

5. 特殊字符编码不一致 #

如果你的文件名包含空格、中文或者特殊符号（比如&、#），一定要保证：

• 构造Canonical Request时URI是编码后的格式（比如空格转%20）。
• 实际请求的URL也用同样的编码，不能一边编码一边不编码。

6. 遗漏或错误处理请求Headers #

如果你的请求里加了自定义Headers（比如x-amz-meta-*这类元数据头），必须把这些Headers加入Signed Headers列表，并且在计算签名时包含进去。漏加任何一个都会导致签名不匹配。

快速验证小技巧 #

先用AWS CLI测试删除是否能成功：

aws s3 rm s3://your-bucket-name/your-file-path

如果CLI能正常删除，说明权限和对象路径都没问题，问题肯定出在你手动构造签名的流程里。可以加--debug参数看CLI生成的签名细节，对比你自己的代码，很容易找到差异：

aws s3api delete-object --bucket your-bucket-name --key your-file-path --debug

要是能把完整的签名构造代码贴出来，更容易定位具体哪里出错了~

内容的提问来源于stack exchange，提问作者david890ch