预签名URL 403最常见原因是凭证权限不足或Region不匹配；Expires应按使用场景设为15分钟（上传）或1–6小时（下载）；上传时PUT请求必须显式设置Content-Type；404表示对象不存在，需提前用HeadObjectAsync校验。
为什么 AwsSdkS3 生成的预签名 URL 403？
最常见原因是签名时用的 Credentials 权限不足，或 Region 和实际 S3 bucket 所在区域不一致。AWS 要求签名请求中的 region 必须和 bucket endpoint 完全匹配，哪怕只是多一个 -1 后缀（比如 us-east-1 vs us-east-1.amazonaws.com）都会导致签名无效。
实操建议：
- 确认
AmazonS3Client初始化时传入的RegionEndpoint和 bucket 所在 region 完全一致，别靠猜测——查 AWS 控制台 bucket 属性页里的「Region」字段原文 - 确保凭证有
s3:GetObject（下载）或s3:PutObject（上传）权限，且ResourceARN 明确限定到目标 bucket 和 key 前缀，不要用通配符*开头 - 检查系统本地时间是否偏差超过 15 分钟，AWS 会拒绝时间戳过旧或过新的签名请求
GetPreSignedUrlRequest 的 Expires 参数怎么设才安全？
这个 TimeSpan 是从签名生成时刻起算的有效期，不是从 URL 被访问时起算。很多人误以为设成 24 小时就能“一天内都可用”，结果用户刚点开链接就过期——因为生成 URL 后可能被缓存、转发、延迟点击。
实操建议：
- 上传场景建议 ≤ 15 分钟：用户通常在表单提交后立刻上传，拖太久反而增加凭证泄露风险
- 下载场景可放宽至 1–6 小时，但避免超过 24 小时；长期有效需求应改用 CloudFront + OAI 或临时 token 换取方式
- 不要依赖客户端时间校准，
Expires值由服务端生成时确定，和用户设备无关
上传用的预签名 URL 需要额外指定 ContentType 吗？
不需要在生成 URL 时指定，但必须在实际 HTTP PUT 请求中带上正确的 Content-Type header，否则 S3 会拒绝——这是签名验证的一部分：签名计算时隐含了 header 约束，哪怕只差一个空格也会失败。
实操建议：
- 生成 URL 时不用管
ContentType，它不影响签名逻辑 - 但调用方发起 PUT 时，header 中的
Content-Type必须和生成签名时传入的GetPreSignedUrlRequest.ContentType（如果设置了）完全一致；没设置则默认为application/octet-stream，此时 PUT 请求也必须显式声明该值 - 浏览器直传常见坑：
fetch或XMLHttpRequest不填Content-Type会导致自动加charset后缀，触发签名不匹配，务必手动设为纯image/png这类标准值
如何避免 GetObjectPreSignedUrl 返回 404？
404 和签名无关，是对象根本不存在。但开发者常误以为是签名问题，反复调换参数。关键点在于：预签名 URL 只授权“访问权”，不保证“存在性”。即使权限正确、时间有效，对象被删了就是 404。
实操建议：
- 生成前先用
HeadObjectAsync检查对象是否存在且可读，再生成 URL；别省这一步，尤其在下载链路中 - 如果对象 key 含中文或特殊字符（如空格、
#），生成 URL 前必须用Uri.EscapeDataString编码，但注意：SDK 内部已处理，你只需传原始 key 字符串，别自己提前编码两次 - 注意 bucket policy 是否显式 deny 了匿名 GET，即使有预签名，policy 层拦截会返回 403 而非 404
真正难搞的是跨区域重定向和签名时区偏移——这两个点一旦出错，错误表现和权限问题几乎一样，但日志里找不到线索，得抓包比对 Authorization header 的 X-Amz-Date 和请求 timestamp 是否对齐。
