牌局恢复与发布保护
区分断线重连、崩溃恢复与计划交接，了解重启后保留哪些状态，以及进行中的纯真人桌为什么仍会阻止游戏运行时发布。
能恢复房间和筹码，不等于能把进行中的一手牌原样续上。BluffKing 把断线重连、崩溃恢复和计划发布交接分开处理；目前只要有进行中的纯真人桌，后端和 H5 发布就会被拒绝。
断线后恢复什么
如果只是浏览器断网，而原服务进程仍在，牌局状态还由原来的 session actor 持有。玩家重新通过身份与座位校验后，收到当前快照和按权限交付的底牌，接回同一个牌局。
重连不会把思考时间重新发一遍。收到的是当前行动期限；离线期间发生的超时和其他玩家行动，也不会因为刷新页面而撤销。
重启后恢复什么
服务进程消失后，不能再依赖原来的内存。普通崩溃恢复读取数据库里的房间配置、原到期时间，以及最后已提交的恢复检查点。以德州为例：
| 可以恢复的持久状态 | 普通检查点不承诺恢复的内容 |
|---|---|
| 座位归属、筹码、累计买入、待生效补码、座位状态 | 半手牌的底牌、公共牌、当前底池与完整引擎状态 |
| 已完成手数、最后完成手牌、庄位及相关盲注进度 | 那一手的发牌种子、轮到谁行动、精确的行动倒计时 |
这个检查点是不含牌面的恢复基线：买入会更新它，当前手的下注不会逐次改写它。崩溃会放弃未完成手牌，按持久边界恢复，而不是猜出一张“补牌”接着打。已完成手牌另有记录供回放；有回放数据，也不等于能恢复任意一刻的运行状态。
还要区分“写入已排队”和“数据库事务已提交”。必要写入按桌有序执行，完成手牌、相关记录与恢复检查点在事务中保存；但普通运行仍有入队后尚未提交的窗口。突然中断后，只能依赖实际提交的部分，不能把玩家刚看到的每个结果都当作已经写盘。
发布已经支持哪些交接
当前已有受控的计划交接，并非每次发布都只能直接杀掉旧进程。对于受支持的德州桌，旧实例先让当前手自然结束，在两手之间保存额外连续状态、刷新检查点并暂停；发布控制确认必要写入排空、版本凭据一致后，候选实例核验归档、恢复牌桌，再开放请求。
这条路径还可携带普通崩溃检查点之外的时间银行使用量、聊天和上一手结果等状态。但它依赖双方遵守交接协议、处于支持的牌桌状态，并完成整条核验链。高级加密发牌、鱿鱼等不支持的德州状态会拒绝交接；任意进程或主机崩溃也不属于这项保证。直接热修复的检查点接管，同样不能替代计划交接的完整证明。
为什么纯真人桌仍不能发布
让新实例先就绪，解决的是服务可用性；保证玩家的一手牌、账目、行动顺序和计时连续，解决的是对局完整性。HTTP 能回答请求、客户端能重新连上，都不足以证明后者。
这不是原理上永远做不到。已有交接解决了一部分问题，但不代表任意模式、任意半手状态和任意失败时刻都能无损迁移。当前发布规则因此仍选择不主动打断进行中的纯真人桌，而不是让玩家替发布验证这些边界。
要放开这项限制，需要先明确支持的模式和版本，并证明安全边界等待、写入排空、唯一实例接管、私牌保密、计时衔接及失败恢复都成立。已有的交接机制可以作为基础；仅仅删掉人数守卫不会补齐这些保证。
哪些房间会阻止发布
权威指标是 human_only_tables，定义为已经开始、有人类入座、没有机器人的桌数。它不是在线人数，也不是全部房间数：等待房和含机器人桌不计入这个指标；不计入也不等于它们完全没有发布影响。
德州桌的“已经开始”会在开过手牌后保留，不会在两手之间自动变成未开局等待房。因此，“这一手刚打完”不能替代指标归零，更不能作为绕过守卫的理由。
只要这个数大于零，游戏运行时发布就停止；读不到可信结果，也不能假定为零。检查会在生产变更和切换前重复执行，热修复与仅更新 H5 的发布也受保护。
营销官网是单独的静态发布路径，不替换后端或 H5，因此不受这项人数限制。代理重载仍可能让连接重连一次，但它接回的是同一个未被替换、仍持有牌局状态的后端。
源码入口：server/src/runtime_checkpoint.rs、server/src/session_persistence.rs、server/src/session/actor/boundary.rs、server/src/release_handoff.rs 与 server/src/handlers/admin_tables.rs。本文说明当前恢复与发布边界，不承诺每种故障都能无损续局。