上周我在咖啡店连一台测试服务器跑构建，日志刚滚到一半，电脑从 Wi-Fi 切到手机热点，SSH 窗口停在最后一行。网络恢复后，窗口看起来像还在原来的位置，我顺手点了重连，结果发现构建早就退出了。那一刻才意识到，“看见一个重新连接的按钮”和“远端任务还活着”是两件事。
我用 Xterminal 重新走了一遍这类场景：先故意让连接断开，再观察自动重连、目录恢复和会话类型各自能做什么。这个过程也让我重新比较了系统终端、Xshell、FinalShell 和 Termius。对偶尔执行一条命令的人，最简单的终端依旧够用；对需要在网络不稳定时回来继续看现场的人，SSH 客户端的价值在于把线索留住，但它不能替服务器保存一个普通进程。
断线时，最先丢掉的通常不是连接
一条 SSH 连接里同时有几层状态：本地窗口知道连到了哪个条目，远端 Shell 知道当前目录，正在运行的命令属于一个进程，日志记录又可能是另一条本地写入链路。网络抖一下，最先消失的往往是这条通道；通道回来后，其他状态不一定跟着回来。
很多人排查断线只看“能不能重新登录”。这个判断太粗了。重新登录成功，只能证明认证和网络入口恢复；它没有证明原来的编译、压缩或日志跟随还在运行。普通 Shell 会随着 SSH 断开结束，除非任务本来就在服务器端的持久会话或任务管理器里。
我现在会把断线后的问题拆成三个小问题：客户端能否重新建立 SSH 连接，能否回到上次目录，远端任务是否仍有可观察的进程。这样看，自动重连只负责第一层，工作目录恢复解决第二层，tmux 或其他服务器端工具才可能覆盖第三层。
我在 Xterminal 里先开自动重连，但不把它当保险
Xterminal 的 SSH 设置里可以开启终端自动重连。网络短暂抖动时，它会尝试重新建立连接，省下手动关窗、找条目、再次登录的几步。我会同时打开“断线重连后恢复工作目录”，这样回到会话后，客户端会尝试用 cd 返回断开前的位置。
这两个选项对“我正在看哪个目录里的日志”很有帮助。比如我在 /srv/demo/logs 里追一段输出，重连后不用重新翻目录，能更快做 pwd 和 hostname 的回读。不过目录恢复有条件：路径必须仍然存在，当前用户也要有权限；Shell 初始化失败时，客户端会退回到可访问目录。
我不会把恢复后的光标位置当成证据。重连完成后，我固定先输入：
hostname
pwd
printf 'exit=%s\n' "$?"
这三步很朴素，却能确认主机、目录和上一条命令的退出状态。Xterminal 帮我更快回到窗口，不能替我确认“这还是刚才那台机器”，也不能判断构建是否已经写坏了产物。
普通 Shell 和 tmux，决定任务能不能继续
我做过一次对照。第一种是在普通 SSH 会话里运行 sleep 120 && echo done，然后断开网络。连接恢复后，新的 Shell 里看不到原来的进程，命令也不会凭空补跑。第二种是在服务器上先进入 tmux，再运行同一个命令；客户端断开时，tmux 会把 Shell 留在服务器端，回来后重新附着，才能看到任务是否完成。
Xterminal 的 SSH 文档把这两个会话类型分开：普通会话跟随 SSH 生命周期，持久会话借助服务器上的 tmux 保留后台会话。开启持久会话前，目标服务器要已经安装并允许当前用户执行 tmux，客户端不会替你安装。关闭持久会话标签时，界面可以提示后台任务仍在运行，这个提示很有用，但它仍然只是提醒。
更容易被忽略的一点是，持久会话只保存在当前设备的连接上下文中。它不是跨设备同步。你在办公室电脑上开的 tmux，回家用另一台电脑仍需要重新连接服务器并附着到同一个会话；客户端工作区不会把远端进程复制到新设备。
因此我的选择很简单：短命令、只读检查和可重复操作用普通会话；预计会跑很久、网络可能变化、结果不能因为窗口关闭而丢失的任务，先把任务放进 tmux。客户端和服务器端各自负责一半，缺一边都不稳。
我用一个可复现动作检查“恢复”到底恢复了什么
为了避免被界面状态骗到，我会按下面的顺序复现一次：
- 在测试服务器建立连接，记录
hostname、pwd，再创建一个临时文件或启动一条可观察的长命令。 - 让本机切换网络，等待窗口进入断开状态，观察 Xterminal 是否自动重连、目录是否回到原处。
- 重连后重新执行
hostname、pwd和ps，最后回到tmux或日志文件核对远端任务。
这个动作用来给每一层状态找证据，不是为了制造故障。客户端状态栏显示“已连接”，只能证明通道回来；ps 或 tmux ls 才能说明任务还有没有。若命令已经退出，我会查看输出文件的最后修改时间和退出码，不会因为窗口恢复到原标签就判定成功。
Xterminal 的工作区能把终端、文件面板和服务器状态放在相邻区域。看日志时，我可以在重连后直接打开同一个远端目录，少切一次窗口；但这种便利也会让人产生“现场被完整保存”的错觉。文件面板还在，不代表文件写入完成；标签标题没变，也不代表远端进程还活着。
会话日志能帮复盘，却补不回断线期间的输出
如果任务需要交接，我会在终端工具栏手动开始会话日志。Xterminal 当前的记录方式是按终端手动开始和停止，不会自动录制每个标签，也不提供基于屏幕快照的回放。这个限制反而提醒我：重要命令要先开启记录，再开始操作。
发生断线时，日志可能显示“连接已断开”或“停止待同步”。重连后要等同步完成再打开日志；如果状态变成“写入失败”，可以重新开始记录，但之前已写入的内容不会自动和新日志合并。也就是说，会话日志是证据的一部分，不是远端任务的备份。
我会把日志和任务输出分开看。日志能说明我在客户端输入过什么、屏幕看到了什么；任务输出文件或服务器端日志才能说明进程实际写入了什么。两者对不上时，以服务器端状态为准，再记录断线发生的时间段。
我还会在任务开始时留一行人为标记，例如“开始检查构建目录”或“准备重载测试服务”，让日志里出现一个能读懂的锚点。断线后回看这行，可以知道自己停在动作之前还是之后。这个习惯不依赖某个软件，换到系统终端或别的 SSH 客户端也能继续用。
如果断线发生在命令已经发出、结果尚未完整显示的时刻，我不会直接补发同一条命令。先查看进程列表、输出文件和服务日志，确认它是未启动、已完成还是仍在运行，再决定下一步。对可能重复写入的操作，宁可先做只读检查，也不要用“再执行一次”碰运气。
在 Xterminal 里，我会把会话日志状态、终端标签和远端文件面板放在同一工作区里观察。这样做减少了查找证据的时间，但也增加了一个判断责任：日志是客户端看见的内容，文件和进程才是服务器发生的事实。两者都回读，才算完成一次断线后的会话恢复复盘。
和 Xshell、FinalShell、Termius 比，我只看断线后的动作
这次比较不做功能排名，只看网络抖动后的回访。Xshell 的终端操作对老用户熟悉，适合已经用脚本或 tmux 管理任务的人；断线后是否继续，仍主要取决于服务器端会话。FinalShell 把连接、文件和状态入口放得较近，回到现场时少切窗口，但多面板也需要重新确认当前主机。Termius 更强调多设备之间的连接使用感，适合经常换设备的人，不过同步连接后仍要自己核对密钥、目录和任务状态。
Xterminal 对我有价值的地方，是自动重连、工作目录尝试恢复、持久会话入口和终端工作区可以在同一个连接上下文里使用。它减少的是“重新找到现场”的动作，不是把一个已经被杀掉的普通 Shell 变回来。若你已经有稳定的系统终端、tmux 和项目日志规范，换客户端未必带来收益；若你总在多个标签之间回访测试环境，图形化 SSH 客户端会更容易把检查线索放在眼前。
三种情况，我不会开启复杂恢复
第一种是一次性执行 cat、df -h 这类只读命令，连接断了重新输入比维护恢复设置更快。第二种是服务器权限不允许安装 tmux，又没有可靠的任务管理器，这时应把长任务交给 CI 或后台队列，不要把希望压在客户端重连上。第三种是生产环境的高风险变更，自动重连可能让你在没有重新确认主机和目录的情况下继续操作，我会关闭自动执行，断线后只做身份回读。
还有一个失败分支值得提前接受：网络恢复了，但远端服务刚好重启，原目录被清理，或者密钥代理状态失效。Xterminal 可能反复尝试连接，最终仍需要人工处理。自动重连不是无限重试许可证，遇到认证失败、主机身份变化或权限变化时，应该停下来查原因。
我的判断：把“回来”与“继续”分开
现在再遇到长命令，我会先问它是否值得在服务器端存活。值得，就用 tmux 或任务管理工具；不值得，就接受断线后重跑。然后在 Xterminal 里开启自动重连和目录恢复，把它当作回到窗口的辅助；回来后先读主机名、目录和退出状态，再看任务证据。
这也是我给新手的建议：先学会区分连接、Shell、进程和日志，再决定要不要换 SSH 客户端。Xterminal 能让回访少几步，Xshell、FinalShell、Termius 和系统终端也都能配合服务器端工具完成可靠工作。中级程序员更应该看重边界：任何客户端都不能替你保存普通进程，也不能替你确认断线期间发生了什么。
如果开头那次构建再来一遍，我会把构建放进 tmux，在客户端重连后先核对 hostname 和 pwd，再查看构建进程和输出文件。这样即使网络再次切换，我知道自己恢复的是哪一层，也知道下一步该相信哪条证据。