接口一直返回鉴权失败时，先别急着换密钥。通常可以从三条线索区分成因：完整返回信息指向哪一类校验、密钥管理页显示的生成时间与重置记录、权限列表中目标接口是否已开通。把这三条线索对齐，多数情况能判断出该改配置、该申请权限，还是该修签名，而不是反复重试同一份代码。

鉴权失败的定位顺序建议是：先打印完整响应体，拿到错误码与错误描述；再核对密钥生成时间与近期是否重置；接着对照权限列表确认目标接口是否已开通；最后才检查签名与请求头拼接顺序。只换密钥不看错误信息，容易在同一处反复失败；只看一句“鉴权失败”也分不清方向。具体判断需要结合自己的返回内容和控制台页面状态确认。

先把返回的原始错误信息完整打出来

不要只截取“鉴权失败”这一句，也不要只看 HTTP 状态码。服务端通常在响应体里给出错误码、子错误码和描述字段，这些字段是区分密钥问题与权限问题的第一依据。下面是一段通用请求骨架，替换 url、headers、payload 即可；关键点是打印完整响应体和状态码，而不是只打印异常信息。

import logging, time, requests

logging.basicConfig(
    level=logging.INFO,
    format="%(asctime)s %(levelname)s %(message)s",
)

def call_api(url, headers, payload):
    started = time.time()
    try:
        resp = requests.post(url, headers=headers, json=payload, timeout=10)
    except Exception as e:
        logging.error("request_exception=%s", repr(e))
        raise
    logging.info("request_ts_ms=%s url=%s status=%s cost_ms=%s",
                 int(started * 1000), url, resp.status_code,
                 int((time.time() - started) * 1000))
    logging.info("resp_body=%s", resp.text)
    return resp

日志里保留请求时间戳的通用做法是使用 logging 的 asctime，或像上面一样显式记录 request_ts_ms。时间戳的价值在于：当密钥被重置、权限被调整之后，你能对照失败请求发生的时间段判断问题是否已经变化。响应体里可能包含令牌等敏感字段，落盘前建议做脱敏，例如只保留错误码、错误描述和字段名。

核对密钥的生成时间与是否被重置过

密钥管理页通常能看到这些信息项：应用 ID、密钥类型（应用私钥/公钥或平台公钥）、生成时间、最近更新时间或重置记录、密钥状态。如果生成时间很晚而配置文件里的密钥很旧，或者页面显示近期重置过，而代码仍在用旧值，就会表现为持续鉴权失败。先确认页面上生效的是哪一份，再回头对代码里的读取路径做检查。

配置检查建议用命令把可能的读取入口全部列出来，而不是只翻一个文件：

grep -rn "APP_PRIVATE_KEY\|app_private_key\|private_key" . \
  `--include`="*.py" `--include`="*.yaml" `--include`="*.yml" `--include`="*.json" `--include`="*.env"

环境变量与硬编码的差异需要特别留意：环境变量通常覆盖配置文件，但前提是代码的加载顺序确实如此；硬编码则容易残留旧密钥，改了一处不代表另一处也改了。可以用一段小脚本确认当前进程实际读到的密钥来源和指纹，只打印长度与哈希前几位，不打印明文：

import hashlib, os

env_key = os.getenv("APP_PRIVATE_KEY")
file_key = open("config/keys/app_private_key.pem").read()
key = env_key or file_key
print("source_env=", bool(env_key))
print("key_len=", len(key))
print("key_hash8=", hashlib.sha256(key.encode()).hexdigest()[:8])

对照权限列表确认目标接口是否在已开通范围内

密钥没错但没权限，是很容易被忽略的一类。查看路径通常是：开放平台控制台进入应用详情，再找到接口权限或已开通产品列表，逐项核对目标接口名、权限包名称和开通状态。这里只给观察方法，不下断言：如果返回描述里出现权限、无权限、未开通、应用未授权这类关键词，而签名或密钥相关字段没有单独报错，可以优先怀疑权限；如果返回描述指向签名校验、密钥非法、证书错误，则先查密钥与签名。

权限页面还可以留意两点：一是接口是否只是“可申请”而没有“已开通”；二是权限是否绑定到了当前使用的应用 ID。把自己实际调用的接口名与页面列表逐一比对，比凭印象判断更可靠。

检查签名或请求头的拼接顺序

参数顺序、时间戳、编码不一致，都会让签名校验不通过。下面是通用签名骨架，字段名和签名算法按你的接入方式替换，重点是拼接规则要保持前后一致：

params = {
    "app_id": "APP_ID_PLACEHOLDER",
    "method": "your.method",
    "charset": "utf-8",
    "sign_type": "RSA2",
    "timestamp": "{{timestamp}}",
    "version": "1.0",
    "biz_content": "{\"key\":\"value\"}",
}
content = "&".join(f"{k}={params[k]}" for k in sorted(params))
print("sign_source=", content)
# sign = sign_with_your_private_key(content)

常见拼接错误对照：参与签名的参数未按约定排序；空值参数在签名与发送阶段处理不一致；时间戳单位秒与毫秒混用；参数被编码两次或该编码时没有编码；请求头里的字段与实际参与签名的字段不一致；biz_content 在签名用的原文与最终发送的 JSON 不一致。验证方式是用同一组参数、同一时间戳重放请求，并记录签名原文与最终发送体，逐字段比对。

用一份最小自检脚本收敛变量

把业务代码排除在外，只做请求、打印、退出码三件事。这样每次失败只对应一个变量，不会把业务参数问题误判成鉴权问题。

import sys, requests

def main():
    url = "https://your-gateway-endpoint"
    headers = {"Content-Type": "application/json"}
    payload = {
        "app_id": "PLACEHOLDER",
        "method": "PLACEHOLDER",
        "sign": "PLACEHOLDER",
    }
    try:
        r = requests.post(url, headers=headers, json=payload, timeout=10)
    except Exception as e:
        print("NETWORK_ERROR:", repr(e))
        return 20
    print("HTTP_STATUS:", r.status_code)
    print("BODY:", r.text)
    if r.status_code == 200:
        return 0
    return 10

if __name__ == "__main__":
    sys.exit(main())

三种结果的下一步动作：退出码 0 表示请求已被接受，鉴权段大概率通过，这时把业务参数、字段类型和必填项逐项对回业务代码；退出码 10 表示服务端明确返回错误，先读错误码与子码，再按前面步骤核对密钥与权限，不要直接改签名；退出码 20 表示没有拿到有效响应，先查网络、网关地址、超时与请求体格式，再谈鉴权。脚本建议放在不加载业务依赖的独立目录里运行，并且只保留一个密钥来源，避免环境变量、配置文件和硬编码三处值互相覆盖。