进阶与大仓实践69 条

fsmonitor 加速状态查询

文件系统监控让 git status 不再全量扫描工作区：新版 Git 内置 FSMonitor（core.fsmonitor=true），在 Windows/macOS 上对大工作区收益明显。

Git 与协作速查开发更新于 2026-10-13

fsmonitor 是什么

fsmonitor 让 Git 借助操作系统的文件系统事件通知来判断「哪些文件被动过」，git status 不再逐目录扫描整个工作区。新版 Git 内置监控守护进程，core.fsmonitor=true 即启用（Windows 与 macOS 支持），大工作区上状态查询提速明显。监控不可用时 Git 会自动退回全量扫描，性能时好时坏往往与守护状态有关。

基本信息

启用	git config core.fsmonitor true（内置守护）
关闭	git config core.fsmonitor false
平台	Windows 与 macOS 内置；Linux 常见做法是接第三方监控如 watchman
验证	对比启用前后 git status 的耗时，二次执行才代表稳态

典型使用场景

超大工作区：数万文件的项目里 status 与 add 的扫描阶段明显变慢
前端与 monorepo：node_modules 层级深、目录多，频繁 status 与切分支的日常操作提速
编辑器与工具集成：IDE 后台反复调用 status，降低索引扫描的 CPU 占用
性能对照测量：作为一组索引加速特性逐项启用、分别量化收益

常用示例

git config core.fsmonitor true        # 启用内置文件系统监控
git status                            # 首次建立基线仍会全量扫描
git config core.untrackedCache true   # 常与未跟踪缓存搭配，减少目录扫描
time git status --porcelain | wc -l   # 粗略对比启用前后的耗时

提速不明显时排查

现象	可能原因	处理
首次 status 仍慢	建立监控基线需要一次全量扫描	第二次执行再看耗时
时好时坏	监控守护退出后回退扫描	git fsmonitor--daemon status 查看守护
一直没收益	仓库在网络盘或共享挂载上，事件不可靠	把工作区放到本地磁盘再测

core.fsmonitor 也可以指向一个 hook 程序路径（旧式集成，如 watchman）：布尔值时使用内置守护，填路径时由自定义程序提供变更列表。

监控状态记在索引里，守护重启或大批量文件操作后可能重建基线；大规模删改后的第一次 status 变慢属于正常现象。

易错点

网络盘与虚拟共享目录（虚拟机共享文件夹、部分容器挂载）上事件通知不可靠，监控频繁失效甚至更慢，先在本地磁盘验证
特性叠加难归因：fsmonitor、untracked cache、sparse index 一起开时，先单项启用再叠加，保留测量基线
守护异常被误判为特性无效：Git 会静默回退扫描，用 git fsmonitor--daemon status 确认后再排查系统通知服务
杀毒软件实时扫描与监控守护互相干扰时收益波动，测量时把干扰项排除或加白名单

数据来源与参考

Git 官方文档：git-config（core.fsmonitor）
Git 2.37 Release Notes（内置 FSMonitor）

继续搜索

常用关键词：3389 traceroute iptables 子网掩码 docker

‌‌‌‌‌‌‌‌‌‌‌‌‌‌‌‌‌‌‌‌‌‌‌‌‌‌‌‌‌‌‌‌‌‌‌‌‌‌‌‌‌‌‌‌‌‌‌‌‌‌‌‌‌‌‌‌‌‌‌‌‌‌‌‌‌‌‌‌‌‌‌