我第一次遇到这个问题时，注意力放在了“切换账号以后，原来的程序为什么还在运行”上。前台已经换成另一个账号，后面的任务却没有停，直觉上很容易把它理解成切换机制失效了。
但现场继续核对以后，我发现真正危险的地方并不在这里。程序继续运行，可能只是因为任务已经在原账号自己的页面或服务端继续执行，它不应该因为前台窗口换了就被强行中断。真正需要警惕的是，下一条任务发出去时，发送入口到底还带着谁的身份。
这次的背景很具体：系统最初按单账号设计，后来实际已经有至少2个账号，甚至可能继续增加。读取和接力的一部分逻辑已经可以枚举多个配置，但负责写入和投递的那条路径还残留着单账号假设。于是，表面是“切号后任务没停”，深层却是“任务可能被送到错误的账号和工作区”。
切换前台，不等于切换任务
先把一个容易误判的现象拆开。一个账号对应自己的页面上下文，任务一旦在这个上下文里启动，后续执行可能由页面内部或服务端继续推进。此时把前台窗口切到另一个账号，并不会自动找到旧任务、更不会替它取消任务。
我一开始也倾向于把“切换就应该中断”当成要求，后来发现这样处理反而会制造新的问题。用户只是想查看另一个账号，旧账号正在执行的工作却被无条件终止；如果这个任务本来可以安全完成，切换动作就被错误地扩大成了停止动作。
前台账号的变化，只能说明人正在看谁，不能单独证明后台任务应该停下或改投给谁。
这个区分很重要。切换动作至少包含2件不同的事：一件是改变当前可见的页面，另一件是决定下一条任务的目标身份。前者可以是界面行为，后者却是发送行为。把它们绑成一个隐含动作，才会让系统在用户没有明确表达时替用户猜测。
真正危险的是错误账号发送
当2个账号都打开了相同类型的页面，发送入口看到的可能不是一个目标，而是多个看起来都合格的页面。旧逻辑只要找到第一个匹配页面，就直接把它当成发送对象。页面能打开、地址也相似，检查似乎都通过了，可它究竟属于哪个账号，并没有被确认。
这就是这次现场核对中最需要重视的地方：当前活跃账号与旧代码里硬编码的发送身份不一致。如果继续发送，程序可能带着旧身份去提交任务；即使任务没有立刻报错，也可能写入另一个账号，或者落进不属于当前任务的工作区。错误不一定马上显形，回头追查时却会同时面对错账号、错上下文和错数据归属。
如果不处理这个问题，后果不只是“这条消息发错了”。一旦发送任务、恢复任务和续跑任务共用一套旧身份，第一次误投还可能被后续流程继续放大：恢复时找不到原账号的状态，续跑时又回到默认工作区，最后留下一个表面成功、实际归属错误的结果。
多账号自动化里，最危险的不是切换没有中断，而是发送前没有证明“我现在要操作的就是这个账号”。
这件事让我重新意识到，身份不是窗口上的装饰信息，而是任务上下文的一部分。只看前台窗口，等于把一个需要验证的事实，交给了界面当前碰巧显示了什么。
最容易误判的3个默认值
第一个误判，是把“当前前台窗口”当成“当前任务目标”。前台状态变化很快，后台任务却有自己的生命周期。窗口被切换、最小化，甚至暂时关闭，都不能单独说明任务归属发生了变化。
第二个误判，是把“第一个匹配页面”当成唯一页面。单账号时代，这个假设通常不会出问题，因为只有一个候选；进入多账号环境后，候选数量本身就变成了必须处理的状态。继续沿用先找到就返回的方式，本质上是在随机选择。
第三个误判，是以为只改一个切换按钮就完成了多账号改造。账号身份如果只在入口处出现一次，后面创建、发送、恢复、转发、续跑和回执仍然使用旧默认值，系统就只是把风险藏得更深。
错误捷径就是继续保留单账号默认值，或者在多个账号都在线时按前台窗口猜目标。它的短期体验很顺：少填一个参数，少做一次核对，任务看起来也能跑。但这种顺利建立在“猜对了”的前提上，而自动化最不应该依赖的就是临场猜测。
我选择在发送入口拒绝猜测
这次我判断，最小而有效的安全阀不是立刻重做一套复杂的账号管理框架，而是在发送前增加一个明确的身份门槛：先枚举候选账号，再核对目标页面的实际身份；如果发现多个候选而任务没有指定目标，就拒绝发送。
我选择这样做，是因为拒绝一次可重试的任务，代价通常低于把任务写入错误账号。系统可以告诉操作者存在多个候选，要求补充账号标识；它不需要替人决定，也不需要为了“自动化”而冒险猜一个。尤其在发送、调研或会改变数据归属的动作前，fail closed 比“尽量帮你完成”更可靠。
指定目标以后，还不能只相信传入的名字或配置。发送前应该再次从目标页面读取当前登录身份，用可核对的标识与任务要求比对；身份一致才允许继续，不一致就停止。这样做是为了防止页面刚被切换、配置刚发生变化，或者候选解析结果已经过期。
这里还有一个容易被忽略的并发问题。单账号时代的全局写入锁，到了多账号环境可能让账号A的任务无谓地挡住账号B。它未必造成错发，却会制造等待和超时。锁应该至少按账号或配置上下文隔离，让安全边界和执行资源边界保持一致。
把账号当作任务上下文传到底
真正的改造重点不是增加一个“切换账号”按钮，而是让账号身份从任务创建时就存在，并沿着完整链路传递。任务被创建时，要记录目标账号；发送时用这个目标解析页面、发送身份和工作区；恢复时继续使用原账号；转发和续跑时不能重新退回全局默认值；最后的回执也要带上归属，方便确认结果确实来自同一个上下文。
我会把这条链路理解成一条简单的约束：任务属于谁，后面的动作就只能在谁的上下文里寻找状态。账号可以用配置标识、用户标识或昵称表达，但表达方式可以变化，归属原则不能变化。
账号参数不是发送函数的一个可选装饰，而是创建、投递、恢复、续跑和回执都必须携带的任务事实。
这也解释了为什么不能只修发送入口。入口拒绝了错误候选，确实能挡住一部分误发；但如果恢复链路没有继续携带账号，下一次操作仍然可能落回旧工作区。安全阀负责阻止错误发生，参数透传负责让正确目标在后续步骤里不丢失，2者缺一不可。
一套可以复用的身份隔离流程
以后遇到类似的多账号桌面自动化，我会按下面的思路检查，而不是先去追逐某个界面现象。
首先，列出账号候选和每个候选对应的页面、工作区及连接状态，确认系统究竟看到了几个真实目标。其次，判断任务是否明确指定了账号；只有一个候选时可以采用受控默认值，多个候选而未指定时直接拒绝。再次，在真正发送前重新读取页面身份，验证它与任务上下文一致。
然后，检查身份参数是否贯穿任务的所有分支：创建、直接发送、恢复、转发、续跑和结果回执都要使用同一个账号事实。任何一个分支重新读取“当前账号”、使用旧常量，或者依赖前台窗口，都应该视为隔离不完整。
最后，做一次不会写回真实数据的跨账号驱动验证。验证重点不是发出一条真实消息，而是证明系统能识别候选、拒绝未指定的多候选任务，并且在指定账号时始终停留在目标上下文。这次验证保持未切号、未写回数据目录，正是为了先验证路由，再承担业务副作用。
这套流程的价值，不在于让所有动作都变慢，而在于把最昂贵的错误挡在副作用发生之前。一个流程成熟的标志，不是它能在单账号、顺风时跑通一次，而是多候选出现、页面状态变化、任务需要恢复时，它仍然不会替人猜身份。
下次我会怎么做
下次再看到“切号后原程序还在运行”，我会先区分任务生命周期和前台显示状态，不急着把持续运行判定为故障。接着我会直接检查发送入口是否能回答3个问题：当前有哪些候选账号，任务明确要操作谁，页面实际登录的是谁。
如果只有一个候选，我仍然会保留发送前核对；如果有多个候选而没有指定目标，就让任务停在入口处，等身份补齐后再继续。因为这不是增加麻烦，而是把本来隐藏在错误结果里的判断，提前变成一次可见的确认。
在代码和流程审查中，我也不会只搜索“切换”相关逻辑。我会沿着任务的全生命周期追踪账号参数：从创建到发送，从恢复到续跑，再到最后的回执。只要某一步重新依赖全局默认值，就说明身份隔离还没有闭合。
这件事让我更愿意把多账号支持看成一种工作习惯，而不是一个功能开关。**先绑定身份，再发任务；先证明目标，再允许副作用；不确定时拒绝猜测。**这3句话足够短，却能在下一次系统扩展时提醒我：自动化真正要节省的，不是核对身份的几秒，而是避免一次很难追回的错误归属。