桌面自动化同时包含界面响应、网络请求、视觉识别和鼠标输入。最容易出现的问题不是线程数量太少，而是多个线程都认为自己可以控制鼠标或直接更新 Tkinter 控件。金手指当前架构把职责拆开：Tk 主线程负责界面与浮窗渲染，网络查询可以使用独立后台线程，真正控制游戏窗口和鼠标的自动化流程同一时刻只保留一个工作线程。
界面线程不承担长流程
Tkinter 的事件循环需要持续处理按钮、窗口重绘和 after 回调。如果副本、捉鬼或逐窗口任务直接在主线程运行，任何等待画面出现的循环都会让界面像卡死一样停止刷新。因此开始任务时，界面先完成任务组合校验、授权状态检查和运行状态锁定，再创建后台工作线程执行具体流程。
工作线程并不意味着所有事情都可以在后台直接操作。Tk 控件更新仍应回到主线程。当前日志浮窗在收到新内容时先缓存最近几行；若调用发生在主线程就直接渲染，否则通过 root.after 把渲染安排回事件循环。消息列表和未读数等网络请求也采用后台获取、主线程回调更新的模式。
鼠标输入为什么需要唯一所有者
多线程同时做模板匹配本身未必产生冲突，但一旦两个流程都能移动和点击鼠标，A 线程刚把窗口置前，B 线程就可能切到另一个窗口；A 线程随后使用的坐标虽然计算正确，却落在错误客户区。类似问题会表现为偶发点击偏移、重复打开任务栏或剧情步骤跳转，很难只靠阈值解释。
当前实现通过 task_thread 保存自动化线程所有权。每次开始只创建一个 daemon 工作线程，线程退出时才清空引用。若用户停止后旧线程仍存活，新的开始请求会被阻止。这个约束比在每一个点击点单独加锁更容易验证，因为从任务入口就保证只有一条自动化调用链拥有鼠标。
一轮一个 Event 避免旧线程被重新放行
停止信号也属于线程边界。若所有运行复用同一个 Event，停止时 set，下一轮开始时 clear，而旧线程恰好尚未退出，旧线程可能看到信号被清空后继续执行，与新线程形成竞争。当前做法是在每轮开始时创建新的 Event；旧线程永远持有已经被设置的旧事件，新线程持有新的事件，两者不会因为清空共享状态而混在一起。
执行器的等待函数定期检查自己的 stop_event。用户停止后，深层流程逐步返回，工作线程进入 finally，再释放 task_thread。界面状态可以先恢复，但再次启动仍以线程是否真正退出为准，这也是“上一轮任务尚未完全退出”提示存在的原因。
日志既是用户反馈也是并发证据
自动化日志不只描述业务步骤，还应能回答当前哪个线程拥有流程、窗口切换到哪里、停止信号是否进入。金手指把执行器的标准输出重定向到界面日志，并在任务运行时显示右下角最近日志浮窗。工作线程产生文本，主线程负责控件渲染，可以避免后台线程直接操作 Tk 组件导致不稳定。
排查并发问题时，应保存从任务开始、窗口激活、关键点击到停止或完成的连续日志。只有最终一行“识别失败”时，看不出是否存在另一个流程提前切窗。若出现两个不同任务步骤交错打印、停止后又继续进入新阶段，才需要检查线程所有权和事件传递，而不是先修改图像模板。
网络线程与自动化线程不应混用
授权刷新、消息读取和停止状态同步可能受网络延迟影响。当前界面将这些请求放到独立后台线程，并通过主线程回调更新控件；鼠标自动化线程专注于窗口、截图和输入。这样网络短暂变慢不会直接占用 Tk 主循环，也不会成为第二个鼠标控制者。
职责边界可以概括为：主线程管界面，网络线程管请求，唯一自动化线程管鼠标，停止事件贯穿执行器。开发新的任务模块时，应接入现有 stop_event 和日志通道，不自行再起一个可以点击桌面的线程。用户侧如需了解停止后的判断方法，可阅读停止运行与再次启动说明；窗口绑定细节见队长窗口选择教程。