VSCode终端必须配置tmux new-session -A -s code作为唯一可靠入口，因其可实现会话级复用、避免进程丢失、统一命名便于管理，并确保登录shell加载环境配置；分屏需在tmux内操作，Remote-SSH场景下tmux是保命刚需。
VSCode 自带终端不支持真正意义上的多路复用，必须靠 tmux 实现会话级复用；关窗即丢进程、SSH 断连就崩服务，这不是配置问题，是设计限制。
为什么 terminal.integrated.profiles.linux 配 tmux new-session -A -s 是唯一可靠入口
VSCode 终端默认启动的是裸 shell，生命周期完全绑定窗口。一旦关闭标签页或重启编辑器，npm run dev、docker logs -f 全部被 SIGTERM 杀死。加 -A -s code 是绕过这个限制的最小改动：
-
-A表示“存在则 attach，不存在则创建”，避免重复开一堆0、1会话导致tmux ls满屏不可读 -
-s code强制统一命名，方便脚本调用（比如远程 CI 或一键恢复命令） -
args必须用["-l", "-c", "tmux new-session -A -s code"]，不能省略-l（login shell），否则~/.bashrc或~/.zshrc不加载，插件/别名失效 - Windows 用户若走 WSL2，仍配
linux分组；原生 PowerShell 不支持 tmux，别试
分屏必须在 tmux 内做，Ctrl+\ 只是多个独立进程
VSCode 的 Ctrl+\ 或右键 Split Terminal 本质是 fork 出新 PTY，每个分屏都是独立 shell 进程，不共享历史、无法统一 detach、滚动缓冲也不互通。真要组织任务，得进 tmux 后操作：
-
Ctrl+b %：垂直分屏（左/右） -
Ctrl+b "：水平分屏（上/下） -
Ctrl+b ,：重命名当前窗格（比如标成server、logs、db），比记 layout 编号靠谱得多 -
Ctrl+b w：列出所有窗格并切换，比鼠标点标签快 - 别在 tmux 里再套
screen，嵌套会导致SIGWINCH尺寸同步失败，窗格错位或光标乱跳
Remote-SSH 下 tmux 不是加分项，是保命刚需
Wi-Fi 切换、笔记本合盖、网络抖动……这些都会让 Remote-SSH 连接中断。没 tmux，rails s、tail -f /var/log/syslog 全部归零。关键配置点很具体：
- 远程服务器必须装 tmux：
sudo apt install tmux（Ubuntu/Debian）或brew install tmux（macOS remote host） - VSCode 的
terminal.integrated.defaultProfile.linux必须显式指向你配好的 tmux profile，不能留空或指回默认bash -
~/.tmux.conf里检查set -g default-shell是否指向真实存在的路径（比如误写成/bin/zshx会导致 attach 黑屏且无提示） - VSCode 启动终端时工作目录是 workspace root，但 tmux 默认
default-path是~；如需自动 cd 进项目，可在 args 里改写为：["-l", "-c", "cd $(pwd) && tmux new-session -A -s code"]
最易忽略的坑：tmux 的 default-path 和 VSCode 工作目录不一致
很多人配完 tmux 发现新窗格总在 ~ 而不是当前项目目录，翻遍 settings.json 也找不到原因——其实是 tmux 自身行为：default-path 默认是 home，和 VSCode 的 workspace root 完全无关。解决方法只有两个：
- 手动在 tmux 里
cd，然后Ctrl+b :setw default-path .（临时生效） - 或在 profile 的
args中硬编码cd，如上一条所示；注意$(pwd)是启动终端时的路径，不是 tmux server 启动时的路径 - 别依赖
terminal.integrated.cwd，它只影响初始 shell，不影响 tmux 新建窗格
