tmux 创建匿名数字编号会话，tmux new -s 名称 创建可识别命名会话并支持 -c 指定初始工作目录，避免路径错误；两者均实现会话与终端解绑，保障断网任务持续运行。
断网不会中断任务，前提是任务运行在 tmux 会话里，且你正确 detach 而非直接关终端。
tmux new -s 和直接 tmux 的区别在哪？
用 tmux 启动的是匿名会话，名称是数字（如 0、1），tmux ls 里看到的就是一串编号，容易混淆；而 tmux new -s 会话名 显式命名，比如 tmux new -s train-model，后续 tmux attach -t train-model 一目了然。
更关键的是：-s 参数支持 -c 指定初始工作目录，例如：
tmux new -s data-pipeline -c ~/projects/etl
这样进入会话后 pwd 就是 ~/projects/etl，不用再 cd。不加 -c 就继承当前 shell 的路径，多人协作或定时脚本启动时容易出错。
常见错误现象：用 tmux 启动后跑 python main.py，断开重连发现报错 No such file or directory —— 很可能就是因为路径不对，而命名 + -c 能直接规避。
Ctrl+b d 之后，进程真的还在跑吗？
是的，只要没执行 exit 或 Ctrl+d，进程就仍在服务器上运行。但要注意几个隐性条件：
- 进程不能依赖前台终端的 stdin/stdout/stderr 交互（比如卡在
input()等用户输入） - 不要在 tmux 外层再套一层 nohup 或 &，否则反而可能造成信号处理混乱
- 如果任务本身会检测终端是否活跃（如某些 SSH 封装工具），需确认它兼容伪终端（pty）
验证方式很简单：detach 后，在另一终端执行 ps aux | grep your_command，能看到进程仍在；或者用 tmux ls 确认会话状态是 (attached) 或 (detached)，而非已消失。
容易踩的坑：有人误把 Ctrl+b d 当成“退出”，然后关掉终端窗口——这没问题；但若先按 Ctrl+b，松开后误按了 c（新建窗口）或 &（关闭窗口），就可能意外杀死当前窗格里的进程。
tmux attach -t 无效？常见连接失败原因
tmux attach -t 会话名 报错 no sessions 或 can't find session，通常不是会话丢了，而是：
- 拼写错误：会话名区分大小写，
Train-Model≠train-model - 用户错位：你在 userA 下创建的会话，却用 userB 登录去 attach —— tmux 会话默认绑定到创建它的用户
- 服务未运行：极少数情况（如系统重启后未启用 tmux server），
tmux ls返回空，此时需先执行任意tmux命令唤醒服务
安全做法是始终搭配 tmux ls 先确认存在再 attach。如果只记得部分名字，可用通配：tmux attach -t "$(tmux ls | head -n1 | cut -d: -f1)"（取第一个会话），但生产环境仍推荐明确命名+记录。
另一个隐藏问题：SSH 连接时用了 ProxyCommand 或跳板机，而 tmux server 在目标机器，中间链路超时会导致 attach 卡住——这时可先 ssh target-host 进去再 attach，绕过代理层干扰。
为什么 tmux 比 nohup/screen 更适合长期任务？
nohup 只解决“后台运行”，但无法交互、无法查看实时输出、无法分屏监控；screen 功能接近，但默认不支持鼠标切换窗格、状态栏定制弱、插件生态差。
tmux 的优势体现在真实运维场景中：
- 日志滚动：按
Ctrl+b [进入复制模式，用方向键/PGUP 查看历史，q退出 —— 不用反复tail -f - 窗格同步：
Ctrl+b :setw synchronize-panes on，多个窗格同时输入命令（比如批量重启服务） - 会话共享：同事用同一账号
tmux attach -t deploy，实时协作排障（注意权限与审计）
真正容易被忽略的一点：tmux 会话默认不继承 shell 的 ENV 变量（如 PATH、自定义 alias）。如果你在 .zshrc 里加了 export PYTHONPATH=...，但在 tmux 里 python 找不到模块，就得在 ~/.tmux.conf 里显式设置：set-environment -g PATH "/usr/local/bin:/home/user/.local/bin:$PATH"。
