有一次，我用远程调试方式启动桌面应用。电脑端看起来一切正常：窗口能被驱动，自动化入口也能访问，任务照样可以派发。可我拿起手机一看，应用却像没有上线一样。电脑上明明“活着”，手机端却显示“离线”，这两个事实放在一起，特别容易把人带进一个错误方向：既然远程调试端口能打开，那应用就应该已经在线。
后来我才发现，这其实是两个不同的状态。一个状态说的是“有没有调试入口”，另一个状态说的是“应用有没有维持自己的在线链路”。它们可能同时成立，也可能只成立一个。远程调试入口可用，不等于桌面应用已经在线。
这次排查给我的价值，不只是修好一次启动问题，而是把“能被驱动”和“对外在线”拆成了两条需要分别验证的链路。
电脑能驱动，手机却看不到
当时使用的是基于 CDP 的启动方式。它的目标很明确：让桌面应用打开一个调试入口，后续由自动化程序在后台连接，不抢前台焦点。应用窗口可以操作，调试接口也能返回版本信息。从桌面端的感受看，似乎没有任何故障。
问题出在手机端。手机上的在线状态没有跟着恢复，像是桌面端没有真正完成登录、连接或者心跳。用户真正需要的并不是“电脑上有一个能连的端口”，而是手机端也能看到它在线，并且后续仍然可以远程使用。
如果不处理这个差异，后面会出现一个很隐蔽的后果：自动化任务以为应用已经准备好了，实际上移动端的状态没有建立。任务可能继续执行一小段时间，等到需要依赖登录态或长连接时才失败。到那时，日志里留下的往往只是“连接成功”或“端口存在”，很难一眼看出真正的问题在在线状态。
所以我先把现状分开记录：调试入口能不能访问，应用内是否仍处于登录状态，手机端是否显示在线，后台连接是否持续。只有这样，后面才不会把一个局部成功误认为整体成功。
在线不是一个开关
桌面应用的在线状态，通常不是启动后自动亮起的一个开关。它至少可能依赖几层条件：登录态是否来自原来的用户数据目录，设备标识是否保持一致，长连接是否已经建立，心跳是否持续发送，以及渲染进程在后台运行时有没有被节流。
这也解释了为什么“同一个应用”用不同方式启动，表现可能不一样。正常启动时，它会沿着原来的用户数据、登录和窗口生命周期走完一套流程；CDP 启动时，如果启动器换了用户数据位置，或者让窗口和渲染进程进入了不一样的后台状态，调试入口仍然可能打开，但在线链路已经变了。
我一开始也怀疑过启动参数，尤其是用户数据目录、后台节流和多实例。这个怀疑是合理的，因为新目录可能没有登录态，后台节流也可能让心跳变得不稳定。但仅仅列出可能性还不够，必须用正常启动和 CDP 启动做对照，观察哪一个条件真的发生了变化。
这里最容易误判的是，把“能访问调试端口”当成“应用内部所有服务都已经准备好”。端口只回答了一个很窄的问题：某个调试服务是否在监听。它没有回答登录态是否正确，也没有回答业务长连接是否活着。
先做双重探活，再看进程
我选择把探活拆成两层，是因为这两层分别对应用户真正关心的两个结果。第一层用调试接口的版本地址检查入口是否可用；第二层看应用自己的在线状态或连接状态。前者适合程序快速判断，后者才接近用户在手机上看到的结果。
调试入口的探活应该直接访问 /json/version，确认返回的确实是目标应用，而不是只用进程查询结果猜测。进程查询可以作为兜底，但不能作为唯一依据。进程列表可能因为命令行过滤、启动方式变化或主进程名称不同而给出误导性的结果；调试入口已经可用时，再因为进程查询没有命中而重复启动，反而会制造新的问题。
可靠的启动判断，应该同时证明“调试车道可用”和“应用在线链路仍然成立”。
这两层探活也让故障边界更清楚：如果调试接口不可用，但应用在线，可以先判断调试车道是否断了；如果调试接口可用，但手机仍显示离线，就要回到登录态、设备标识、长连接和后台活跃度去查。不要把所有问题都归结为“应用没启动”。
对照实验尤其重要。同一个应用，先用正常方式启动，再用 CDP 方式启动，分别记录用户数据位置、登录状态、调试入口和在线表现。如果不能直接读取手机状态，就使用应用内状态或连接日志替代，并明确这个替代的局限。验证不是为了把表格填满，而是为了知道差异究竟从哪一步开始。
真正的根因藏在守护判断里
这次最关键的线索，最后没有落在“CDP 会不会让应用离线”上，而是落在启动守护的进程匹配条件上。守护逻辑原本要做的事情很简单：应用已经在运行，就不要重复拉起；只有调试车道断开或应用确实退出时，才重新启动。
但脚本寻找的是应用包路径对应的主进程名，实际运行的 Electron 应用主进程却叫另一个名字。于是，应用明明已经在运行，守护逻辑却始终认为没有找到它。每次检查都像第一次启动一样，继续走原始启动路径。
这解释了一个看似矛盾的现象：偶尔启动后能被驱动，在线状态却不稳定；有时应用其实已经存在，启动器仍然尝试再拉起一份。重复启动会让用户数据、设备身份、窗口生命周期和长连接之间出现竞争。表面上看是“CDP 启动后离线”，实际上是“启动守护没有识别真实的运行实例”。
我没有直接继续堆启动参数，是因为那只能改变启动时的行为，不能修复守护在运行后的错误判断。当一个系统反复把“已运行”判断成“未运行”时，优先修正状态识别，而不是反复增加启动动作。
修复思路因此收敛成两步：先用调试接口判断车道是否可用，再用真实的主进程路径做兜底；国内版和国际版各自绑定自己的调试端口，不能只修其中一条。这样，启动器在应用已经运行时应该直接复用，只有车道断开、进程退出或状态确实失效时才重启。
在线保活需要保守的边界
“默认在线”并不意味着让应用永远盲目运行，也不意味着不停地重启直到手机显示上线。它应该是一种有边界的保活：保留原来的登录态和设备身份，避免后台节流影响必要的连接，启动后确认调试入口可用，同时用应用内状态观察在线链路。
如果只加禁止后台节流的参数，却没有确认用户数据目录，应用可能仍然是一个没有登录的“在线进程”。如果只复用用户数据目录，却不处理重复启动，多个实例又可能争用同一份状态。每个措施都只解决一部分问题，必须放回完整链路里判断。
这里的决策原则是，我选择“探活优先、进程兜底、断线才重启”，是因为它对已有状态最保守。已经在线的应用不应该被新的启动动作打断；真正失效时，系统又要有明确的恢复入口。启动器的职责不是证明自己做过一次启动，而是让后续任务拿到一个稳定、可复用的运行状态。
这件事也让我重新意识到，保活不是把进程留在列表里，而是保留用户真正依赖的关系：登录关系、设备关系、连接关系和调试关系。只要其中一条被重置，桌面上看似正常，手机端就可能先告诉你问题已经发生了。
一套可以复用的排查流程
以后遇到“远程入口正常，但应用显示离线”的问题，我会按固定顺序处理。先记录正常启动和 CDP 启动的差异，包括用户数据、登录态、调试接口、在线状态和后台活跃度；再用调试接口做直接探活，不把进程查询当成结论；接着检查守护脚本实际匹配的进程路径，确认它识别的是运行中的真实主进程。
然后做两类验证。第一类是已运行验证：应用已经启动时，重复调用启动器，不应再拉起新实例。第二类是断线恢复验证：主动让调试车道失效，守护才应该重新启动，并在恢复后再次通过调试入口和应用在线状态检查。两类验证缺一不可，否则只能证明“能启动”，不能证明“不会重复启动”或“能从故障恢复”。
如果过程里发现必须扫码登录，就把它当作需要用户参与的边界，不用脚本绕过。登录凭据、设备身份和用户数据都属于不能随意替换的状态。自动化真正应该接管的是判断和恢复，不是未经确认地重建身份。
这个方法也适用于其他桌面自动化应用。只要系统同时存在“远程控制入口”和“业务在线状态”，就应该把两者分开探活，再把启动、复用、断线恢复放进同一套状态机里理解。它比单纯记住一组启动参数更可靠，因为参数会变，判断链可以继续使用。
下次我会怎么做
下次再接到类似任务，我会先问清楚用户要的“在线”到底是哪一种在线：端口可连接、桌面应用可操作，还是手机端能看到业务在线。然后记录当前状态，再做正常启动与 CDP 启动的最小对照，不先假设根因一定是参数。
启动层的判断顺序会固定为：先探活调试接口，再确认应用内在线状态，最后才用真实主进程路径兜底。已运行就复用，车道断开才重启；每次恢复都要验证不会重复拉起。这样做的原因很朴素：一个流程成熟的标志，不是它能跑通一次，而是它能在下一次少依赖临场记忆。
**真正值得留下的不是“加了哪个参数”，而是下一次知道该先验证哪条链路。**这次看起来只是桌面端和手机端显示不一致，最后却让我重新看见了自动化系统里的一个基本事实：能被看见、能被连接、能持续在线，从来不是同一件事。