在 macOS 上真正替代screen：不只是命令替换，而是终端工作流的重构
你有没有过这样的经历？深夜调试一个嵌入式设备，串口日志正刷着关键错误，突然 SSH 断了——然后你发现minicom进程没了，tail -f /var/log/syslog停了，连刚写到一半的git commit -m都悬在半空。不是网络不稳，是 macOS 默认没装screen，而你又没提前配好替代方案。
这不是小问题。这是现代开发中会话即状态的底层断裂。screen的缺席，暴露的其实是 macOS 对“终端作为第一类运行环境”这一理念的长期忽视——它把 Terminal.app 当作 GUI 的附属品，而非可编程、可持久、可审计的计算载体。
但好消息是：这个缺口早已被填平，而且填得比screen更深、更稳、更面向未来。答案不是找一个“差不多能用”的替代品，而是用tmux+reattach-to-user-namespace重建一套具备生产级鲁棒性的终端操作系统。
为什么tmux不是screen的模仿者，而是它的进化体？
先说结论：tmux和screen确实都解决“断线不断进程”的问题，但它们的底层契约完全不同。
screen是个“单体进程”：它 fork 出子 shell，自己劫持 stdin/stdout/stderr，再模拟 tty 行为。这种设计在 1987 年很聪明，但在今天，它成了扩展性与可靠性的天花板——比如，你无法让screen的某个窗格运行在独立 cgroup 里，也无法让它原生支持 Wayland 剪贴板协议，更没法给每个 session 分配不同 UID。
而tmux是 client-server 架构：
tmux server是一个常驻内存的守护进程（/tmp/tmux-<uid>/<socket>），只管状态调度；- 每个
tmux attach都是一个轻量 client，只负责渲染和转发输入； - 所有 pane 中运行的进程（
zsh、ssh、docker logs -f）都是真正的子进程，拥有完整信号语义和环境隔离。
这意味着什么？
→ 你可以killall tmux而不影响任何正在运行的服务进程；
→ 你可以tmux set -g limit-cpu 200限制整个会话 CPU 占用（需 patch 版本）；
→ 你可以用systemctl --user import-environment把 systemd 用户会话注入tmux，实现服务+终端一体化编排。
这不是功能叠加，是范式升级。
tmux的核心配置，必须改的三件事
别急着抄一整套.tmux.conf。先确保这三件事做对，否则你永远觉得tmux“用着别扭”。
