我以为 token 刷新是个简单事。

cookie 快过期了，触发一次接口、拿新的 cookie、写回去——几行代码。

跑了一段时间发现完全不是。

第一个意外是滑块。刷新接口本身就会触发风控验证。你以为在调一个 API，平台那边可能弹给你一个滑块。我得在刷新链路里嵌入完整的滑块识别，识别失败还要支持人工兜底。

第二个意外是有头模式白屏。我让 Playwright 启了带界面的浏览器去刷新，结果在 Docker 里显示一片白。后来发现是 xvfb 的虚拟显示和 Chromium 的渲染时序对不上。这一段调了三天。

第三个意外是会话回写。滑块过了之后，平台会发一个新的 session cookie 给你。我的代码一开始没接住——刷新成功了，但 cookie 没存对，下一次接口又被拒了。这种”成功的失败”最难调。

第四个意外是人脸验证。某次刷新触发了人脸——我项目里根本没准备这种情况。临时加了一个人脸通知模板，让 app 把验证链接推到我手机，人介入一下。

第五个意外是并发刷新。同一个账号多个地方触发刷新，可能同时去抢同一把锁。我加了 in-flight 预占机制，让后来的等前面的，避免重复触发风控。

写到现在我才接受一件事——

刷新一个 token 不是”调一次接口”。

是一整条会话恢复链路：会失败、会被识别、会被改写、会撞上意外。

这件事我大概会一直接着改。