subl -w 有时不阻塞终端，根本原因是其依赖 GUI 上下文与平台实现：macOS 对文件夹无效、tmux/IDE/SSH 中易失效；应搭配 -n 使用（如 subl -n -w file.txt），路径含空格需加引号，且不可用于目录。
subl -w 为什么有时不阻塞终端？
根本原因不是参数写错，而是 subl -w 的行为高度依赖 GUI 启动上下文和平台实现。macOS 上对文件夹无效，只对单个文件生效；在 tmux、某些 IDE 内置终端或远程 SSH 会话中，-w 可能直接失效或提前返回——它本质是靠 Sublime 主进程发信号通知子进程退出，GUI 初始化失败时这个链路就断了。
常见错误现象包括：subl -w config.json 执行后终端立刻返回，编辑器却还在运行；或反过来卡住不动，Ctrl+C 也无响应。
- 务必搭配
-n使用：用subl -n -w file.txt强制新建窗口，避免复用已有窗口导致状态混乱，提升-w的可靠性 - 路径含空格或中文时，必须用单引号包裹：如
subl -w '/Users/name/My Project/settings.json' - 不要对目录用
-w：比如subl -w .在 macOS 上完全不等待，Linux/macOS 均建议改用subl -n .+ 手动关闭 - 验证是否真在等待：执行后检查终端光标是否冻结（无新提示符），且
ps | grep sublime应显示子进程仍在运行
怎么让 git commit 等场景真正等编辑完成？
Git 默认调用 $EDITOR，若设为 subl -w 却没效果，大概率是环境变量未生效或 shell 配置未重载。更稳妥的做法是显式指定并绕过 shell 别名解析歧义。
- 临时生效（推荐测试）：
GIT_EDITOR="subl -n -w" git commit - 全局设置（持久化）：
git config --global core.editor "subl -n -w" - 避免使用别名：不要设
alias gitcommit='GIT_EDITOR="subl -w" git commit'，shell 层可能截断参数 - Windows 用户注意：
subl.exe -w在 PowerShell 中需加--分隔：如git -c core.editor="subl.exe -n -w --" commit
subl -w 在脚本里卡住或提前退出怎么办？
典型误用是把 subl -w 当作同步 I/O 操作，但它的等待逻辑不保证原子性。尤其当 Sublime 已有实例在运行，且未启用“允许从命令行重新聚焦”选项时，-w 可能无法正确关联到新打开的标签页。
- 脚本中优先用
subl -n -w，而非仅-w - 添加超时保护：例如在 Bash 中用
timeout 300 subl -n -w file.txt防止无限挂起 - 检查 Sublime 设置：
"remember_open_files": true和"hot_exit": false可减少因意外退出导致的等待异常 - 调试技巧：执行前先运行
subl --version确认命令可用，再试subl -w /tmp/test.txt（确保路径存在且可写）
替代方案：当 -w 实在不可靠时用什么？
没有绝对可靠的跨平台等待机制，但可以退而求其次——用文件系统事件监听代替进程等待。核心思路是让 Sublime 保存时触碰一个标记文件，脚本轮询它是否存在。
例如 Bash 脚本片段：
subl -n config.yaml
touch /tmp/subl_editing_flag
while [ -f /tmp/subl_editing_flag ]; do
sleep 0.5
if ! pgrep -f "subl.*config.yaml" > /dev/null; then
rm -f /tmp/subl_editing_flag
fi
done
这比纯依赖 -w 更健壮，但也增加了复杂度。真正关键的点在于：不要假设 -w 是银弹，它只是 Sublime 提供的一个尽力而为的同步辅助，实际集成时永远要加兜底判断。
