WebStorm的“safe write”导致文件变更未被监听，需关闭该功能：Settings → Appearance & Behavior → System Settings → 取消勾选“Use 'safe write'”，并重启WebStorm；同时排查Live Edit依赖、File Watcher冲突及Node.js与chokidar兼容性问题。
WebStorm 的 “safe write” 导致文件变更未被监听
Webpack、Vite 或 dva 的 dev server 依赖文件系统事件（如 fs.watch）检测源码改动。而 WebStorm 默认开启的 “safe write” 机制会先将修改写入临时文件，再原子性地替换原文件——这个过程可能绕过某些 watcher 的监听逻辑，尤其在 macOS 或部分 Linux 文件系统上更明显。
解决方法很简单：关闭它。
- 打开 Settings → Appearance & Behavior → System Settings
- 取消勾选 “Use ‘safe write’ (save changes to a temporary file first)”
- 重启 WebStorm（必要，否则设置不生效）
Live Edit 需要配套浏览器插件和 Debug 启动方式
Live Edit 不是热更新（HMR），而是 HTML/CSS 的即时注入，且只对 index.html 和内联样式/脚本有效，JS 模块变更不会触发刷新。它依赖两个前提同时满足：
- Chrome / Edge 安装
JetBrains IDE Support插件（ID:hmhgeddbohgjknpmjagkdomcpobmllji） - 必须通过 WebStorm 的 右键 → Debug ‘index.html’ 启动页面（不是直接用浏览器打开
file://或http://localhost:8080） - 浏览器顶部出现黄色提示条且未被关闭（关闭即断开 Live Edit 连接）
注意：Debug 模式启动后，修改 JS 仍需手动刷新或依赖框架自身的 HMR；Live Edit 对 React/Vue 组件内的 JS 逻辑无效。
文件监视器（File Watcher）干扰 webpack-dev-server
如果项目里手动配置了 File Watcher（比如 Sass 编译、TypeScript 转译），它可能与 webpack 的 watch 机制冲突，导致重复编译、监听延迟甚至静默失败。
排查建议：
- 进入 Settings → Tools → File Watchers
- 检查是否启用了与当前构建流程重叠的 watcher（如已用
vite build --watch，就禁用 WebStorm 内置的 TypeScript watcher） - 临时禁用全部自定义 watcher，观察是否恢复自动刷新
- 若必须保留，确保其 “Trigger on external changes” 选项关闭，避免响应 webpack 输出文件的变更
Node.js 版本与 chokidar 兼容性问题
webpack-dev-server 依赖 chokidar 监听文件，而新版 Node.js（v20+）在某些系统上对 fs.watch 的实现有变化，可能导致监听失效。这不是 WebStorm 的锅，但会表现为“保存了，但没反应”。
验证和缓解方式：
- 终端运行
npm start后，手动用 vim/nano 修改一个.js文件，看是否触发 rebuild —— 若终端有反应但浏览器不刷新，说明是 HMR 配置或网络问题；若终端也无反应，则大概率是底层监听失效 - 尝试降级 Node.js 到 v18.x（LTS），或在启动命令中加环境变量：
CHOKIDAR_USEPOLLING=true npm start - Windows 用户可额外启用
CHOKIDAR_INTERVAL=1000提高轮询灵敏度
真正卡住的地方往往不在框架配置，而在编辑器保存行为和底层文件监听的配合细节。关掉 safe write 是最常见解法，但别忘了确认你用的是哪种刷新机制——Live Edit、HMR 还是纯 page reload，它们的触发条件完全不同。
