查占用文件：windows用资源监视器搜句柄，macos/linux用lsof；vscode报锁文件实为系统ebusy/eacces错误，需定位并合理关闭excel、tail、杀软等元凶进程，而非硬杀或仅重启vscode。
查谁在占用文件：Windows 用资源监视器，macOS/Linux 用 lsof
VSCode 报“文件被外部程序锁定”，本质是操作系统返回了 EBUSY 或 EACCES 错误，它只是转述——真正锁文件的是别的进程。别关 VSCode，先定位元凶：
- Windows：按
Ctrl+Shift+Esc打开任务管理器 → “性能”页 → 点“打开资源监视器” → 切到“CPU”页 → 在右下角“关联的句柄”里搜你的文件名（如package.json）→ 看“进程”列，常见有EXCEL.EXE、AntimalwareServiceExecutable.exe、另一个Code.exe - macOS/Linux：终端运行
lsof /full/path/to/filename.py；若提示command not found，macOS 上先brew install util-linux，Linux 一般自带；输出里带PID的那行就是占用者 - 特别注意 Git LFS 场景：如果文件是 LFS 跟踪对象，
git status显示未修改但无法保存，大概率是 LFS 后台 fetch 中——运行git lfs status查，必要时git lfs fetch --all
关进程别硬杀：优先关 Excel、tail -f、杀软实时防护
找到占用进程后，别一上来就 kill -9 或“结束进程树”：
- Excel 正开着 CSV/Excel 文件？直接关掉那个工作簿就行，不用杀 EXCEL.EXE 全局进程
- 终端里跑着
tail -f logfile.txt？按Ctrl+C停掉即可，安全且不中断其他服务 - 杀毒软件（如
AntimalwareServiceExecutable.exe）占着？临时关闭其实时扫描功能，比强制结束服务更稳妥 - 避免杀
svchost.exe或explorer.exe：它们只是宿主，实际句柄在子进程里，杀错会导致系统异常
为什么重启 VSCode 有时有用、有时没用
重启只清 VSCode 自身状态和插件缓存，对系统级文件句柄无效。它“管用”的真实原因是：
- 上一个 VSCode 实例没完全退出，残留的是读句柄（非写锁），新实例能抢到写权限
- 某个插件（比如 GitLens）在旧会话中卡死，导致伪锁定；重启后插件重载恢复正常
- 但若
EXCEL.EXE还开着、或tail -f还在跑，重启 VSCode 毫无意义——句柄还在那儿
WSL2 下的隐藏坑：/mnt/c 路径 + Git LFS + 杀软三重叠加
在 WSL2 里编辑 Windows 路径（如 /mnt/c/Users/name/project）时，问题往往不是单一的：
- Git LFS 默认在后台同步，但 WSL2 的 DrivFS 驱动对文件锁处理不一致，容易卡住
- Windows Defender 会对
/mnt/c下所有变更实时扫描，哪怕你只改了一行 JS，它也可能正拿着句柄 - 此时
lsof在 WSL 里查不到 Windows 进程，必须切回 Windows 用资源监视器查 - 临时解法：把项目移到 WSL 原生路径（如
~/project），或改用 Remote-WSL 扩展打开项目
真正容易被忽略的是：同一个文件可能被多个角色同时持有句柄——Excel 在读、杀软在扫、Git LFS 在同步。单查单关没用，得用资源监视器或 lsof 一次性看清全貌，再逐个清理。
