先区分签名错误和权限错误
函数计算（FC）读写对象存储 OSS 时，SignatureDoesNotMatch 表示请求携带的签名与 OSS 根据请求内容重新计算出的结果不一致。它和 AccessDenied 不是同一类问题：前者优先检查凭证、签名算法、请求参数和时间；后者才进入 RAM 或 Bucket Policy 的授权排查。
这一区分很重要。直接修改 Bucket Policy，通常不能修复签名串不一致，反而可能把排查带到更复杂的跨账号授权上。建议先保留响应中的错误码、x-oss-request-id、请求时间和 endpoint，后续比对日志时会更容易。
按顺序排查五类高频原因
1. 核对 FC 实际读取到的凭证
本地调试正常、部署到 FC 后失败，首先检查运行时真正读取到的配置，而不是只看控制台里是否填写过变量。重点包括：
- AccessKey ID 与 AccessKey Secret 是否填反；
- 值的前后是否混入空格、换行或转义字符；
- 密钥是否已经轮换，但函数实例仍在使用旧值；
- 变量名是否与代码读取的名称完全一致；
- 使用 STS 时，是否同时传入
AccessKeyId、AccessKeySecret和SecurityToken。
不要在日志中打印完整密钥。可以只记录凭证来源、AccessKey ID 的脱敏片段、配置版本和函数实例启动时间，用来判断新配置是否已经加载。修改环境变量或服务角色后，结合函数版本重新部署，并做一次最小化的 GetObject 或 PutObject 冒烟测试。
2. 统一签名版本、SDK 和请求参数
OSS 请求的签名不仅依赖密钥，也依赖参与签名的请求内容。不同 SDK 版本可能采用不同的默认签名行为；本地、CI 和 FC 使用的依赖不一致时，就可能出现同一份代码在不同环境表现不同。
排查时固定 SDK 版本，并根据当前 SDK 的文档显式确认签名版本。开启安全范围内的调试日志，比较客户端与服务端预期相关的关键字段，例如请求方法、资源路径、Content-Type、Date、x-oss-* 请求头和规范化参数。不要为了“试一下”随意删掉请求头，因为参与签名的头部变化本身就可能导致问题。
如果代码使用预签名 URL，还要检查生成 URL 时的 HTTP 方法、过期时间、对象路径和实际请求方法是否一致；生成 GET 签名却用 PUT 请求，或者对象路径编码方式不同，也会造成签名校验失败。
3. 检查运行环境时间与 endpoint
签名通常包含时间信息。函数运行环境的系统时间明显偏离服务端时，即使密钥完全正确，也可能被判定为签名无效。应检查运行时日志中的请求时间、容器或宿主环境的时间同步状态，以及是否存在跨地域的时间处理错误。
同时确认 endpoint 与网络环境匹配：函数在专有网络内访问 OSS 时，使用的内网 endpoint、地域和 Bucket 所在地域要对应；通过公网访问则不能误用只在特定网络可达的地址。endpoint、Bucket 名称、对象 Key 任一处不一致，都可能让待签名资源与实际访问资源不同。
4. 正确传递 STS 临时凭证
使用 STS 时，SecurityToken 是签名上下文的一部分，不能只替换 AccessKey ID 和 Secret。代码若遗漏 Token、Token 已过期，或函数实例缓存了旧凭证，就会出现请求签名与服务端校验信息不一致。
更稳妥的做法是让 FC 通过服务角色获取临时凭证，并使用官方 SDK 的凭证提供链，而不是把长期 AK/SK 硬编码在代码或环境变量中。应用需要处理凭证刷新和失败重试，但重试不应无限进行：先判断是否为凭证过期或配置未刷新，再决定是否重新获取凭证。
5. 签名修复后再处理跨账号授权
如果错误已经变成 AccessDenied，再检查 FC 所属账号、OSS Bucket 所属账号、RAM 角色信任关系，以及 Bucket Policy 是否允许所需的 GetObject、PutObject 等最小操作。跨账号场景要同时核对身份链路和资源策略，不能只给函数绑定一个角色就认为授权完成。
权限策略不应写成“全资源、全操作”。按函数实际用途限制 Bucket、前缀和动作范围，既能降低误操作风险，也能让错误更容易归类。
用一条最短路径定位问题
可以按下面的顺序执行，避免在多个变量之间来回试错：
- 记录错误码、请求 ID、地域、Bucket、对象 Key 和 endpoint。
- 确认 FC 运行时加载的是哪一套凭证，并检查 STS Token 是否存在且未过期。
- 固定 SDK 版本，确认签名版本、HTTP 方法、请求头和资源路径一致。
- 检查运行环境时间同步，以及函数到 endpoint 的网络可达性。
- 若错误仍是
SignatureDoesNotMatch，导出脱敏后的签名调试信息，不要先扩大权限。 - 若错误变为
AccessDenied，再按 RAM、角色信任关系和 Bucket Policy 排查授权。
提交工单或寻求支持时，至少准备函数名称、地域、Bucket、发生时间、错误码、x-oss-request-id、SDK 版本和脱敏后的请求上下文。完整信息比反复重启实例更有助于定位。
如何减少签名错误反复出现
让凭证管理替代手工复制
优先使用 FC 服务角色或其他受控的临时凭证机制，减少长期密钥在代码、环境变量和流水线之间复制。密钥轮换应当有明确的发布步骤，并在变更后执行读写冒烟测试。
固定依赖和配置
将 SDK 版本、签名版本、endpoint 和地域配置纳入版本管理；开发、测试、生产环境只通过配置项切换，不要让每个环境隐式依赖运行时内置版本。
保留可审计的失败日志
日志中记录错误码、请求 ID、配置版本、凭证来源、SDK 版本和 endpoint 等非敏感信息，并对签名失败设置告警。这样既避免泄露密钥，也能在偶发故障发生后还原请求链路。
FC 访问 OSS 的签名问题，核心不是“权限越大越容易成功”，而是客户端和服务端必须对同一组凭证、时间和请求内容得出同一个签名。先分清错误类型，再按密钥、算法、时间、凭证和授权的顺序收敛范围，通常比盲目修改策略更快。