1. 从"能连上"到"敢调用"：为什么下半场才是真正的硬仗
上半场我们把 WSS 通道打通了，Server 能通过 WebSocket Secure 把指令送到 Desktop 端，Desktop 也能把执行结果回传。很多人在这一步就以为大功告成，结果一上生产环境立刻被打脸：指令重复执行了三次、用户根本没点确认工具就跑了、网络一抖结果两边状态对不上、有人伪造了一条调用消息把本地文件删了。这些问题不是通道问题，是信任与一致性问题。
这篇是下篇的第二部分，专门啃四块硬骨头：Ticket 票据机制、人工确认环节、幂等设计、断线对账。这四个东西凑在一起，才构成一个"敢让 Server 调用 Desktop 本地工具"的完整闭环。缺任何一个，你的系统都只能停留在 Demo 阶段。
先说清楚适用场景。这套东西适合的是：Server 端（可能是云端服务、也可能是内网调度中心）需要触发 Desktop 端（用户电脑上的客户端）执行本地能力，比如调用本地某个命令行工具、操作本地文件、读取本机硬件信息、执行一段本地脚本。Desktop 端不是无脑执行器，它有自己的安全边界，用户坐在电脑前，得让他知道"有人要动我的机器"，并且有权拒绝。
读者画像我大致分三类：一是正在做类似 C/S 协同工具的开发者，二是做 RPA、远程运维、本地 Agent 这类产品的工程师，三是单纯想搞明白"分布式调用里幂等和对账到底怎么落地"的技术人。三类人都能从下面四块内容里拿到能直接抄的东西。
我先把结论摆前面：Ticket 解决"这次调用凭什么被允许"，人工确认解决"用户是否真的同意"，幂等解决"重复到达怎么办"，断线对账解决"两边状态不一致怎么收敛"。四者环环相扣，下面逐个拆。
2. Ticket 机制：给每一次调用发一张"一次性通行证"
2.1 为什么不能直接信任 Server 发来的指令
最朴素的做法是：Server 通过 WSS 发一条 JSON 过来，Desktop 解析后直接执行。听起来没问题，但这里有个致命假设——你默认了这条消息一定来自可信的 Server，且这条消息只应该被执行一次。这两个假设在真实网络里都不成立。
第一，WSS 虽然加密，但 Desktop 端怎么确认对面就是自己的 Server？如果攻击者拿到了 Desktop 的连接地址，或者中间有人能诱导 Desktop 连到伪造的服务端，那所有指令都可能是恶意的。第二，就算来源可信，一条消息在网络里可能被重放。攻击者抓包拿到一条"删除临时文件"的指令，原样再发一遍，Desktop 如果无脑执行，就出事了。
所以我们需要一个东西，它同时满足：来源可验证、时效有限、次数受限、内容绑定。这就是 Ticket。
2.2 Ticket 的字段设计与签发流程
Ticket 本质上是一个由 Server 签发、Desktop 校验的凭证。它不需要多复杂，但字段必须齐全。我实际用的结构大概是这样：
{ "ticket_id": "tk_20240521_8f3a9c", "issued_at": 1716280000123, "expire_at": 1716280060123, "nonce": "a1b2c3d4e5f6", "tool_name": "local_file_scan", "params_hash": "sha256:9f86d081884c7d65...", "caller": "server-scheduler-01", "signature": "base64(...)" }逐个说清楚每个字段为什么必须有：
- ticket_id：全局唯一，用于日志追踪和幂等去重，后面断线对账也靠它。
- issued_at / expire_at：时效窗口。我一般给 60 秒，够用又不至于被长期重放。窗口太长等于给攻击者留时间，太短又容易因为时钟偏差误杀。
- nonce：随机数，配合 ticket_id 一起防重放。即使两条 ticket 内容完全一样，nonce 也不同。
- tool_name：这次要调用哪个本地工具。Desktop 端应该有一张白名单，不在白名单里的直接拒。
- params_hash：参数的哈希。为什么要哈希而不是直接放参数？因为签名只需要覆盖"参数没被篡改"这个事实，哈希更短，且避免参数里的敏感信息进入签名原文。
- caller：谁发起的。多租户或者多调度器场景下，这个字段用于审计。
- signature：整个 ticket 的签名，Desktop 用预共享的公钥或对称密钥验证。
签发流程是：Server 在决定调用某个工具前，先组装上面这些字段，用私钥签名，然后把 ticket 和实际参数一起通过 WSS 发过去。注意，ticket 里只有 params_hash，实际参数在消息体里，Desktop 收到后要自己算一遍参数的哈希，跟 ticket 里的 params_hash 比对，一致才继续。
2.3 Desktop 端的校验顺序，顺序错了等于没校验
校验顺序非常关键，我见过有人先验签名再验时效，结果一个过期很久但签名正确的 ticket 被放行。正确顺序应该是：
- 验签名：签名不对，直接拒，连日志都只记一条告警，不返回细节。
- 验时效：当前时间是否在 issued_at 和 expire_at 之间。这里要留一点时钟偏差容忍，比如 ±5 秒。
- 验 nonce 是否用过：Desktop 本地维护一个已用 nonce 的集合（带过期清理），用过就拒。
- 验 tool_name 白名单：不在白名单，拒。
- 验 params_hash：自己算一遍参数哈希，跟 ticket 里的比对。
- 验 caller 权限：这个 caller 有没有权限调这个工具。
六步全过，才进入下一步——人工确认。任何一步失败，都要返回一个明确的错误码，但错误码不要暴露太多信息，比如签名失败统一返回AUTH_FAILED，不要告诉对方"你签名错了还是时效错了"，避免给攻击者提供探测信息。
提示：nonce 集合的清理策略要跟 expire_at 对齐。我一般保留 2 倍过期时间，比如 ticket 60 秒过期，nonce 记录保留 120 秒后清理。这样既防重放，又不会让集合无限膨胀。
2.4 密钥管理：别把私钥硬编码进客户端
这是踩过的最大的坑。早期图省事，把对称密钥直接写进 Desktop 客户端代码里，结果客户端一被反编译，密钥就泄露了，等于所有 ticket 都能伪造。
正确做法分两种。如果 Desktop 和 Server 是同一套体系内的，用非对称签名：Server 持私钥签发，Desktop 内置公钥验签。公钥泄露无所谓，私钥永远不出 Server。如果非要对称，那密钥必须通过安全渠道下发，且支持轮换——Desktop 启动时向 Server 请求当前密钥，密钥有版本号，ticket 里带上 key_version，Desktop 按版本选密钥验签。轮换时新旧密钥并存一段时间，平滑过渡。
密钥轮换的节奏我建议 30 天一次，配合灰度：先让 Server 用新密钥签发，Desktop 同时支持新旧，观察一周没问题再下掉旧密钥。
3. 人工确认：把"要不要执行"的决定权还给用户
3.1 什么情况下必须弹确认，什么情况下可以静默
不是所有调用都要弹窗，否则用户会被烦死。我的划分标准是按风险等级：
| 风险等级 | 典型操作 | 确认策略 |
|---|---|---|
| 低 | 读取本机基础信息、查询状态 | 静默执行，仅记录日志 |
| 中 | 写入指定目录、调用只读工具 | 首次确认，后续同工具可记住选择 |
| 高 | 删除文件、执行脚本、修改系统配置 | 每次必确认，且展示完整参数 |
| 极高 | 涉及敏感目录、提权操作 | 每次确认 + 二次验证（如输入确认码） |
这个分级不是拍脑袋，是根据"操作可逆性"和"影响范围"来的。可逆的、影响小的，静默；不可逆的、影响大的，必须让用户明确点头。
3.2 确认弹窗里到底该展示什么
我见过很多产品的确认弹窗就一句"是否允许执行操作？"，用户根本不知道自己在同意什么。这种确认等于没确认，出了事用户会说"我哪知道它要删我文件"。
好的确认弹窗应该包含：
- 谁在请求：caller 字段，让用户知道是哪个服务发起的。
- 要做什么：tool_name 加上人类可读的描述，比如"扫描 D 盘下的图片文件"。
- 具体参数：把参数展开给用户看，尤其是路径、文件名这类关键信息。
- 影响范围：会修改哪些文件、会不会联网、大概耗时多久。
- 有效期：这次确认是只对这一次有效，还是对这个工具的一段时间内有效。
展示参数时有个细节：路径要做规范化处理再展示，防止有人用../../这种相对路径骗过用户的肉眼判断。展示的是规范化后的绝对路径，实际执行也用规范化后的路径，两边一致。
3.3 确认结果的回传与超时处理
用户点了"同意"或"拒绝"，Desktop 要把结果回传给 Server。这里有个容易被忽略的点：用户可能一直不点。所以确认必须有超时，我一般设 30 秒到 2 分钟，看操作紧急程度。超时后按"拒绝"处理，回传一个CONFIRM_TIMEOUT。
回传的消息里要带上 ticket_id，这样 Server 能把确认结果和之前的调用请求对应起来。如果用户同意，Desktop 才真正执行工具，执行完再把结果回传。整个链路是：
Server 发 ticket+params -> Desktop 校验 ticket -> Desktop 弹确认 -> 用户同意 -> Desktop 执行工具 -> Desktop 回传执行结果注意，确认和执行是两个独立阶段，确认通过不代表执行一定成功，执行可能因为权限、文件不存在等原因失败，这些都要如实回传。
3.4 记住选择：便利性与安全性的平衡
每次都弹窗用户体验很差，所以要有"记住选择"机制。但记住的粒度要设计好：
- 按caller + tool_name记住，而不是只按 tool_name。同一个工具，不同 caller 发起的，信任度可能不同。
- 记住的选择要有有效期，比如 24 小时，过期重新确认。
- 高风险操作不允许记住，每次必弹。
- 用户要能随时在设置里查看和撤销已记住的选择。
我实际用下来，这个粒度比较合理：中风险工具记住后，日常使用几乎无感；高风险工具该弹还是弹，用户也不觉得烦，因为确实少。
4. 幂等：让"重复到达"变成"只执行一次"
4.1 重复是怎么产生的，比你想的要多
很多人以为幂等只是防"用户手抖点两次"，实际上重复来源多得多：
- 网络重传：WSS 底层是 TCP，但应用层如果做了超时重发，就可能重复。
- Server 重试：Server 发了一条指令，等了一会儿没收到回执，以为丢了，又发一遍。
- 断线重连：Desktop 断线重连后，Server 可能把未确认的指令重新推送。
- 用户重复确认：确认弹窗因为 UI 卡顿，用户点了两次同意。
这些场景下，如果 Desktop 无脑执行，就会出现"文件被删两次""脚本跑两遍"这种事故。所以幂等不是可选项，是必选项。
4.2 用 ticket_id 做幂等键，但要注意执行状态
最直接的幂等方案：Desktop 维护一张"已处理 ticket_id"表，收到指令先查表，处理过就直接返回上次的结果，不重复执行。
但这里有个坑："处理过"不等于"执行成功"。如果上次执行到一半 Desktop 崩了，ticket_id 已经记了，但工具没跑完，这时候直接返回"已处理"就是错的。所以状态要分细：
| 状态 | 含义 | 收到重复请求时的处理 |
|---|---|---|
| RECEIVED | 已收到，未开始执行 | 忽略重复，继续原流程 |
| EXECUTING | 执行中 | 返回"执行中"，让 Server 等待 |
| SUCCESS | 执行成功 | 返回缓存的成功结果 |
| FAILED | 执行失败 | 返回缓存的失败结果 |
| UNKNOWN | 状态不明（如崩溃恢复） | 触发对账流程 |
关键是EXECUTING 和 UNKNOWN 这两个状态。EXECUTING 时收到重复请求，不能重新执行，要告诉 Server"我正在跑，你等着"。UNKNOWN 是最麻烦的，通常发生在 Desktop 崩溃重启后，需要靠断线对账来收敛。
4.3 幂等表的落地细节
幂等表我建议用本地轻量存储，SQLite 就够。表结构大概：
CREATE TABLE idempotency ( ticket_id TEXT PRIMARY KEY, status TEXT NOT NULL, result TEXT, created_at INTEGER NOT NULL, updated_at INTEGER NOT NULL );几个实操要点：
- ticket_id 做主键，天然去重。
- result 字段存序列化后的执行结果，重复请求直接返回，不用重跑。
- created_at 用于清理，比如保留 7 天，过期删除，避免表无限增长。
- 写入要事务化：先插入 RECEIVED 状态，再执行，执行完更新状态。这样即使中途崩溃，重启后也能看到"有个 ticket 卡在 RECEIVED"，触发对账。
注意：幂等表和执行本身不在一个事务里（执行是外部操作，没法回滚），所以只能保证"不重复执行"，不能保证"执行和状态记录原子"。这就是为什么需要 UNKNOWN 状态和对账机制兜底。
4.4 执行结果的缓存与返回
重复请求返回缓存结果时，要注意结果的时效性。比如"查询磁盘剩余空间"这种，缓存 5 分钟前的数据可能已经不准了。所以缓存策略要分工具：
- 幂等且结果稳定的（如"读取某个固定文件内容"）：可以长期缓存。
- 幂等但结果会变的（如"查询系统状态"）：缓存短时间，或者干脆标记为"结果可能过期"。
- 非幂等的（如"追加写日志"）：这类操作本身就不该设计成可重试，Server 端要避免重试。
这里的原则是：幂等设计要跟业务语义对齐，不能为了幂等而幂等。一个"给文件追加一行"的操作，你硬要它幂等，就得引入去重逻辑，反而复杂。更好的做法是把它设计成"写入指定内容到指定位置"，用内容哈希做幂等键。
5. 断线对账：两边状态不一致时怎么收敛
5.1 断线期间到底发生了什么
WSS 断线是常态，不是异常。断线期间可能发生：
- Server 发了指令，Desktop 没收到。
- Desktop 执行完了，结果没回传成功。
- Desktop 正在执行，连接断了，执行完发现回传不出去。
- 双方都以为对方收到了，其实都没有。
这些情况下，两边的状态就分叉了。Server 以为指令没发出去，其实 Desktop 执行了；或者 Server 以为执行成功了，其实 Desktop 根本没收到。断线对账就是要把这些分叉收敛掉。
5.2 对账的触发时机
对账不是随时都在跑，那样太浪费。触发时机我一般设三个：
- 重连成功后立即触发一次：这是最主要的时机，把断线期间的不确定性一次性解决。
- 定时触发：比如每 5 分钟一次，兜底那些"连接没断但消息丢了"的极端情况。
- 手动触发：提供一个接口，运维发现异常时可以主动发起。
重连后的对账最关键，因为断线期间积累的不一致最多。
5.3 对账协议：双方交换什么
对账的本质是双方交换各自记录的 ticket 状态，找出差异。协议设计要简单，我用的方案是：
Desktop 重连后，主动向 Server 发送自己最近 N 分钟（比如 10 分钟）内处理过的 ticket 列表，每条包含 ticket_id 和最终状态。Server 收到后，跟自己记录的该时间段内的 ticket 做比对：
- Server 有、Desktop 没有：说明指令可能没送达，Server 决定是否重发（重发时 ticket_id 不变，靠幂等保证不重复执行）。
- Desktop 有、Server 没有：说明 Desktop 执行了但 Server 没记录，Server 补记录，以 Desktop 的状态为准。
- 两边都有但状态不一致：以 Desktop 的最终状态为准（因为执行发生在 Desktop），Server 更新自己的记录。
- 两边都是 EXECUTING/UNKNOWN：需要进一步查询，Desktop 检查本地是否真的还在执行，给出确定状态。
这个协议的关键是以 Desktop 的执行状态为权威，因为工具是在 Desktop 上跑的，它最清楚实际发生了什么。
5.4 对账中的冲突处理
对账时最怕的是"两边都觉得自己对"。比如 Server 记录 SUCCESS，Desktop 记录 FAILED。这种情况按"Desktop 权威"原则处理，但 Server 要记录一条冲突日志，方便排查为什么会出现这种分歧。
还有一种情况：Desktop 记录了一个 Server 完全不知道的 ticket_id。这通常意味着 Server 的存储丢了数据，或者 Desktop 收到了伪造指令。前者补记录，后者要告警——因为能通过 ticket 校验的伪造指令，说明密钥可能泄露了。
对账的频率和窗口大小要权衡。窗口太小，断线时间长了对不上；窗口太大，数据量大传输慢。我一般用 10 分钟窗口，配合分页传输，每页 100 条。如果断线超过 10 分钟，就扩大窗口或者做全量对账。
5.5 对账后的状态收敛
对账完成后，两边状态要收敛到一致。收敛动作包括：
- Server 更新自己的 ticket 状态表。
- Desktop 清理已确认完成的 ticket 的幂等记录（或者标记为已对账）。
- 对于需要重发的指令，Server 重新走一遍发送流程，但 ticket_id 复用，Desktop 靠幂等表识别出"这个我处理过了"，直接返回缓存结果。
这里有个细节：重发时 ticket 可能已经过期。因为 ticket 有 60 秒时效，断线 5 分钟后重发，ticket 早过期了。所以对账重发不能直接用原 ticket，要么 Server 重新签发一张新 ticket（但这样幂等键就变了），要么对账重发走一条特殊通道，跳过时效校验但保留幂等校验。
我选的是后者：对账重发时，Desktop 识别出这是"对账重发"标记，跳过时效校验，但仍然查幂等表。这样既解决了过期问题，又保证了不重复执行。
6. 四块拼图怎么咬合：一条完整链路的走查
把 Ticket、人工确认、幂等、对账串起来看，一条完整的调用链路是这样的：
- Server 决定调用工具，签发 ticket，通过 WSS 发送 ticket + params。
- Desktop 收到，按六步校验 ticket。校验失败，回错误码，结束。
- 校验通过，查幂等表。如果 ticket_id 已存在且状态是 SUCCESS/FAILED，直接返回缓存结果，结束。
- 如果不存在，写入 RECEIVED 状态，进入人工确认。
- 弹确认窗，用户同意则继续，拒绝或超时则更新状态为 FAILED，回传，结束。
- 更新状态为 EXECUTING，执行工具。
- 执行完成，更新状态为 SUCCESS 或 FAILED，缓存结果，回传 Server。
- 如果执行过程中断线，Desktop 继续执行完，结果暂存本地，等重连后通过对账回传。
- 重连后，Desktop 发起对账，双方交换状态，收敛差异。
这条链路里，每一步都有明确的失败处理，不会出现"卡住不知道怎么办"的情况。这是生产级系统和 Demo 的最大区别。
再说几个实操中容易忽略的点：
- 日志要带 ticket_id：从 Server 到 Desktop，所有日志都带上 ticket_id，排查问题时能一键串起来。
- 监控要对账差异率：对账时发现的不一致条数要打点监控，差异率突然升高说明有问题。
- 压测要模拟断线：正常压测跑不出问题，要专门模拟断线重连、消息丢失、重复发送这些场景。
- 灰度发布：Ticket 校验逻辑、幂等逻辑变更时，先灰度一部分客户端，观察对账差异率没升高再全量。
7. 几个我踩过的坑和对应的解法
坑一：nonce 集合内存泄漏。早期 nonce 只加不删，跑了一周内存爆了。解法是按 expire_at 定期清理，用带过期时间的结构（比如按时间分桶的 map）。
坑二：确认弹窗阻塞了消息处理线程。弹窗是 UI 操作，如果同步等待用户点击，会把 WSS 的消息处理线程卡住，导致其他消息堆积。解法是把确认做成异步：收到指令后立即返回"待确认"，确认结果通过另一个消息回传，消息处理线程不阻塞。
坑三：幂等表和执行结果不一致。有次执行成功了，但更新幂等表状态时进程崩了，重启后状态还是 EXECUTING，对账时被判为 UNKNOWN。解法是执行完成后先写结果到临时文件，再更新状态，重启后如果发现 EXECUTING 但临时文件有结果，就恢复成 SUCCESS。
坑四：对账时全量拉取导致超时。一开始对账直接拉全部历史，数据量大了直接超时。解法是分页 + 时间窗口，只对最近 10 分钟，且每页 100 条。
坑五：ticket 时效和时钟偏差。有台机器时钟慢了 30 秒，导致所有 ticket 都被判过期。解法是 Desktop 启动时跟 Server 对一次时，算出偏差值，校验时效时把这个偏差算进去。
这些坑的共同点是：都不是逻辑错误，而是工程细节没考虑到。分布式系统的难点从来不是算法，而是这些边边角角。
8. 关于这套机制的一点个人体会
我做完这套东西最大的感受是：安全调用本地工具，核心不是加密有多强，而是"每一步都可追溯、可拒绝、可恢复"。Ticket 让每次调用有据可查，人工确认让用户有否决权，幂等让重复不造成伤害，对账让不一致能收敛。四者缺一，系统就有窟窿。
如果让我给正在做类似系统的朋友一句建议：先把幂等和对账做扎实，再考虑 Ticket 和确认的复杂度。因为幂等和对账是数据一致性的底线，Ticket 和确认是安全性的增强。底线不牢，增强再多也是空中楼阁。实际落地时，我见过太多团队把精力花在花哨的签名算法上，结果连"重复执行"都没解决，一出事就是数据损坏，那才是真的麻烦。
另外，这套机制不是一次设计就能完美的，一定要留好监控和日志，上线后根据对账差异率、确认拒绝率、幂等命中率这些指标持续调优。我自己的系统跑了半年，对账差异率从最初的千分之三降到了万分之零点五，靠的就是不断看数据、不断补边界。
