refresh token过期后无法获取新access token，本质是refresh token已失效（过期、被吊销或强制登出）；应手动更新存储、用json序列化、设文件权限、防并发覆盖、后端加密存redis并校验时效。
refresh token 过期后拿不到新 access token
本质是 refresh_token 本身也过期了，或已被服务端作废（比如 OAuth2 提供商强制单设备登录、用户主动登出、token 被泄露后吊销）。不是代码没调用 refresh，而是它已失效。
实操建议：
立即学习“Python免费学习笔记（深入）”；
- 每次成功刷新后，立刻用新
refresh_token替换本地存储的旧值——很多 SDK（如requests-oauthlib）默认不自动更新refresh_token字段，得手动提取并保存 - 检查授权服务器文档是否支持「轮换式 refresh token」：若返回的
refresh_token和上次不同，说明启用了轮换；若始终不变，那它就是长期有效的，需额外防范泄露 - 捕获
401 Unauthorized或响应中"error": "invalid_grant"，这是refresh_token失效的明确信号，别再重试，应跳转重新授权
用 pickle 存储 token 导致反序列化失败或执行任意代码
pickle 不安全，且跨 Python 版本/环境容易出错。一旦 token 字典结构微调（比如新增字段），旧 pickle 数据就无法加载。
实操建议：
立即学习“Python免费学习笔记（深入）”；
- 改用 JSON 序列化：用
json.dump()写入，json.load()读取，只存字典字段（access_token、refresh_token、expires_at等），不存函数或类实例 - 文件权限必须设为仅当前用户可读写：
os.chmod(token_file, 0o600)，尤其在 Linux/macOS 上，避免被其他用户窃取 - 不要把 token 存进 Git 仓库或日志——哪怕只是调试时
print(token_dict)，也得删掉或加掩码
多进程/多线程下并发刷新导致 token 覆盖冲突
两个线程同时发现 access_token 过期，都去调 refresh，然后都写回本地存储，后写的会覆盖先写的，导致其中一个线程拿到的 access_token 突然失效。
实操建议：
立即学习“Python免费学习笔记（深入）”；
- 加文件锁：用
portalocker或flock（Linux/macOS）确保同一时间只有一个进程在刷新和写入 - 更轻量的做法是内存标记 + 原子写入：首次检测到过期时，设置一个全局
_refreshing = True，其他线程等待几秒后直接读新文件，而不是各自发起请求 - 如果用数据库存储 token，用带条件的 UPDATE（如
WHERE refresh_token = ? AND expires_at > ?）避免覆盖旧有效 token
Flask/FastAPI 中 token 存在 session 或 cookie 里被前端窃取
HTTP-only + Secure 的 cookie 可防 XSS 读取，但若没设 SameSite=Strict 或 Lax，仍可能被 CSRF 利用；而存在普通 session（如 Flask 的 session）里，底层其实是签名 cookie，refresh_token 一旦泄露，攻击者就能无限续期。
实操建议：
立即学习“Python免费学习笔记（深入）”；
-
refresh_token绝对不要进前端——后端用httpx或requests直接调第三方 API，前端只拿短期access_token（有效期 ≤ 15 分钟） - 后端存储推荐方案：加密后存 Redis，key 带用户 ID 和随机 salt，TTL 设为比
refresh_token过期时间短 5 分钟，避免脏数据残留 - 如果必须透传
refresh_token给前端（极不推荐），至少用Web Crypto API在浏览器内加密，密钥由后端动态下发且单次有效
最麻烦的不是怎么存，是怎么保证每次写入都原子、每次读取都校验时效、每次刷新都确认服务端是否真接受了新 token——这些细节一漏，安全模型就塌了一半。
