auto_reload是唯一有效开关，需设为true并验证系统监控（如touch测试），但原子写入、WSL2、未保存编辑等场景会静默失效或丢内容。
Sublime Text 默认不自动重载外部修改的文件内容，auto_reload 是唯一能启用静默热重载的配置项，但它在多数真实开发场景中会“看似开启却无反应”——问题通常不出在设置本身，而在于写入方式、系统监控或编辑状态。
怎么确认 auto_reload 真正生效了
别只看配置写了没，先验证底层监听是否通：
- 终端执行
touch当前已打开的文件，观察 Sublime 是否立刻刷新内容；若无反应，说明不是配置错，而是 inotify/fsevents 被阻断 - Linux 下检查是否报
inotify_add_watch failed: No space left on device—— 实际是fs.inotify.max_user_watches耗尽，需运行echo fs.inotify.max_user_watches=524288 | sudo tee -a /etc/sysctl.conf && sudo sysctl -p - macOS 上去「系统设置 → 隐私与安全性 → 完全磁盘访问」确认 Sublime Text 已勾选，否则 fsevents 请求直接被系统丢弃
- WSL2 环境下基本无效：/mnt/c/ 路径的 inotify 事件丢失率极高，建议改用 Windows 原生 Sublime 或换 VS Code
为什么 webpack/vim/git checkout 后文件不刷新
这些工具普遍采用原子写入（atomic write）：先写 file.tmp，再 rename() 覆盖原文件。Sublime 监听到的是“删除 + 新建”，无法关联到已有标签页，auto_reload 自然失效。
- Vim 用户可加
set nowritebackup和set nobackup关闭备份机制，再配合set backupcopy=yes强制覆盖写入（但可能影响 Vim 插件行为） - webpack watch 默认用原子写入，加
devServer.writeToDisk: true并配output.clean: false可缓解，但不能根治 - Git checkout 无法绕过原子语义，只能接受手动
Ctrl+R或切换标签页触发reload_modified提示 -
auto_reload和原子写入是根本冲突的设计，没有插件能可靠桥接——这是 Sublime 的架构限制，不是 bug
未保存编辑时 auto_reload 会静默丢内容
这是最危险也最容易被忽略的一点：auto_reload: true 触发时，只要当前文件有未保存修改，Sublime 就直接覆盖内存内容，不弹窗、不备份、不提示。
- 务必确保
hot_exit和remember_open_files均为true（默认已是，但建议打开 Settings – User 确认） - 编辑日志、构建输出等只读但高频变动文件时，可加
"atomic_save": false，但这只影响你自己的保存行为，对外部写入无帮助 - 想保留人工确认权？关掉
auto_reload，保持reload_modified: true（默认开启），这样切换回标签页时才会弹提示 - 永远不要依赖
always_reload_on_change：它是部分旧插件误传的字段，Sublime 原生不识别，加了不仅无效，还可能导致 JSON 解析失败
侧边栏不更新和热重载是两回事
文件内容自动重载 ≠ 文件树自动同步。删了一个 .js 文件，Sublime 不会关 tab，也不会从侧边栏消失——它根本不知道文件已被删。
- 侧边栏刷新需手动触发：
Ctrl+Shift+P（Win/Linux）或Cmd+Shift+P（macOS），输入refresh folders回车 - 前提：项目必须已保存（
Project → Save Project As…），否则 Sublime 按临时会话处理路径，刷新无效 -
folder_exclude_patterns影响“刷新后看到什么”，但不影响刷新动作本身 - 没有配置能让侧边栏像 VS Code 那样实时响应增删——这是 Sublime 故意为之的性能取舍
