科技 · 实用指南
Git 提示 index.lock 已存在？删除前先证明占用者
锁可能属于仍在写入的 Git、崩溃后的残留、不断重建它的 hook/IDE，或不可写仓库。先解析真实路径、核对持有者、保存暂存状态，再只修复已证明的边界。
index.lock 是 Git 更新索引时的保护，不是看到就删的垃圾。同一提示可能代表活跃写入、崩溃残留、持续重建或原子重命名无法完成。
按证据顺序处理：解析路径、保存暂存状态、找持有者、判断重现与可写性，最后只做一次窄修复。
保留状态并解析真实锁路径
先保存完整错误，再运行 git status 与 git diff --cached --stat，确认索引里是否已有准备提交的改动。不要删除 .git/index；那是二进制索引本体。使用 git rev-parse --path-format=absolute --git-path index.lock 获取 Git 实际使用的路径。
记录该文件是否存在、所有者、权限、大小与修改时间。零字节或时间较旧只能提示可能陈旧，不能证明没有活跃写入者。Git 用 index.lock 构建新索引，再原子重命名或回滚。
证明是谁占用或重建锁
Linux/macOS 用 lsof 查询精确路径；Windows 用 Process Explorer 或 Handle 搜索。先确认进程、账户和父进程，再决定是否停止。它可能是等待编辑器的 Git、IDE、GUI、hook、索引器或自动化任务。
如果没有当前持有者，观察一次受控重试。锁立刻再出现，说明存在持续生产者或重叠 Git 命令。暂停相关 IDE、hook、watcher 或任务并串行化写入，不要反复删锁。
只删除已确认的陈旧锁
只有在路径准确、没有持有者、原操作已结束且文件不会立刻重现时，才可判定为陈旧。先保存状态和暂存摘要，然后只删除这个 index.lock，不要一并删除 index、HEAD、refs 或其他锁。
先执行 git status，再单独重试原写操作。确认成功后锁消失，git diff --cached 仍只有预期改动。如果 Git 报出另一个锁路径，回到路径解析，不要扩大删除范围。
把权限与 unlink 错误当作另一类故障
如果 Git 无法创建、重命名或删除锁，检查解析出的 Git 目录的所有权、可写性与文件系统。WSL 的 Windows 挂载路径、网络共享、容器绑定挂载或安全扫描目录都可能与本地文件系统不同。
不要把 sudo git 或递归 chown 当通用修复；它们可能制造混合所有权或改动无关文件。只修复证据指向的用户、挂载、防病毒或策略边界，再以原用户复测。
用可复现检查结束事件
只从一个终端运行原 Git 写操作。核对退出码、锁是否消失、git status 与 git diff --cached，并记录导致阻塞的进程或陈旧文件。hook 修改索引时应审查设计，而不是用 --no-verify 隐藏冲突。
自动化应串行化同一索引的写命令，并记录开始、结束和仓库路径。不同 worktree 有独立索引状态，但解析后的路径始终是权威。
