失败是多个明确原因叠加的结果：目录非空、依赖解析失败、镜像源未切换、PHP版本不匹配、权限错误、Docker UID/GID不匹配等，需逐项排查。
失败不是偶然，而是几个明确原因叠加的结果。直接看报错信息里最关键的词，比盲目重试更省时间。
报错 Dir 'xxx' is not empty，目标目录非空
这是最常被误判为“权限问题”或“网络问题”的错误，实际就是 Composer 的硬性限制：它拒绝往已有文件的目录里写项目骨架。
从不覆盖、不跳过、不合并——它只接受一个空目录
用
或
完全无效，它们不参与“目录是否为空”的判断
真要复用当前目录里的
或
？别硬清空，改用
，装完再手动复制必要文件
如果目录里已有
，你根本不需要
，直接
就行
报错 Your requirements could not be resolved
本质是依赖解析失败，不是包不存在，而是当前环境和版本约束对不上。
先确认 PHP 版本：比如
（ThinkPHP 8）要求 PHP ≥ 8.1，
不达标就会卡在这里
镜像源没切对：国内默认连不上 packagist.org，执行
再清缓存
某些包（如私有仓库或 GitHub tag）需要额外配置
参数，不能只靠全局镜像
加
看具体卡在哪一行，常会暴露某个 dev 分支的约束冲突
卡在 Resolving dependencies 或一直不动
看起来像死锁，其实是 Composer 在后台暴力穷举兼容组合，尤其当
模板里 require 了十几个包且版本范围宽松时。
Composer 2.9.6
Composer 2.9.6 是 PHP 生态中高效、稳定的依赖管理工具。此版本在性能与兼容性上进一步优化，改进了依赖解析算法，提升大型项目中的安装与更新速度。它支持并行下载任务，显著减少等待时间，并增强了与私有仓库及镜像源的交互稳定性。同时修复了多项命令行交互与内存使用相关的缺陷，确保在复杂依赖关系下依然可靠运行。无论是新项目初始化还是现有系统维护，Composer 2.9.6 都能为开发者提供流畅、精准的依赖管理体验。
下载
不是网络问题，但容易被当成网络问题——先跑
，如果秒出结果，说明网络 OK，问题在依赖解析
换稳定版：不加版本参数时，
可能拉
，显式加
能大幅缩短耗时
Docker 场景下，挂载卷的 UID/GID 不匹配也会表现为“卡住”，用
启动容器再试
磁盘空间不足或
权限不对，会导致解压中途失败，日志里可能只显示 “failed to extract”，没有明确报错
Permission denied 或 Could not delete vendor/
composer
90% 是所有权错位，尤其是用
开头，后续就再也写不进去了。
查当前用户：
和
，再对比目标目录的
输出
修复命令：
，如果目录已半残，不如
彻底重来
在
这类系统路径操作？提前建空目录并授权：
Docker 中挂载宿主机目录时，必须用
指定 UID/GID，否则容器内 PHP 进程无法写入宿主机文件
真正难排查的，往往不是单个错误，而是多个条件叠加：比如目录非空 + 镜像源失效 + PHP 版本偏低。每次只改一个变量，用
看输出变化，比凭经验猜快得多。
composer create-project--remove-vcs--no-interaction.envconfig/composer create-project vendor/name ./new-dir --no-installcomposer.jsoncreate-projectcomposer installtopthink/thinkphp -vcomposer config -g repos.packagist composer https://mirrors.aliyun.com/composer/composer clear-cache--repository-vvvcomposer.jsoncomposer create-project laravel/laravel test --no-install -vvvcreate-projectdev-main--stability=stabledocker run -u $(id -u):$(id -g)/tmpsudo composer create-projectwhoamiid -uls -ld /path/to/dirchown -R $USER:$USER /path/to/dirrm -rf /path/to/dir/var/wwwsudo chown $USER:www-data /var/www/myapp && sudo chmod 775 /var/www/myapp-u-vvv