RecursiveDirectoryIterator 报错主因是权限不足或路径不可达，常见于 Linux/macOS 下 sudo composer 留下的 root 权限文件、Docker UID 不匹配、open_basedir 限制或插件缓存干扰，需依序检查 vendor 所有权、容器用户映射、PHP 配置及禁用插件验证。
RecursiveDirectoryIterator 报错通常是因为权限不足或路径不可达
这个错误不是 Composer 本身的问题，而是 PHP 底层在调用 RecursiveDirectoryIterator 扫描 vendor 或缓存目录时被系统拒绝访问。常见于 Linux/macOS 下非 root 用户执行 composer install 或 composer update 后残留了 root 权限的文件，或者 Docker 容器内用户 UID 不匹配。
检查并修复 vendor 目录权限（最常见原因）
先确认当前用户能否读写 vendor/ 和 composer.lock 所在目录：
- 运行
ls -ld vendor，看 owner/group 是否为当前用户；若显示root，说明之前用sudo composer执行过 - 执行
sudo chown -R $USER:$USER vendor/（Linux/macOS）重置所有权 - 避免再用
sudo composer—— Composer 设计上不需 root 权限，强行使用只会污染文件权限 - 如果项目在 Docker 中，确保容器内运行 Composer 的 UID 与宿主机挂载目录的 owner 一致（例如加
--user $(id -u):$(id -g)）
禁用递归扫描缓存（临时绕过问题）
当权限修复困难（如共享 CI 环境），可跳过 Composer 对本地缓存的深度校验：
- 设置环境变量禁用缓存：
COMPOSER_CACHE_DIR=/dev/null composer install - 或清空并重建缓存：
composer clear-cache && composer install - 注意：这不会解决根本权限问题，仅适用于 CI/CD 流水线等一次性场景
PHP 配置限制导致 RecursiveDirectoryIterator 失败
极少数情况是 PHP 的 open_basedir 或 disable_functions 拦截了目录遍历操作：
- 检查
php -i | grep open_basedir，若输出非no value，确认路径是否包含项目根目录 - 运行
php -r "new RecursiveDirectoryIterator('.');"看是否直接报错 —— 若报错且非权限相关，则是 PHP 运行环境受限 - 这类问题多见于虚拟主机或老旧 PaaS 平台，需联系运维调整配置或换环境
composer install --no-cache --no-plugins
这条命令能快速验证是否由插件或缓存引发的递归迭代异常 —— 它跳过所有扩展逻辑，直通核心安装流程。如果此时不再报 RecursiveDirectoryIterator 错，说明问题出在某个插件或缓存钩子上，可逐个禁用排查。
真正棘手的是权限和 UID 混乱交叉的情况，比如在 WSL、Docker、NAS 挂载卷中反复切换用户，这时候 chown 可能无效，得结合 stat vendor 和 id 对照查看实际生效的 UID/GID。
