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