一个工程师在服务器上跑一个 40 分钟的构建，用 ssh 直连执行。网络抖了一下，连接断了，构建被 SIGHUP 杀掉——这个"没有断点"是关键：很多长任务本身支持"续跑"（rsync、构建缓存、迁移批次），而"被 SIGHUP 杀掉"让它们"从头再来"——于是"一次网络抖动"代价 35 分钟。
而它已经跑了 35 分钟，且没有断点。

tmux 的价值不在于"分屏好看"，而在于"把进程从 SSH 连接上摘下来"。而这件事有三个层次：会话（断开不死）、窗格（同屏多任务）、以及"脚本化"（可重复的布局）。

---

1. 三个层次解决的问题

层次	解决
会话（session）	SSH 断开后进程继续
窗口（window）	多任务切换（如"日志/编辑/部署"）
窗格（pane）	同屏对照（如"改代码同时看日志"）

第一项是"最刚需"的：它把"进程的生命周期"与"连接的存活"解耦这个"解耦"是运维的基础认知：SSH 会话结束会给前台进程发 SIGHUP，于是"连接断"与"进程死"被绑在一起——而 tmux 做的就是把它解开。
——于是"网络断"不再等于"任务死"。

第二项与第三项的"收益"随"任务数"增长：两三个任务时手动切即可，五六个时"一个屏幕看全"才明显省时间。
第二项与第三项是"效率"：减少"切来切去"的上下文成本。

2. "断开不死"的三种做法与代价

做法	代价
tmux 会话	需要记住"attach"这一步
nohup ... &	看不到实时输出
systemd-run / 服务化	最规范，但配置重

第二项的问题在"输出"：日志进了文件，而"想看实时"要 tail -f——于是"边跑边看"变成了两个命令。

第三项适合"长期任务"：**它比 tmux 更可靠（崩溃重启、日志归 systemd 管）**第三项的"额外好处"是"日志被统一收集"：journalctl -u build 能看历史，而 tmux 的输出在"会话结束后就没了"。
，但"临时任务"用它太重。

// 三种做法（同一场景：跑 40 分钟构建）
tmux new -d -s build 'make build 2>&1 | tee build.log'   # 可 attach 看实时
nohup make build > build.log 2>&1 &                       # 只能 tail
systemd-run --unit=build --collect make build             # 日志进 journalctl

3. 会话的四个常用操作

操作	命令
新建（后台）	tmux new -d -s NAME 'CMD'
列表	tmux ls
接入	tmux a -t NAME
断开	Ctrl-b d

第一项的"实用性"在于"远程脚本化"：ssh host 'tmux new -d ...' 一条命令就能"起任务并返回"，于是它可以被写进部署脚本。
第一项的 -d 很关键：它让"创建"与"接入"分开——于是"起一个长任务"不必"先占一个终端"。

第四项是"干净退出"：断开不等于结束，会话还在跑——这正是它的价值。

// 一个完整的"远程长任务"流程（四步）
ssh blog 'tmux new -d -s deploy "bash /root/deploy.sh 2>&1 | tee /root/deploy.log"'
// 之后随时：ssh blog 'tmux a -t deploy'（看实时）；Ctrl-b d 断开
// 最后：ssh blog 'tail -20 /root/deploy.log'（确认结果）

4. 窗格布局的"可重复"

做法	效果
手动分屏	每次都要重摆
会话脚本（tmux script）	一条命令重建布局
配置里写 new-session	启动即布局

第二项是"脚本化"的核心：把"我常用的布局"写成文件，于是"换台机器也一样"。第二项的"附加价值"是"新人也用同一套布局"：于是"排查时看哪几个窗口"变成团队共识，而不是个人习惯。

// 布局脚本（logs.tmux）：左边 tail 日志，右边 shell
#!/usr/bin/env bash
tmux new-session -d -s logs -n main
tmux send-keys -t logs 'tail -f /var/log/app.log' C-m
tmux split-window -h -t logs
tmux send-keys -t logs 'htop' C-m
tmux attach -t logs
// 用法：bash logs.tmux

"会话命名"值得定一条约定，否则"一堆会话"会变成新的混乱：

// 命名约定（三要素，一眼看出"谁的、干什么的、什么时候起的"）
<用户>-<任务>-<月日>   例：yg-deploy-1110、yg-migrate-1110
// 清理：超过 2 天且无输出的会话 → 先看日志再 kill-session
tmux ls | awk -F: '$0 ~ /-11(0[0-9])-/ {print $1}' | xargs -r -n1 tmux kill-session -t
// 注意：先确认没有仍在跑的任务，清理是"人的判断"而非脚本自动

5. 三个"看起来用了 tmux 却没用"的情形

情形	问题
任务是"交互式"的	需要 attach 才能操作
输出被 tee 到文件但没 flush	tail 看不到实时
会话里跑的东西需要"输入"	断开后卡在等待输入

第一项的"识别"是"这个命令会不会等待 stdin"：会（read、y/n 确认、sudo 密码），就不适合"后台跑"。
第一项是"边界"：tmux 让"非交互任务"断开不死，而"交互任务"仍需要一个终端——于是"跑完就走"的任务适合，而"需要敲 y/n"的不适合。

第二项在"缓冲"上：有些程序输出到管道时是块缓冲，于是"实时"变成"攒一批"第二项的"判据"是"输出到终端时实时、输出到文件/管道时攒批"——这正是"行缓冲 vs 块缓冲"的差别，而它在"看日志"时最刺眼。
——用 stdbuf -oL 或 PYTHONUNBUFFERED=1 解决。

// 让输出"立即出现"（三行，按语言选一行）
stdbuf -oL -eL ./app                 # C/C++ 程序
PYTHONUNBUFFERED=1 python3 app.py    # Python
java -Dfile.encoding=UTF-8 ...       # Java 一般行缓冲，注意日志框架配置

"断线后到底死没死"可以用三个证据确认，而不是靠"回来看"：

// 三个证据（按可信度）
1 tmux ls 里会话还在 → 进程大概率还在（但可能已退出）
2 ps 里能看到目标进程 → 明确在跑
3 日志文件在增长（tail -1 前后对比 mtime） → 明确有输出
// 建议：先看 2 与 3，再看 1（1 只说明"会话壳还在"）

6. 排错：五种"用了 tmux 还是丢任务"

现象	成因	处理方向
断线后任务死了	没在 tmux 里跑	检查"命令是否在会话内"
会话在但"找不到输出"	输出在别处/未 flush	tee + 行缓冲
会话列表里有一堆	没清理	定期 kill-session
attach 后界面错乱	终端类型/尺寸	tmux a -d 或调 TERM
多用户抢同一会话	共享会话	tmux -S 指定 socket

第五项的"防法"是"各自用自己的会话"：tmux new -s $(whoami)-work，而不是"共用 main"——而"共享"只在"结对排查"时故意为之。
第五项在"排查协作"里常见：两个工程师同时 attach 同一会话，于是"我敲的命令在你屏幕上出现"——而它有时是优点（结对），有时是事故。

最后一个"可续跑"的设计视角：真正可靠的做法是"任务本身能续跑"，而不是"依赖不断线"。

// 三种"长任务"的可靠性（从低到高）
裸跑：断线即死，从头再来
tmux：断线不死，但机器重启即失
可续跑 + 队列：任意中断都能"从断点继续"
// 判据：这个任务"重跑一次"的代价有多大（小时级 → 必须可续跑）

7. 边界：什么情况不必用 tmux

场景	为什么	做法
本地开发（不断线）	无"断线"问题	直接跑
秒级命令	断线概率低	直接跑
已有服务化管理	平台负责	用服务
需要 GUI	终端不够	用远程桌面

判断口径一句话："这个命令会不会跑得比"你的 SSH 连接寿命"更久。最后一条与"可靠性"有关的边界：tmux 只解决"连接断"，不解决"机器重启"。要跨重启存活，得用 systemd 或"任务队列 + 续跑"——这两件事的边界要分清。
会（构建、迁移、压测），用 tmux 或服务化；不会（ls、git status），直接用。

---

8. 自测

1. tmux 的三个层次分别解决什么问题？哪一个是"最刚需"的？
2. "断开不死"的三种做法各有什么代价？为什么 nohup 的"输出"是问题？
3. tmux new -d 里的 -d 为什么关键？"断开"与"结束"的区别是什么？
4. 为什么"交互式任务"不适合放 tmux 后台？
5. "输出没实时出现"的两个原因是什么？怎么解决？
6. 判断"是否需要 tmux"的那个问题是什么？