enable_autoreload必须关闭，因2026年起该配置已被移除逻辑支持，设为true会注入无效脚本，导致Sublime卡死、浏览器报livereload.js加载失败、预览页URL被篡改为about:blank。
MarkdownPreview 的 enable_autoreload 为什么必须关掉
它在 2026 年起的版本中已无实际逻辑，设为 true 反而触发无效脚本注入，导致 Sublime 卡死、浏览器加载 livereload.js 失败、预览页 URL 被悄悄替换成 about:blank。这不是配置没生效，而是插件主动拒绝响应——强行保留只会让保存变慢、刷新失序、调试线索中断。
LiveReload 插件 + CLI 组合里最常漏掉的三件事
Sublime 的 LiveReload 插件只是个“通知器”，真正干活的是全局安装的 livereload CLI 工具：
- 没运行
livereload . --port 35729 --exts html,css,js,md，整个链路就断了 - 浏览器扩展没点成实心绿色圆点，或没勾选
Allow access to file URLs，file://协议下直接静默失效 - CLI 端口（如
--port 35729）和浏览器扩展设置里的端口不一致，连接永远建立不了
ts-node-dev 构建系统里影响热重载稳定性的关键参数
Sublime 的构建系统不是“运行一次完事”，它得让 ts-node-dev 持续驻留并监听变更：
-
"working_dir": "${project_path:${folder}}"必须显式设置，否则找不到tsconfig.json和路径别名配置 -
--respawn是自动重启的核心开关，漏掉就等于没热重载 -
-r tsconfig-paths/register要紧挨着入口文件前，顺序错位会导致Cannot find module '@/utils' - Windows 下建议用
"cmd": ["cmd", "/c", "ts-node-dev ..."]，避免 PowerShell 缓冲阻塞
真正决定“秒级”还是“卡顿”的底层细节
热重载快不快，不取决于插件多炫酷，而在于文件变更能否被及时捕获、注入是否精准、浏览器是否允许执行：
- Sublime 的
"atomic_save": false必须开启，否则rename中间态会让livereload或ts-node-dev监听失效 - Linux/macOS 下若用
rbenv或nvm，必须从已加载 shell 环境的终端启动subl .，否则which node为空，构建系统找不到命令 -
file://协议下 Chrome/Edge 的「预测服务」会拦截本地刷新，需手动关闭chrome://settings/privacy中对应选项
热重载链条越长，每个环节的容错就越低；看似只是点一下保存，背后是 Sublime、CLI、浏览器扩展、Node.js 运行时四层协同——少一个条件，就卡在某个环节不动，而且往往不报错，只“没反应”。
