根本原因是锁被进程持有而非文件残留，需先定位并终止持锁进程（如ide后台git服务），再检查句柄占用，最后重建损坏索引。
遇到 fatal: unable to create '.git/index.lock': file exists，本质不是文件没删干净，而是“锁还被某个进程攥着”。高频异常中断（比如反复 Ctrl+C、IDE 自动提交卡死、WSL 终端意外关闭）会让 Git 进程残留句柄或 PID 信息，导致 .git/index.lock 被持续持有——你删了它，它秒复活；你重试命令，它继续报错。排查必须从“谁在持锁”切入，而非只盯文件本身。
确认当前是否真在 Git 仓库根目录
很多误操作源于路径错误：你在子目录执行命令，却试图删主仓库的锁文件，或删了 submodule 里的锁却不管主仓库。
- 运行
git rev-parse --git-dir，输出应为.git（根仓库）或.git/modules/xxx（子模块） - 若报
fatal: not a git repository，说明不在任何 Git 环境里，删.git/index.lock完全无效 - 若输出是 submodule 路径，需进入对应子模块目录再操作，主仓库的锁和它无关
定位并终止真实持锁进程（非简单 kill -9）
直接删锁文件治标不治本。Windows 和 Linux/macOS 的排查逻辑一致：先找进程，再看它是否真在操作索引。
-
Linux/macOS：执行
ps aux | grep -E '(git|code|idea|webstorm)'，重点观察是否有git commit、git merge、git rebase或编辑器启动的后台 Git 进程（如code --git） -
Windows：运行
tasklist | findstr "git.exe code.exe idea64.exe webstorm64.exe"，IDE 后台服务（尤其是 VSCode 的 Git Host Process）是高频持锁源 - 发现可疑进程后，用
kill -9 [PID]（Linux/macOS）或taskkill /f /pid [PID]（Windows）强制结束，不要只关终端窗口
检查文件句柄是否被系统级组件锁定
尤其在 Windows 上，删不掉 index.lock 往往不是权限问题，而是资源管理器、杀毒软件或 Git Bash 守护进程正持有该文件句柄。
- 退出所有 IDE、Git GUI 工具（SourceTree、GitHub Desktop）、Git Bash、PowerShell 中与该仓库相关的会话
- 临时关闭 Windows 资源管理器的“预览窗格”和“详细信息窗格”，避免 Explorer 扫描并锁定文件
- 仍无法删除？下载 Process Explorer，搜索
index.lock，直接右键“Close Handle”释放句柄
删锁后仍报错？索引文件可能已损坏
如果删完 .git/index.lock 立即执行 git status 仍失败，或提示 error: bad index file sha1 hash，说明 .git/index 本身在上次崩溃中写坏。
- 先备份：运行
cp .git/index .git/index.bak（Linux/macOS）或copy .git\index .git\index.bak（Windows） - 重建索引：删除损坏的索引
rm -f .git/index，再执行git reset（会重新生成 index 并同步工作区状态） - 验证完整性：运行
git fsck --full检查对象库是否异常；若大量报错，建议git stash本地修改后重新克隆
