auto_reload是唯一有效的自动重载开关，设为true后sublime text才可能静默重载已打开文件的外部修改；需在用户设置中添加合法json："auto_reload": true，保存即生效，但受原子写入、wsl2、未保存编辑等限制。
auto_reload 是唯一有效的开关，设为 true 后，Sublime Text 才可能静默重载已打开文件的外部修改；但这个设置本身不保证一定生效，尤其在原子写入、WSL2 或未保存编辑时会直接失效甚至丢内容。
怎么正确启用 auto_reload
只改用户配置（Preferences → Settings – User），添加一行合法 JSON：
{ "auto_reload": true }
保存即生效，无需重启。注意：always_reload_on_change、watch_files 等字段 Sublime 原生不识别——加了不仅没用，还可能导致配置解析失败。
-
auto_reload只对当前已打开且未关闭的标签页起作用 - 它依赖系统底层事件（Linux inotify / macOS fsevents / Windows ReadDirectoryChangesW）
- 修改必须写入原文件路径（非原子写入方式才稳定触发）
- 只读文件（如
chmod -w）不会触发重载，状态栏仅显示read only
为什么开了 auto_reload 还不刷新？
常见失效不是配置错了，而是系统或写入机制绕过了监控：
- Vim / git checkout / webpack watch 等使用原子写入：先写
file.tmp再rename()，Sublime 收到的是“删除+新建”，无法关联原标签页 - WSL2 下 inotify 支持极差，尤其对
/mnt/c/路径，auto_reload基本不可靠 - Linux 报
inotify_add_watch failed: No space left on device？其实是fs.inotify.max_user_watches耗尽，需调高内核参数 - macOS 没给 Sublime “完全磁盘访问”权限，fsevents 被系统拦截
验证是否真失效：终端执行 touch 文件名，看 Sublime 是否响应。若不响应，说明是环境或写入机制问题，不是配置没生效。
auto_reload 和 reload_modified 的区别
两者逻辑完全不同，不能互相替代：
-
auto_reload: true：主动监听系统事件，一旦检测到磁盘变化，**立刻重载**（前提是当前无未保存修改） -
reload_modified: true（默认开启）：被动检查，只有你**切换回该标签页**时才比对 mtime，弹出是否重载提示 - 若
auto_reload为true，reload_modified不再弹窗（静默覆盖）；若都为false，则完全无提示、无重载
想保留人工确认权？关掉 auto_reload，确保 reload_modified 是 true 即可。
侧边栏不刷新？那是另一个机制
auto_reload 只管编辑区内容，对侧边栏中的文件增删、图标状态、目录结构变化完全无感。比如你用 rm 删除了一个已打开的 .js 文件，Sublime 编辑区可能还显示旧内容，侧边栏仍挂着那个文件名，图标也不变灰。
- 手动刷新侧边栏：快捷键
Ctrl+Shift+P（Win/Linux）或Cmd+Shift+P（macOS），输入Refresh Folders回车 - 前提：项目必须已保存（
Project → Save Project As…），否则 Sublime 当作临时会话，刷新无效 - 若需自动监听侧边栏变化，得启用
file_watcher（ST4 build 4126+），设"mode": "native"或"mode": "poll"
最常被忽略的一点：auto_reload 不判断“文件是否存在”，只比对已打开文件的磁盘内容。它不会关 tab，也不会告诉你“这文件已经被删了”——这是设计取舍，不是 bug。
