密钥轮换必须由应用主动发起，python 及其加密库不支持自动到期换密；需显式调用轮换函数，并同步更新环境、存储及多进程/多服务间密钥状态，jwt 轮换后需配合黑名单与多密钥验证。
密钥轮换必须由应用主动发起，Python 本身不自动触发
Python 标准库和常见加密包（如 cryptography、pyca/argon2）都不内置“到期自动换密钥”机制。密钥生命周期管理完全在业务逻辑层，不是语言或库的职责。
常见错误是以为调用 generate_key() 或配置了 expires_in=3600 就能自动轮换——其实那只是个时间戳，没任何调度能力。
- 轮换动作必须显式调用，比如在用户登录后、API 请求前、或定时任务中执行
rotate_secret_key() - 如果依赖环境变量或文件加载密钥，轮换时得同步更新
os.environ或写入磁盘，否则后续load_key()仍读旧值 - 多进程部署下，各 worker 进程不会共享内存中的密钥变量，单独轮换一个进程无效
用 APScheduler 做定时轮换要绕开 fork 安全陷阱
在 Flask/FastAPI 等 Web 框架里直接启 APScheduler 的 BackgroundScheduler，常遇到子进程密钥不同步、信号中断导致轮换失败等问题。
根本原因是：Linux 下 fork() 后子进程会复制父进程内存，但 scheduler 实例无法跨进程通信；且某些加密后端（如 OpenSSL）在 fork 后调用 rand_bytes() 可能卡死或返回弱随机数。
立即学习“Python免费学习笔记（深入）”；
- 只在主进程（PID == 1）中启动 scheduler，用
if os.getpid() == 1:判断 - 轮换函数内避免调用
os.urandom()或secrets.token_bytes()—— 改用主线程预生成并安全传递 - 别把新密钥存进全局变量，改用线程安全的
threading.local()或外部存储（Redis、Vault）
JWT 场景下轮换后旧 token 并非立即失效
即使你已调用 rotate_signing_key()，已签发的 JWT 仍能被 jwt.decode() 验证通过，直到其 exp 字段过期。这是 JWT 协议设计决定的，不是 bug。
真正要实现“强制提前失效”，得配合状态检查：
- 维护一个
revoked_jti_set（Redis Set 最合适），在轮换时把所有未过期的活跃 jti 加入其中 - 每次
jwt.decode()后额外调用check_if_revoked(jwt_payload['jti']) - 注意
jwt.encode()用的新密钥，但jwt.decode()必须支持多密钥验证——传入列表如[new_key, old_key]，否则刚轮换那段时间的请求全 401
轮换失败时最容易被忽略的是密钥使用方缓存
你以为改了服务端密钥就完了，但客户端 SDK、Nginx 的 auth_request 模块、甚至数据库连接池里的 pgcrypto 函数，可能都缓存着旧密钥或密钥指纹。
典型表现是：轮换后部分请求成功、部分 403，日志里反复出现 InvalidSignatureError 或 BadSignature，但查密钥加载逻辑又没错。
- 检查所有调用方是否硬编码了
SECRET_KEY字符串，而非从统一配置中心拉取 - Nginx 用
auth_request转发鉴权时，确认它没把密钥写死在set $secret "xxx"里 - PostgreSQL 中用
pgp_sym_encrypt()加密的数据，轮换密钥后无法解密——这类数据必须提前用新密钥重加密
密钥轮换从来不是改一行代码的事，而是查清所有密钥消费路径、确认每个环节支持热加载、再设计回滚开关的过程。漏掉任意一个下游缓存点，都会让轮换变成一场静默故障。
