SMB 网络盘上的 Git 锁文件：一个网络文件系统引发的坑

根因：网络文件系统不保证原子删除#

Git 的锁机制依赖文件系统的一个原子操作：创建锁文件用 O_CREAT | O_EXCL——“如果文件不存在就创建，存在就报错”，这个操作是原子的，用来防止两个进程同时写。

但在 SMB 网络文件系统上，这个保证不牢靠。网络抖动时：

1. Git 进程创建了锁文件（index.lock）
2. 删除锁文件的操作因为 SMB 网络延迟 / 抖动失败
3. 锁文件残留在 .git 目录里
4. 下次任何 Git 操作看到锁文件存在 → 认为”有进程正在写” → 拒绝执行

网络断一下，锁就永远留下来了。

哪些锁文件会阻塞什么#

立即修复：删掉残留锁文件#

在仓库根目录执行：

1
find .git -name "*.lock" -delete

Windows 命令提示符：

1
del /q .git\index.lock .git\HEAD.lock 2>nul
2
del /q .git\refs\heads\*.lock 2>nul

注意：删锁文件前确认没有 Git 进程在真正运行——如果有个卡死的 Git 进程握着锁，删了也会被重新创建。

预防：降低碰撞概率#

1. 降低自动提交频率。 如果用了”自动备份”类插件（定时自动 commit），把间隔调大到 10-30 分钟。自动提交越频繁，并发碰撞的概率越高。

2. 避免设置包装脚本。 某些工具支持配置自定义 Git 路径 / 包装脚本，但配置可能被迁移到工具内部存储里，之后即使从配置文件删掉也不生效——必须在工具设置界面里手动清空。

3. 考虑本地 + 远程双副本。 如果对可靠性要求高，把仓库放本地，通过同步工具推送到远程，而不是直接在网络盘上跑 Git。

一句话经验#

网络文件系统（SMB / NFS / 网盘）对 Git 的原子锁操作支持不稳定。仓库尽量放本地盘，放网络盘就要接受”网络抖动 = 锁残留”的风险，并准备好清理手段。

这不是 Git 的 bug，是”网络文件系统不保证本地盘语义”这个通用事实。凡是依赖原子操作的工具（数据库、Git、构建缓存），放在网络盘上都要多一份警惕。