Claude Code 的「账号」到底是什么

写在前面

过去两年，"我要用 Claude Code / Codex" 这件事，从"装个包、填个 Key"变成了一个需要认真做技术选型的问题。

我在社区里反复看到同一批困惑，而且提问的人往往并不外行：

• "我明明买了 API 额度，为什么网页版还是让我登录？"
• "同样的账号，昨天跑得好好的，今天怎么就一直转圈？"
• "为什么中转服务商都强调 IP，我自己挂个更贵的代理不行吗？"
• "托管方案说'环境分配后不再变动'，这听着不是很保守吗？换个更好的不是更快？"
• "一个跑了两分钟的长任务断在半路，为什么重试一次反而更亏？"

这些问题看起来分散，其实指向同一件事：大多数人把「账号」当成了一个不可再分的原子概念，而它实际上是三类凭据 + 两级额度窗口 + 一套身份一致性约束的叠加体。不把这三层拆开，上面每一个问题都无解。

这篇文章不讲怎么"薅"，也不给任何对抗性配方。它只做一件事：把工程约束讲清楚——为什么会这样，以及在这些约束下，不同方案各自的天花板在哪里。

全文约一万字，含 5 张原理示意图。读完你应该能自己回答上面五个问题，并且知道自己该选哪条路。

目录

• 第一章 凭据学：一个账号身上挂着三样东西
  • 1.1 先看结论
  • 1.2 两条通道，从计费系统那一刻就分岔了
  • 1.3 API Key：无状态的计量入口
  • 1.4 OAuth 令牌：带订阅额度的身份
  • 1.5 Session 凭据：网页那一层
  • 1.6 派生关系：谁能换出谁
• 第二章 额度学：滚动窗口如何决定你的体感
  • 2.1 两级窗口
  • 2.2 窗口是按账号统计的
  • 2.3 多人共用时的排队效应
  • 2.4 读懂 429：不是所有"限流"都一个意思
  • 2.5 为什么"平均分配"在窗口模型下不成立
• 第三章 身份一致性：账号最怕的不是被用，是"看起来换了个人"
  • 3.1 服务端能观察到什么
  • 3.2 一致性比"高级"更重要
  • 3.3 环境固定为什么是个工程约束，而不是懒
  • 3.4 一个必须说清楚的边界
• 第四章 多租户隔离：共享方案的天花板在哪
  • 4.1 会话隔离
  • 4.2 额度隔离
  • 4.3 故障隔离
  • 4.4 三者能同时满足吗
• 第五章 流式响应：中转层最难的一段
  • 5.1 为什么不能"收完再转发"
  • 5.2 四种断法，长得一模一样
  • 5.3 重试的不幂等性
  • 5.4 超时设定的两难
  • 5.5 背压：容易被忽略的一环
• 第六章 接管与还原：托管客户端在你机器上做什么
  • 6.1 问题定义
  • 6.2 备份—覆写—还原：三段式
  • 6.3 合并，而不是替换
  • 6.4 幂等与"首份为准"
  • 6.5 崩溃安全：中途断电会发生什么
  • 6.6 收尾时的对称性
• 第七章 可观测性：你应该要求看到什么
  • 7.1 一个朴素的判据
  • 7.2 具体应该能看到哪些
  • 7.3 一个反面模式
• 第八章 设备绑定：为什么凭据要发给"这台机器"
  • 8.1 一次登录，多台设备
  • 8.2 吊销为什么必须是"一等公民"
• 第九章 选型：一张决策表
  • 9.1 别只算入场成本，还要算退出成本
  • 9.2 这两类不必二选一
• 第十章 九个误区，一表回顾
• 结语

第一章 凭据学：一个账号身上挂着三样东西

1.1 先看结论

一个 Claude 或 ChatGPT 账号，技术上不是"一个东西"，它至少派生出三类互不等价的凭据：

最反直觉、也最常被踩的是最后一列——三类凭据能开的门不一样，而且不能互相替代。

1.2 两条通道，从计费系统那一刻就分岔了

很多人以为这两条只是"入口不同、后面都通向同一个模型"。技术上确实通向同一批权重，但它们在计费、鉴权、限流三个维度上是彻底分离的两套系统：

这种分离是刻意设计的，因为两类用户要的东西根本不同：程序化调用方要可预测的单价、可水平扩展的并发、不依赖"有人在线"的稳定性——无状态密钥最好实现；个人订阅用户要"一口价随便用"，厂商为了不被重度用户拖垮必须引入配额，而配额要生效就必须能把消耗归到某个人头上——于是必须有身份，必须有登录。

一旦想明白这一层，很多"为什么不能……"的疑问就自动消解了。不是厂商不肯打通，是打通之后两套计费口径没法自洽。

1.3 API Key：无状态的计量入口

API Key 的技术特征可以概括为四个字：无状态计量——它不绑定任何登录会话，你在哪台机器、用什么客户端都一样，带上这串字符服务端就认；计费按 token 结算。

正因无状态，它极其适合程序化调用（CI、后端服务、批处理），不需要"有个人坐在那里登录"。

也正因无状态，它开不了任何面向人的界面。网页版和桌面客户端要的不是"能计费的凭据"，而是"已登录的身份"——这在服务端是两套完全不同的鉴权路径。

这是"我买了 API 额度为什么网页版还要登录"的全部答案。不是产品设计得别扭，是你手里那串东西从来就不是拿来开网页的。

1.4 OAuth 令牌：带订阅额度的身份

第二类凭据是 OAuth 令牌，通常是一对：一个短期的访问令牌（access token），一个用来续命的刷新令牌（refresh token）。

它和 API Key 的根本差别在于来路：

• API Key 是你在后台"点一下创建"出来的，凭空产生。
• OAuth 令牌是从一个已经登录的会话里换出来的——必须先有"人登录过"这个事实，才谈得上签发令牌。

两个后果：

它挂在订阅额度上，不是计量额度上。 用官方 CLI 或编辑器插件跑任务，消耗的是订阅套餐那份配额——这也是为什么同一家厂商，"订阅"和"API"是两本账。

它有派生前提。 能不能换出令牌，取决于源会话所属账号的档位。免费档通常派生不出可用于命令行和编辑器的令牌——不是哪个中间方"不给"，是授权范围在签发那一刻就被限定了。

实践含义很直接：如果你打算用命令行或编辑器插件，那么"手上有个账号"这句话必须补全成"手上有个付费档的账号"。这一条在下单之前就该确认，而不是配到一半才发现。

1.5 Session 凭据：网页那一层

第三类是网页会话凭据，形态上就是浏览器里的那个 Cookie。

它的技术特征是与登录环境强相关。会话是在某一次具体的登录动作中签发的，服务端对"这个会话后续出现在什么样的环境里"是有观察的——环境突变，会话被要求重新验证是很正常的服务端行为。

这一点会在第三章展开，因为它是整篇文章里工程含义最重的一条。

1.6 派生关系：谁能换出谁

把三者的关系画成一条链：

邮箱登录  ──►  Session 凭据  ──►  （若账号档位允许）OAuth 令牌
                    │
                    └──►  网页版对话界面

API Key  ──►  计量接口     （与上面那条链完全平行，互不相通）

几个必须记住的性质：

1. 箭头是单向的。 有了 Session 可能换出 OAuth 令牌；反过来不成立。
2. API Key 那条线是孤立的。 它不参与上面任何一步，也不能被上面任何一步换出。
3. 配置"完成"是分级的。 拿到 Session 意味着网页版可用；再拿到 OAuth 令牌，命令行和编辑器才可用。前者是必要步骤，后者是可选的第二步。

这条链解释了一个常见的困惑：为什么托管服务配好之后，往往是"网页版先能用，命令行稍后"。因为这确实是两步，而不是一步。任何把这两件事说成"配好就全都能用"的服务，要么是把第二步藏起来了，要么就是没考虑账号档位不够的情况。

第二章 额度学：滚动窗口如何决定你的体感

2.1 两级窗口

订阅额度的计量方式，和很多人的直觉不一样。它不是月度池子——不是"这个月给你 N 次，用完拉倒"。主流实现是滚动窗口（rolling window），而且通常是两级：

• 短窗口，数小时量级。它决定你"这一阵"能不能连着干活。这个窗口很小，所以撞上它是高频事件，尤其是在做大规模重构、让 agent 连续跑长任务的时候。
• 长窗口，数日量级。它决定你"这一周"的总盘子。撞上它的频率低，但一旦撞上，恢复周期也长。

"滚动"的意思是窗口边界相对于此刻往前推，不固定在某个整点。所以不存在"熬到零点就重置"，只有"最早那批消耗滑出窗口，额度才一点点还回来"。

2.2 窗口是按账号统计的

这是全章最关键的一句话，也是后面很多结论的地基：

两个窗口都按账号统计，不按人、不按设备、不按 IP。

服务端的视角里，一个账号就是一个配额主体。至于这个账号背后坐着一个人还是十个人，它既不知道，也不需要知道。

2.3 多人共用时的排队效应

把 2.1 和 2.2 拼起来，共享账号方案的一个结构性问题就浮出来了。

假设一个账号挂了 5 个用户，每人日常用量都不大，看起来完全吃得消。但滚动窗口对瞬时并发极其敏感：其中一人启动一次大规模重构，短窗口二十分钟内被拉到 90%，剩下 4 人毫无征兆地全都开始撞墙——而且看不到是谁、看不到还剩多少、也无从判断何时恢复，因为恢复取决于最早那批消耗何时滑出，而那批不是他们产生的。

这不是"调度没做好"能解决的，是配额主体粒度决定的。只要配额按账号统计而账号被共用，这个耦合就一定存在。

2.4 读懂 429：不是所有"限流"都一个意思

撞墙时你拿到的通常是一个 HTTP 429。但 429 在不同层面上含义完全不同，分不清就会做出错误应对：

第二种最容易被误判。很多客户端的默认重试策略是"退避后再试"，但在窗口配额场景下，重试不仅无效，还会把恢复时间往后推——因为每一次失败请求可能仍然计入统计。

判断依据其实很简单：看响应里有没有给出明确的重置时刻。给了，说明是配额，老实等；没给且间隔很短，才是速率限制，可以退避重试。

这也是为什么"能看到剩余额度和重置倒计时"不是一个花哨功能，而是排障的必要信息。看不到的话，你在撞墙时能做的只有瞎猜。

2.5 为什么"平均分配"在窗口模型下不成立

一个自然的想法是：那我在中间做个配额分配，每人限 1/5 不就行了？

在滚动窗口模型下，这个想法有两个绕不开的问题。

第一，你分不准。 中间层能统计的是自己转发出去的请求数，但服务端的窗口口径（怎么加权、怎么折算、边界怎么滑）是它自己的实现细节，不对外承诺。你按自己的口径分，和它按它的口径算，两条曲线必然对不齐——对不齐的部分就是"我这边还剩很多，那边已经 429 了"。

第二，分准了也不划算。 假设你真的能精确五等分，那每个人拿到的就是账号额度的 1/5。这时候用户实际买到的东西，已经不是"一个订阅"，而是"一个订阅的五分之一"——那还不如把话说清楚。

所以共享方案真正的定位应该是：用量不大、能接受偶发排队、看重的是低门槛和低起步成本。这是一个非常正当的定位，只是它和"稳定可预期"是两件事。

第三章 身份一致性：账号最怕的不是被用，是"看起来换了个人"

3.1 服务端能观察到什么

先把话说在前面：这一节不讨论任何对抗手段，只讨论一个中性的事实——服务端在鉴权时能观察到的信号，远不止"你带没带凭据"。

任何一个成熟的线上服务，在会话续期、敏感操作、异常检测这些环节，都会参考一组上下文信号。这些信号大致分三层：

这些信号服务端怎么加权、阈值定在哪，没有任何一方对外公开，也不该有人声称自己知道。凡是拿着一张"规则表"告诉你"照这个做就绝对安全"的，基本可以判定为不可信。

3.2 一致性比"高级"更重要

但有一条经验规律，是可以从系统设计原理推出来的，而且相当稳健：

对异常检测系统来说，"突变"比"某个具体取值"更值得注意。

异常检测本质上是在建模"正常是什么样"再找偏离。一个账号长期在稳定的上下文里活动，这组上下文本身就是它的基线；基线越稳，后续每次访问的解释成本越低。反过来，今天在这明天在那，即便每一次单看都正常，变化本身就是需要被解释的。

这就推出了本文最反直觉、但也最重要的一条工程结论：

稳定，比"更好"更有价值。

很多人的直觉是"我换一个更快更干净的网络出口，账号应该更安全才对"。但从异常检测的角度，你做的事情是制造了一次突变。突变的成本，很可能高于你换来的那点质量提升。

3.3 环境固定为什么是个工程约束，而不是懒

这就解释了托管类方案里那条看起来很保守的规矩：运行环境一旦分配，就不再变动。

外行容易读成"服务商图省事"。实际上它是主动付出成本换来的约束——放弃"哪条链路更优就动态调度到哪条"这种听着先进的做法，换每个账号的基线长期不动。

这个取舍的依据就是 3.2：账号的可用性，对上下文稳定性的敏感程度，远高于对上下文质量的敏感程度。 用一点点质量上限，换基线不抖，是笔划算买卖。

同样的逻辑也解释了另一个设计：换账号时不换环境。账号和运行环境是两层，需要更换账号时，只动账号那一层，环境保持不变——因为如果两层一起换，就等于把"新账号"直接放进一个"新上下文"里，两个变量同时动，是最糟糕的组合。

3.4 一个必须说清楚的边界

写到这里必须插一句，因为这是这个领域里最常见的误导：

没有任何第三方能保证一个账号"永远可用"。

账号是否可用，最终由官方判定，不由任何中间方决定。任何服务商——包括做托管的——能做的只有两件事：

1. 降低不必要的风险：不制造无谓的突变，不做明显异常的操作模式；
2. 把状态如实告诉你：出了问题第一时间标出来、通知你，而不是让你对着一个错误页自己猜。

至于"保号""包不封""封了赔"，凡是这类承诺，要么是没想清楚，要么是知道自己做不到还在说。判断一个服务商是否专业，看它敢不敢把这条边界写在明面上，比看它承诺得多漂亮有用得多。

第四章 多租户隔离：共享方案的天花板在哪

第二章讲了额度耦合，但那只是共享模式三个隔离难题中的一个。完整地看，共享一个账号要同时解决三种隔离：

4.1 会话隔离

问题：同一账号下的对话天然堆在一起，A 打开列表不该看到 B 的会话。通常解法：中间层维护一张"对话归属"表，按用户过滤。

天花板：过滤是展示层的，不是存储层的。对话本身仍在同一个账号名下，账号级别的任何操作（停用、官方清理）对所有人一视同仁。

而且这张归属表的工程要求，比它看起来高得多。展开讲讲，因为它是"共享方案的复杂度到底藏在哪"最好的例子。

一、关键路径上的读。 每次打开对话列表都要查，延迟直接体现在体感上——自然会想到用内存缓存做快路径。

二、绝对不能丢。 这就和上一条打架：缓存是易失的。只有缓存这一份，那么进程重启、缓存驱逐、实例迁移任何一个发生，所有用户的对话列表会同时清空。而且这种故障很恶劣——它看起来不像故障，用户看到空列表的第一反应是"我数据没了"，不是"服务挂了"。

三、得能重建。 前两条合起来只有一个解：双写 + 冷启动回灌——持久存储作真源，缓存作快路径，冷启动时从真源把缓存灌满。

这套东西的复杂度不低，而它解决的还只是三种隔离里最容易的那一种。这也侧面说明了一件事：

共享方案看起来省钱，是因为成本从订阅费转移到了工程复杂度上。 这笔成本不会消失，只是换了个地方支付——而且一旦某个环节没做扎实，代价是由用户承担的。

要求四：排序键的坑。 补充一个非常具体、但特别容易踩的细节。这类表需要按"最近活跃"排序，而"时间"这个字段一旦跨了时区解释，就会出问题——写入端和读取端如果对时区的理解不一致，同一个时刻会被换算成不同的值，排序直接乱掉。

稳妥做法是排序键存原始时间戳（整数），不存带时区语义的日期时间类型；需要给人看的那份另存一列。整数不参与任何时区换算，天然免疫这类问题。

4.2 额度隔离

第二章已经讲透了：做不到。配额主体是账号，粒度就在那里。中间层能做的只有"我这边限一下流"，而这和服务端的真实窗口是两条对不齐的曲线。

4.3 故障隔离

问题：账号出问题时，影响面是所有挂在上面的人。

天花板：这是共享这个词的定义决定的，没有技术手段能绕过。一个账号出事，就是一群人同时出事。

4.4 三者能同时满足吗

答案是不能，而且原因很干净：

会话隔离可以靠中间层"装出来"，额度隔离和故障隔离必须靠拆分配额主体才能真正解决。

而"拆分配额主体"翻译成人话就是：一个账号只给一个人用。

这就是账号托管这条路线存在的全部理由。它并不比共享方案"高级"，它只是把问题挪到了唯一能真正解决的那个层次上——代价是每个人都要有自己的一份订阅，成本结构完全不同。

第五章 流式响应：中转层最难的一段

前面讲的是"账号"这个静态资产，这一章看一次请求在链路上经历了什么。AI 类服务有个和普通 API 截然不同的特征：响应是流式的，一次交互可能持续几十秒——这把很多本不成问题的事变成了硬骨头。

5.1 为什么不能"收完再转发"

最省事的实现是把上游响应完整读进内存再一次性发给客户端。普通 API 上没问题，流式场景就是灾难：首字延迟从几百毫秒变成整个生成时长——用户盯着不动的光标等三十秒，体验上跟卡死没区别。

所以中转层必须边收边转，而这意味着它在整个生成期间都得持有两条活跃连接。这是后面所有麻烦的根源。

5.2 四种断法，长得一模一样

链路上每一跳都可能断：客户端网络抖了、中转层实例重启了、跨网那段丢包超时、上游自己出错。问题在于这四种断法在客户端看来现象完全相同——流突然停了，没有任何区别性信息。

于是你无法根据现象判断该不该重试。可行的缓解是中转层在断流时补一个结构化的结束事件，把它知道的（断在哪一段、是否上游主动结束、有无错误码）带出来。做不到完美——断的若是中转层自己，它也发不出这个事件——但能覆盖大部分情况。

这里有个判断服务质量的实用技巧：看它断流时给不给你信息。什么都不说、直接静默结束的实现，说明它自己也没在追踪这件事。

5.3 重试的不幂等性

这是流式场景最反直觉的一点。

普通 API 的重试通常安全——失败没扣钱，重发即可。但流式响应在中断那一刻，上游可能已产出大半内容，额度实实在在消耗掉了。于是重试有了真实成本：额度双花（用户视角只成功一次，实际消耗两次）、拼不回去（生成带随机性，第二次接不上第一次）、账不透明（中转层默默重试，用户只会觉得额度掉得莫名其妙）。

首字是分水岭：

所以一个负责任的实现应该是：首字之前可以悄悄重试，首字之后如实报断。把断流包装成"看起来成功"，短期内投诉少了，长期是在用用户的额度买自己的好看。

5.4 超时设定的两难

流式场景下，超时值特别难定。

定短了，长思考任务会被切断——而这恰恰是 agent 编程的主力场景，一次大重构跑几分钟很正常。定长了，卡死的上游会一直挂着资源直到超时。

比"总超时"更合适的是空闲超时：不看总时长，只看距上一个数据块过去了多久。还在吐字就不打断，超过阈值没有任何数据才判定卡死。这思路和滚动窗口同源——都是把"绝对量"换成"相对于最近一次活动"，后者才真正反映健康状态。

5.5 背压：容易被忽略的一环

中转层从上游收数据的速度，和往客户端发的速度不一定一致。客户端消费慢（网络差、或干脆是个卡住的终端）而中转层还在全速拉，中间缓冲区就持续增长——单连接看不出问题，成百上千个并发一起涨就是内存被吃光。

正确做法是让下游消费速度反压到上游读取速度：客户端来不及收，就暂停从上游读。现代流式框架大多内置了这个机制，但手写转发逻辑极容易漏掉，而且它只在高并发下暴露，测试环境往往测不出来。

这一章可以概括成一句话：流式让"转发"这件事从无状态变成了有状态。 每多一跳，就多一处可能断的地方、多一份要维护的缓冲、多一次要做的重试判断。这也是为什么链路越短，体验通常越稳——不是因为短的更"高级"，而是因为可出错的环节更少。

第六章 接管与还原：托管客户端在你机器上做什么

这一章讲的是一个具体的工程问题，也是我认为整个托管方案里最容易被低估的部分。

6.1 问题定义

托管账号要在你自己的机器上跑官方客户端，而这些客户端的身份信息存在本机配置文件里。于是问题来了：你自己本来就有一份登录状态。

不加设计的实现会直接覆写它——托管期间你自己的号用不了，结束后还得重新登录一遍，而且很可能已经不记得原来配了什么。这个代价在很多方案里是被默默转嫁给用户的。

6.2 备份—覆写—还原：三段式

一个负责任的实现，会把它做成严格对称的三段：

接管前   把现状原样存一份
   ↓
运行中   托管配置生效，你原来的那份不受影响
   ↓
收尾时   把存的那份放回去，托管痕迹一并撤走

听起来简单，但要做对，有几个非平凡的细节。

6.3 合并，而不是替换

写配置应该做合并，而不是整份替换。 配置文件里除了身份信息，还有一堆用户自己的偏好、历史、项目级配置——整份替换就全没了。

正确做法是只写托管真正需要的那几个键，其余逐字节保留；撤销时也只摘掉那几个键。一个原本不含这些键的配置文件，走完一轮接管再还原，应该和没被碰过完全一致。

这也是为什么在描述这类方案时，"我们不改你的设置"是句假话，而"我们只写需要的那几项、其余原样保留"才是真话。前者用户不会信（他知道肯定要改），后者才经得起验证。

6.4 幂等与"首份为准"

最容易出 bug 的地方：备份必须幂等，而且第一份为准。 设想这个序列：

1. 接管，备份了你的原始配置 —— 此时备份 = 你的原件 ✓
2. 托管运行，配置被改成托管态
3. 因为某种原因（重连、切换、客户端重启）又触发了一次接管
4. 如果这次备份不加判断地又存一遍 —— 备份 = 托管态的配置 ✗
5. 收尾还原 —— 把托管态还给你，你的原件永久丢失

所以规则必须是：已有备份就绝不覆盖——第一份才是原件，后面每一次都是脏数据。

还有个容易漏的边界："原本没有这个文件"也是一种状态，必须被记录。否则还原时无法区分"把内容放回去"和"删掉我们创建的东西"，而不做区分的实现会给用户留下一个他从来没有过的文件。

6.5 崩溃安全：中途断电会发生什么

前面几条都假设流程能跑完。但真实世界里，进程会被 kill、机器会睡眠、磁盘会写满。所以还得问一句：在任意一步中断，系统处于什么状态？

把三段式拆成原子步骤看：

① 读取用户原始配置
② 写入备份文件            ← 断在这里：备份可能不完整
③ 写入托管配置            ← 断在这里：备份完好，配置是半截的
④ ……运行……
⑤ 从备份还原              ← 断在这里：配置可能是半截的
⑥ 删除备份（如需要）      ← 断在这里：配置已还原，只是多了个备份文件

危险的是 ② ③ ⑤ 三步——任何"写了一半"的配置文件，对客户端来说都是损坏。

标准做法是先写临时文件、再原子重命名。文件系统保证 rename 是原子的：要么你看到的是旧文件，要么是完整的新文件，不存在"半新半旧"。这一条几乎是所有配置写入场景的通用解，代价极低，但不做的话就会在极低概率下把用户的配置写坏——而这类 bug 的复现成本极高，往往要等到线上出事才被发现。

第 ⑥ 步的残留反而是安全的：多一个备份文件不影响任何功能，下次接管时"已有备份就不覆盖"的规则还会保护它。在这类设计里，宁可残留也不要丢失——这是一条很好的取舍准则。

6.6 收尾时的对称性

撤销必须和接管一样全面。 接管时动了三处（命令行、编辑器插件、桌面客户端指向），撤销就必须三处都撤。少撤一处的后果往往不是报错，而是静默降级——编辑器配置还指向一个已被删掉的可执行文件，插件找不到就悄悄退回内置版本，用户完全看不出接管已经失效，只觉得"最近怎么怪怪的"。

静默失败比报错难查十倍。这是这类客户端工程里最值得投入的一块。

第七章 可观测性：你应该要求看到什么

前面反复出现一个主题：看不见，就没法判断。这一章把它单独拎出来，因为它是选型时最容易被忽略、却最能区分服务商成色的一项。

7.1 一个朴素的判据

托管类服务本质上是代你持有一个资产并代你运维，信息不对称是天然的。所以判断它是否值得托付，最有效的单一指标不是技术宣传，而是：

它主动让你看到多少你本来看不到的东西。

因为公开状态是有成本的——摊开了，出问题时就没法含糊过去。愿意付这个成本的，通常是真做得住。

7.2 具体应该能看到哪些

还有两条加分项，也是很好的反向判据：

• 检测结果是否如实展示。 永远显示"一切正常"的面板，多半没在真检测。敢显示"尚未检测"和"检测失败"的，比永远绿灯的可信。
• 你能否主动发起一次检查。 被动等推送和主动验证是两种体验，后者才是掌控感的来源。

7.3 一个反面模式

值得警惕的一种设计：只给结论，不给依据。

比如面板上写着"线路健康"，但不告诉你这个结论是什么时候、基于什么得出的。这种设计的问题在于——当你的实际体验和它的结论冲突时，你完全无从判断是自己的问题还是它的问题。

好的做法是把"结论 + 时间 + 来源"一起给出："这是你 10 分钟前自己发起的那次检测的结果"，比一个孤零零的"健康"有用得多。

第八章 设备绑定：为什么凭据要发给"这台机器"

8.1 一次登录，多台设备

一个自然的问题：既然账号是我的，我在几台机器上用，应该无所谓吧？

技术上确实可以做成"一份凭据到处拷"。但成熟一些的做法是按设备签发：每台机器单独走一次授权，拿到属于这台机器的凭据。

这么做多了一步，换来三件事：

1. 可见性：你能看到有哪些设备在用、各自最近什么时候活跃过。
2. 可撤销：某台机器不用了、或者你不认识它，可以单独吊销，不影响其他设备。
3. 爆炸半径小：一台机器上的凭据泄露，影响范围就是那一台。

8.2 吊销为什么必须是"一等公民"

值得强调的是第 2 点。很多方案里，"吊销"是个事后补的功能，做得很敷衍。但从安全模型上看，凭据签发和凭据吊销必须是对称的一对——只能发不能收的系统，随着时间推移必然积累出一堆你自己都不知道还有效的凭据。

对用户来说，判断一个方案是否认真对待安全，看"我能不能自己吊销一台设备"，比看它宣传里写了多少安全词汇有效得多。

第九章 选型：一张决策表

把前八章的结论压缩成可操作的判断：

9.1 别只算入场成本，还要算退出成本

选型讨论里几乎没人提的一个维度：这条路走不通的时候，你要付出多少代价才能换掉？

这不是商务问题，是技术问题——退出成本几乎完全由耦合点的数量和深度决定。

按耦合深度从浅到深排一下：

三点值得注意。

API Key 的低退出成本被严重低估。 官方接口形态高度趋同，多数客户端都支持改 base URL——今天用 A 家明天换 B 家，成本接近于零。它几乎不锁定你。

判断托管方案退出成本的关键，就是第六章那套还原逻辑。 能干净还原的实现，退出时执行一次卸载即可；还原潦草的实现，你得自己一处处找回被改过的地方，而你根本不知道它改了哪些。所以第六章那些琐碎细节（首份为准、合并不替换、撤销对称）决定的不是"用着爽不爽"，而是你有没有随时走的自由。

代订账号耦合最深。 关键问题只有一个：不续了，这账号还是不是我的？ 不同服务商答案差别很大，出问题才问就晚了。反过来，自带账号是耦合最浅的托管形态——账号一直是你的，托管的只是运行它的那套环境。

9.2 这两类不必二选一

按量和订阅可以并存，成熟团队大多如此：交互式开发走订阅账号（要界面、要连续性），CI 与批处理走 API Key（要无状态、要并发）。两者技术特性互补，硬要二选一是在给自己找麻烦。

第十章 九个误区，一表回顾

结语

回到开头那五个问题，现在应该都有答案了：

• 买了 API 额度网页版还要登录——那是两条平行的鉴权路径，密钥换不出身份。
• 昨天好好的今天转圈——大概率是滚动窗口，而且如果账号是共用的，消耗它的人不一定是你。
• 为什么都强调固定而不是"更好"——异常检测建模的是"正常是什么样"，突变本身就是需要解释的。
• "环境不变"是不是太保守——它是主动付出的成本，不是偷懒。
• 长任务断在半路重试为什么更亏——首字之后额度已经消耗，重试是二次扣费，而且拼不回去。

再往上抽一层，这篇文章真正想说的是一句朴素的话：

在这个领域里，把约束讲清楚的人，比把承诺讲漂亮的人更值得信。

因为约束是可验证的——你可以自己去撞，看它说的是不是那么回事。而承诺往往在你验证不了的地方，等你验证得了的时候，通常已经付过钱了。

如果这篇东西能让你在下一次做选型时多问两句"额度是怎么算的""断流了它怎么处理""我要走的时候本机能不能干净还原"，它的目的就达到了。

本文只讨论公开可观测的机制与通用工程权衡，不含任何服务端规则细节，也不提供任何对抗性方案。文中涉及的额度窗口、鉴权路径等描述，均为面向用户的行为层归纳，不代表任何厂商的内部实现。