composer 不提供也不需要 vendor 目录的文件系统监控守护进程，其 autoload 机制基于静态映射或预生成 classmap，仅在构建阶段（如 composer install 或 dump-autoload）扫描 vendor，运行时不 readdir；所谓“免扫”本质是禁用 classmap 并优化解压流程。
Composer 本身不提供 vendor 目录的文件系统监控守护进程
别被“本地文件系统监控”这类词带偏——Composer 没有、也不需要运行一个常驻的 inotify 或 fsevents 守护进程来监听 vendor 变化。它的 autoload 机制是静态映射（PSR-4）或预生成类表（classmap），根本不会在运行时实时扫描目录结构。
所谓“减少扫盘开销”，实际指的是避免 composer install 或 composer dump-autoload 过程中对 vendor 下成千上万个 PHP 文件做递归遍历。这个动作只发生在构建阶段，不是运行时行为。
- PHP 自动加载器（
vendor/autoload.php）加载类时，只查映射表，不 readdir - 真正触发全量扫描的，是
"optimize-autoloader": true+"classmap-authoritative": true组合下执行composer dump-autoload，或composer install --optimize-autoloader - 即使你改了 vendor 里某个 .php 文件，只要没重新 dump-autoload，PHP 就不会知道——它只认当前生成的映射
为什么有人误以为需要“监控 vendor”
常见误解来源有三个：
- Windows Defender 实时扫描：解压 vendor 包时，每个 .php 文件被逐个送进 AV 引擎，看起来像“一直在扫”，其实是杀软行为，不是 Composer
-
IDE 或编辑器后台索引：PhpStorm、VS Code 的 PHP Intelephense 会主动遍历 vendor 建立符号表，可关掉“index vendor”选项，或加
**/vendor/**到工作区排除 -
某些老旧插件残留逻辑：比如已弃用的
hirak/prestissimo在 Composer 1.x 时代会额外触发 vendor 遍历，升级到 Composer 2.2+ 后该行为已被移除，但配置未清理干净仍可能激活兼容路径
真正有效的“免扫”方案：跳过 classmap 生成
如果你项目完全使用 PSR-4（Laravel、Symfony 默认如此），classmap 就是冗余的。禁用它，vendor 扫描直接消失：
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 删掉
composer.json里的"optimize-autoloader": true和"classmap-authoritative": true - 确认没有
"autoload": {"classmap": [...]}手动配置（包括所有 vendor 包的 composer.json） - 运行
composer install --no-autoloader，再手动composer dump-autoload --no-dev（只生成 PSR-4 映射） - 后续部署一律用
composer install --no-dev --no-autoloader，跳过 autoload 生成和脚本执行
这一步做完，composer install 时间从几十秒降到 2–5 秒，且不再触发任何 vendor 目录递归遍历。
WSL/Windows 下必须同步做的三件事
即使禁用了 classmap，NTFS + WSL 的 I/O 瓶颈仍会卡在解压环节：
- 把项目移到 WSL2 的原生 ext4 分区（如
/home/user/myproject），别放在/mnt/d/下 - 在 Windows 主机上，用 PowerShell（管理员）运行：
Set-MpPreference -ExclusionPath "D:\myproject" - 换用 7z 解压：在
composer.json加"config": {"archive-format": "7z"}，并确保系统 PATH 里有7z命令
这三项不全做，哪怕 classmap 关了，解压阶段依然可能卡住 20+ 秒——问题不在 Composer，而在文件系统与安全软件的协作方式。
