应先排查并终止残留Git进程，再删除.index.lock文件；若仍报错，需重建索引或检查杀毒软件干扰。
git checkout / pull 报 “index.lock: File exists” 怎么办
直接删 .git/index.lock 通常没用——只要持锁进程还在跑，它几秒内就会重建这个文件。真正要动的是“谁在占着锁”，不是“锁本身”。
- 先确认是否真有残留进程：Windows 上执行
tasklist | findstr git，再补一句tasklist | findstr "code.exe|idea64.exe|webstorm64.exe"；Linux/macOS 用ps aux | grep -E "(git|code|idea)" - 看到
git commit、git merge或 IDE 相关进程（比如code --git）就大概率是它；别犹豫，用taskkill /f /pid [PID]（Win）或kill -9 [PID]（macOS/Linux）干掉 - 删锁前务必验证当前目录是仓库根：运行
git rev-parse --git-dir，输出必须是.git或绝对路径；如果输出.git/modules/xxx，说明你在 submodule 里，得去对应子模块删自己的index.lock
为什么 VSCode 或 WebStorm 经常“偷偷持锁”
IDE 的 Git 插件默认启用后台自动 fetch、status 检查，它们会起独立的 Git 进程，且不显式暴露在终端里。这类进程一旦卡住（比如网络超时、大文件 diff 中断），就会长期持有 index.lock 而不释放。
- 临时解法：关闭所有编辑器窗口，再删锁；更稳妥的是在 VSCode 设置里关掉
git.autoFetch和git.enableSmartCommit - WebStorm 用户注意：
VCS → Git → Background tasks里勾选的 “Update project on startup” 和 “Fetch on branch change” 是高频肇事项，建议禁用 - 杀毒软件（尤其 Windows Defender 实时保护）有时会扫描
.git/index文件并短暂锁定句柄，导致 Git 写锁失败；可临时排除整个项目目录
删了 index.lock 还报错？可能是 index 文件已损坏
锁文件只是表层症状。如果删完 .git/index.lock 立即执行 git status 仍失败，或提示 error: bad index file sha1 hash，说明上次崩溃时索引文件写到一半就中断了，内容已不一致。
- 不要硬修，直接重建索引：
git rm -r --cached . && git add .（慎用，会重算全部暂存状态） - 更轻量的做法：
git update-index --refresh尝试修复；若失败，再用git read-tree --reset -u HEAD强制重置工作区与索引对齐 - 极端情况（如
git fsck报 object missing）：备份好未提交修改后，删掉整个.git/index，让 Git 下次操作自动重建
如何避免下次再被锁住
根本解法不是写个脚本删锁，而是切断并发源头。Git 本身不支持多进程安全写索引，所有“同时操作”都是危险行为。
- 禁止在同一个仓库开多个终端执行 Git 命令；尤其避免一边
git pull一边在 IDE 里点 Commit - CI/CD 脚本里加
git config --local core.filemode false和core.autocrlf input，减少因文件属性变更触发的隐式 index 更新 - 团队约定：远程分支更新统一走
git pull --rebase，避免git merge启动交互式合并流程（容易卡在编辑器里）
index.lock 文件，而是你不知道哪个进程正把它攥在手里——而且它可能藏在 IDE 后台、资源管理器预览窗格，甚至杀软扫描队列里。 
