sublime text 不监听符号链接目标文件的修改，因其文件监听机制默认不递归跟踪 symlink；解决方法是将 symlink 替换为真实路径并添加到项目配置中。
Sublime Text 无法监听符号链接目标文件的修改
Sublime Text 默认只监控它“认为”是项目一部分的路径，而符号链接（symlink）在 macOS/Linux 下常被用作快捷方式或共享配置目录。但 Sublime 不会自动跟随 symlink 去监听其指向的真实路径——结果就是你改了源文件，编辑器里不刷新、保存不生效、语法高亮卡住，甚至 Ctrl+S 后文件内容回退到旧状态。
这不是 bug，是设计行为：Sublime 的文件监听基于 inotify（Linux）或 FSEvents（macOS），它们默认不递归监听 symlink 目标，除非显式启用。
- 确认是否为 symlink：终端执行
ls -la，看到路径旁有->指向另一路径，就是它 - 不要把 symlink 当普通文件夹直接拖进侧边栏添加；Sublime 会把它当“空容器”处理，不扫描内部
- 如果项目根是 symlink，整个项目索引和监听都会失效——
index_files设置可能被忽略，folder_exclude_patterns也不起作用
让 Sublime 正确识别并监听 symlink 目标路径
唯一可靠的做法，是绕过 symlink，直接把真实路径加进项目。但如果你必须保留 symlink 结构（比如统一管理 dotfiles 或跨仓库共享 config），就得手动告诉 Sublime “这个链接该被当作真实目录对待”。
- 打开命令面板：
Ctrl+Shift+P（Windows/Linux）或Cmd+Shift+P（macOS） - 输入
Project: Edit Project，回车，编辑当前项目的.sublime-project文件 - 在
"folders"数组中，把 symlink 路径替换成它的实际目标路径（用readlink -f /path/to/symlink或realpath /path/to/symlink获取） - 确保该路径存在且可读；如果目标路径含空格或中文，请用双引号包裹，如
"path": "/Users/name/my project/config"
保存后重启 Sublime —— 此时索引会重建，Indexing Status 可能短暂出现，但后续修改就能实时响应了。
Windows 上的 junction 和 mklink 链接更麻烦
Windows 的 mklink /D 或旧版 junction 创建的目录链接，Sublime 完全不识别。它会把链接当普通文件夹打开，但内部文件不会被纳入监听范围，也不会出现在 Ctrl+P 搜索中。
- 别指望
folder_exclude_patterns或binary_file_patterns能修复这个问题——监听层根本没启动 - 最稳方案：在项目设置中用绝对路径指向真实目录，例如
"path": "C:\dev\shared-configs" - 如果必须用链接，可尝试在 Windows 设置中启用“开发人员模式”并开启“符号链接支持”，但 Sublime 自身仍不主动跟随；这仅对系统级工具有效，不影响编辑器行为
插件干扰 symlink 监听的典型表现
某些插件会在文件系统层做额外封装，进一步掩盖 symlink 的存在。比如 SideBarEnhancements 或 GitGutter 在解析路径时若未正确调用 os.path.realpath()，就可能把 symlink 当作孤立节点，导致右键菜单异常、Git 状态不更新、甚至保存时写入错误位置。
- 临时禁用插件验证：通过
Preferences → Package Control → Disable Package关掉GitGutter、SublimeLinter、EditorConfig - 观察
Ctrl+Shift+P → Show Console中是否有类似OSError: [Errno 2] No such file或路径拼接错误的报错 - 检查插件自身设置：进入
Preferences → Package Settings → [插件名] → Settings – User，搜索follow_symlinks或resolve_path字段，设为true（少数插件支持）
真正棘手的是，这类问题往往没有明确报错，只表现为“改了没反应”。盯住控制台日志、确认路径真实性、跳过中间链接直连源头，比反复调参数更省时间。
