成熟的自动化，知道"墙"在哪：凭证为什么会过期，以及怎么优雅处理

通用工程思想 · 编程博客 · 第 2 篇 主题：你费心存下来的登录凭证不是永久的。它早晚会过期、会被要求"重新验证"。怎么面对这件事？

---

开场一个比喻

你不会觉得"门禁卡办一次，终身都能刷"吧？——大多时候过段时间就得重新激活。为什么呢？不是为了麻烦你，而是安全：卡万一丢了、落到别人手里呢？

你程序里那份"登录凭证"，和门禁卡完全是一回事。它不是永久的，这是设计使然，不是意外。 越早明白这点，越不会在项目里两头焦头烂额。

---

一个要戳破的泡：凭证会过期

很多人配置好凭证后，就以为"一劳永逸"了。直到某天跑出来的日志突然满屏报错，"需要重新登录"——才惊觉：哦，它失效了。

而且它失效的原因还不止"时间到了"一种：

失效原因	大白话
过期	凭证设了有限寿命，到点作废
平台强制刷新	平台规则改版，统一要求旧凭证重新验证
被风控	检测到"异常访问"，临时吊销凭证要求人确认
多端冲突	别处登录把旧凭证挤掉了

结论很硬：你是控制不了"凭证什么时候作废"的，那掌握在平台的规则手里。 成熟的方案，从不指望"永远有效"。

---

那好设计该怎么做？

面对"凭证一定会过期"，有两类做法：

❌ 坏做法：假装不会过期

• 存一次就撒手不管，"应该没事吧"。
• 后果：某个深夜定时任务爆发，无人知晓地挂了几天；或者硬着头皮用失效凭证反复试，反而加深风控。

✅ 好做法：提前检测 + 优雅重登

把"过期"当成一个预期内会发生的事件来设计，而不是"不该发生的意外"。具体两步：

1. 提前检测：每次开工前，先悄无声息地确认"这份凭证还灵不灵"——不灵就立刻知道，而不是做到一半才炸。
2. 优雅重登：检测到失效，就清清楚楚地停下来、告诉你"去重新登一次吧"，而不是崩溃、不是硬闯、不是气急败坏地重试。

这套"检测 + 优雅告知重登"的思路，就是本篇最想让你带走的。

---

为什么"知道墙在哪"才叫成熟

一句值得反复回味的话：

成熟的自动化，不是不撞墙，而是知道墙在哪、撞了怎么处理。

不成熟的样子：撞了墙，懵了，或者死磕着继续撞。 成熟的样子：知道这面墙大概率会在某处出现，提前在撞之前就先探路（检测）；真撞上了（过期/风控），也知道路线（停下、告知、引导重登），而不是原地打转。

这跟"异常处理"的哲学完全一致——不要祈祷不出错，而是接受一定会出错，然后把"出错怎么办"设计掉。

---

用的时候注意（边界）

• 检测别太频、也别太懒：每次都全量验证慢；不验证又危险。按"关键节点"检测（比如每次开工前、每次要动外部前）是平衡点。
• 停 ≠ 崩溃：检测到失效而停下，应该是有礼貌、有提示的"请重新登录"，而不是报一屏红色堆栈。
• 别急着自动重登：涉及真人扫码/验证码的，别把它们也自动化"绕过"——既可能失败，也可能触发封禁。该真人就真人（见第 1 篇）。

---

落地检查清单

• 是否有提前"检测凭证还灵不灵"的机制？
• 凭证失效时，是否会"优雅停下 + 明确告知重登"，而非崩溃或硬闯？
• 是否在关键节点检测（而不是过于频繁或完全不管）？
• 是否避免了把"真人验证"也硬自动化（防封禁）？

---

一句话带走

"凭证一定会过期——这不是意外，是安全设计。成熟的做法是把'过期'当预期事件：提前探路、优雅停下、引导重登，而不是假装它永不过期、或撞了墙原地打转。"