auto_reload仅在文件路径不变、系统监控有效且无未保存编辑时才生效；测试工具原子写入导致Sublime收到“删除+新建”事件而无法关联标签页，WSL2下/mnt/c/路径监听失效，且auto_reload与reload_modified互斥。
auto_reload 是唯一能触发自动重载的开关，但直接启用后，在配合自动化测试工具（如 pytest、jest、webpack watch）时大概率失效——不是配置错了，而是测试工具写文件的方式绕过了 Sublime 的监听机制。
为什么测试工具输出的文件不自动刷新？
绝大多数自动化测试/构建工具（包括 pytest --tb=short 输出日志、jest --watch 生成快照、webpack --watch 写 bundle.js）默认使用原子写入：先写 file.tmp，再 rename() 覆盖原文件。Sublime 收到的是「删除 + 新建」两个独立事件，无法关联到已打开的标签页，auto_reload 完全不触发。
- 验证方法：终端执行
touch 文件名，如果 Sublime 响应了，说明配置和系统监控正常；不响应，则大概率是原子写入导致 - Linux/macOS 下可临时禁用原子写入（若工具支持）：例如 jest 加
--no-cache，webpack 用devtool: 'eval'配合output.filename直接写入（不推荐生产，仅调试） - 更可靠的做法：改用非原子写入的日志/输出方式，比如让测试脚本用
echo "..." >> output.log追加，而非覆盖重写
WSL2 环境下根本别指望 auto_reload 工作
WSL2 的 inotify 实现对 /mnt/c/ 路径的支持极差，即使 auto_reload 设为 true，也几乎收不到任何文件变更通知。这不是 Sublime 的 bug，是 WSL2 内核层限制。
- 临时缓解：把项目移到 WSL2 原生路径（如
~/project/），再试touch验证 - 长期建议：在 Windows 原生环境运行 Sublime，或换 VS Code（其文件监听对 WSL2 兼容性更好）
- 不要尝试调高
fs.inotify.max_user_watches——它对 WSL2 挂载路径无效
auto_reload 和 reload_modified 别混用
两者逻辑互斥：auto_reload: true 启用后，reload_modified 彻底失效。你不会收到任何弹窗提示，只要磁盘内容变了，且当前标签页没有未保存编辑，Sublime 就静默覆盖缓冲区。
- 风险点：测试工具跑完立刻覆盖日志文件，而你正盯着那个 tab 修改注释——
auto_reload会直接清空你刚写的几行，不警告、不备份 - 安全策略：如果你需要人工确认权（比如对比测试前后差异），就关掉
auto_reload，确保reload_modified: true（默认已是） - 检查方式：打开
Preferences → Settings – User，确认没有"always_reload_on_change"字段——这是无效字段，Sublime 不识别，加了还可能因 JSON 错误导致整个配置失效
侧边栏和文件状态完全不联动
auto_reload 只管编辑区文本内容，对文件是否存在、是否被删、目录结构是否变化毫无感知。测试工具删掉一个 test_old.py，Sublime 的侧边栏仍显示它，tab 也还在，状态栏也不变灰。
- 手动刷新侧边栏：按
Ctrl+Shift+P（Win/Linux）或Cmd+Shift+P（macOS），输入Refresh Folders回车 - 前提：项目必须已保存（
Project → Save Project As…），否则 Sublime 当作临时会话，不维护文件树状态 - 如果测试工具频繁增删文件，建议搭配插件如
SideBarEnhancements或定期手动刷新，别依赖自动同步
最常被忽略的细节：自动重载只在「文件路径不变 + 系统监控有效 + 无未保存编辑」三个条件同时满足时才真正起作用。测试流程里任意一环出问题，它就静默退场，连个错误提示都不会给。
