直接用http.Client发AWS API请求返回403，是因为AWS强制要求V4签名——需严格按规范构造含方法、路径、头、时间戳、密钥派生的动态签名；漏掉任一字段（如host未规范化、X-Amz-Date格式错误、body哈希不匹配）即导致SignatureDoesNotMatch。
为什么直接用 http.Client 发 AWS API 请求会返回 403？
因为 AWS 所有需要认证的 API（如 S3、EC2、API Gateway）都强制要求 V4 签名——它不是简单加个 Authorization: Bearer xxx，而是基于请求方法、路径、头、时间戳、密钥派生出一串动态签名。漏掉任意一个字段（比如没规范化 host 头或忽略空查询参数），签名就失效。
常见错误现象：403 Forbidden + InvalidSignatureException 或 SignatureDoesNotMatch；调试时容易误以为是 AK/SK 写错，其实是签名构造阶段某步标准化失败。
- 必须按字典序排序并小写处理所有参与签名的 header（
host、x-amz-date、x-amz-security-token等） -
host值不能带端口（即使用了非标准端口也要去掉），且必须与 DNS 解析目标一致 - 请求体（body）哈希必须是
sha256，空 body 也得填e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855 - 日期头必须用
X-Amz-Date（ISO8601 格式：YYYYMMDD'T'HHMMSS'Z'），且和签名中使用的日期前缀（yyyymmdd）严格一致
如何用 Go 构造 AWS V4 签名字符串？
核心是四步：规范化请求 → 生成签名摘要 → 派生签名密钥 → 组装 Authorization header。Go 标准库不提供封装，需手动实现或借助 github.com/aws/aws-sdk-go-v2/aws/signer/v4（推荐）。
若选择手撸（仅用于学习或极简场景），关键点：
立即学习“go语言免费学习笔记（深入）”；
Golang Spf13 Viper
下载
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
- 规范化请求字符串必须包含：HTTP 方法 + 换行 + 规范化 URI（URL 编码且不重复编码）+ 换行 + 规范化 query（含空值，按 key 排序）+ 换行 + 规范化 header 字符串（key 小写+冒号+单空格+value 去首尾空+换行）+ 换行 + header key 列表（小写、换行分隔）+ 换行 + hex(sha256(body))
- 签名密钥派生：先用
sha256("AWS4"+secret)得到 kDate，再用kDate对region做 hash 得 kRegion，再对service（如s3）做 hash 得 kService，最后对"aws4_request"做 hash 得 kSigning - 最终签名 =
hex(hmac(kSigning, canonicalRequestHash))
示例片段（使用 v2 SDK）：
cfg, _ := config.LoadDefaultConfig(context.TODO())
signer := v4.NewSigner()
signedReq, _ := signer.SignHTTP(ctx, credentials.Value{AccessKeyID: ak, SecretAccessKey: sk}, req, service, region, time.Now())
用 aws-sdk-go-v2 签名时哪些参数最容易错？
SDK 封装了大部分逻辑，但仍有几个显式参数必须对齐真实请求环境，否则签名无效：
-
service必须精确匹配 AWS 文档中的服务名（s3、execute-api、ec2），大小写敏感，不能写成S3或api gateway -
region必须与 endpoint 地域一致（如调https://s3.us-west-2.amazonaws.com就得传us-west-2），不能用global替代 -
req必须是已设置好Host、X-Amz-Date、Content-Type的 *http.Request，且Body未被读取过（SDK 会重读 body 计算 hash） - 若使用临时凭证（STS），必须把
X-Amz-Security-Token加入 request header，并在 signer 的SignHTTP调用前确保它存在
签名后发请求，为什么还是 403？检查这三处
签名本身正确 ≠ 请求能过鉴权。常被忽略的链路断点：
- 系统时间偏差超过 5 分钟：AWS 会拒绝
X-Amz-Date与服务器时间差 > 300 秒的请求，用ntpdate -q time.amazon.com或chronyd同步 - endpoint URL 协议/域名不匹配：签名时用的
host头必须和实际 DNS 解析结果完全一致（例如s3.amazonaws.com和s3-us-west-2.amazonaws.com是不同 host） - 权限策略限制 source IP 或 referrer：签名通过了，但 IAM policy 或 bucket policy 显式 deny 了当前出口 IP 或未带
Referer，此时错误仍是 403，但日志里会提示具体原因
真正难调的永远不是算法步骤，而是签名输入和网络请求之间那几行 header 和 URL 的微小不一致——建议用 curl -v 抓包对比签名时用的 request 和实际发出的 request 字节级是否相同。
