禁用classmap是见效最快、副作用最小的手段：将composer.json中"optimize-autoloader"和"classmap-authoritative"设为false，执行composer install --no-autoloader与dump-autoload --no-dev，仅生成psr-4映射；同时排除defender扫描、禁用vcs缓存、项目置于wsl ext4分区。
Composer 在 vendor 文件极多（数万级）的磁盘环境下，扫描热点开销主要来自 classmap 生成、Defender 实时扫描、NTFS/WSL 路径遍历延迟三者叠加——禁用 classmap 是见效最快、副作用最小的手段。
禁用 classmap 自动生成（最有效）
classmap 是 vendor 扫描慢的主因，不是“扫描慢”，而是“根本没必要扫”。只要项目纯用 PSR-4（Laravel、Symfony 等现代框架默认如此），classmap 就是冗余的。
- 在
composer.json中确保："optimize-autoloader": false且"classmap-authoritative": false（或直接删掉这两项） - 检查所有 vendor 包的
composer.json，确认无"autoload": {"classmap": [...]}配置（极少数老包可能带，可手动 patch 或换 fork） - 执行
composer install --no-autoloader后，再运行composer dump-autoload --no-dev，只生成 PSR-4 映射，跳过全量文件遍历
绕过 Windows Defender / WSL NTFS 路径扫描（Windows+WSL 必做）
即使禁用 classmap，composer install 解压 ZIP 阶段仍会被 Defender 逐个扫描每个 .php 文件——尤其路径含中文时更易触发深度检测，单次解压卡顿可达分钟级。
- PowerShell（管理员）执行：
Set-MpPreference -ExclusionPath "D:\myproject"（把项目根目录加进 Defender 排除） - 避免用
--prefer-source：它会触发 Git clone + checkout，比 ZIP 解压多出数倍文件操作和路径遍历 - WSL2 用户务必把项目放在
/home/xxx/（ext4 原生分区），而非/mnt/d/（NTFS 挂载点）；opendir()在后者上对深度嵌套目录可能单次耗时 >150ms
清理缓存中 vcs 和小文件 inode 杀手（磁盘/Inode 双满时优先处理）
cache/vcs/ 目录是隐形空间黑洞：每个 Git 包一个裸仓库，平均占 200–800MB，含数万个对象文件——它不占大块空间，但吃光 inode 后，No space left on device 错误就来了。
- 全局禁用：
composer config --global cache.vcs false（此后所有包强制走--prefer-dist） - 安全删除已有 vcs 缓存：
rm -rf ~/.composer/cache/vcs/（Linux/macOS）或rd /s /q "%APPDATA%\Composer\Cache\vcs"（Windows） - 别碰
cache/repo/：删了会导致首次composer update卡住拉元数据；cache/files/和cache/archives/可放心交由composer clear-cache处理
真正卡住的从来不是“扫描逻辑”，而是操作系统层面对大量小文件的路径解析与安全策略干预。优化方向永远是「绕过扫描」，而不是「加速扫描」——classmap 关掉、Defender 排除加好、vcs 缓存清干净，三步做完，vendor 目录从“不敢碰”变成“秒装”。
