composer create-project 装 laravel 卡在「resolving dependencies」大概率因未关闭 packagist 镜像或缺失 ext-opcache/ext-pdo_sqlite 扩展；需用 php -m 确认扩展启用，并临时禁用镜像或换为有效国内源。
composer create-project 装 Laravel 为什么卡在「Resolving dependencies」？
不是网络慢，大概率是没关 Packagist 镜像或 PHP 扩展缺失。Laravel 10+ 默认依赖 ext-opcache 和 ext-pdo_sqlite，缺一个就会让依赖解析拖长到几分钟甚至超时。
- 先运行
php -m | grep -E "opcache|pdo_sqlite"确认扩展已启用 - 临时禁用镜像：加
-d repos.packagist.org=packagist.org参数，比如：composer create-project laravel/laravel myapp --no-interaction -d repos.packagist.org=packagist.org
- 如果用国内镜像，别用过期的
https://packagist.phpcomposer.com（已停），换成https://packagist.laravel-china.org或阿里云源
laravel new 和 composer create-project 选哪个？
laravel new 是个封装脚本，本质还是调 composer create-project，但它会自动执行 npm install、生成密钥、设好 storage 权限——只适合本地快速启动。
- 开发机上图省事，用
laravel new myapp没问题 - CI/CD 或 Docker 构建环境里，必须用
composer create-project，否则laravel new会尝试访问外部 npm registry，容易失败 -
laravel new默认装最新稳定版；create-project可指定版本，比如：composer create-project laravel/laravel myapp "9.*"
部署时 composer install 报错「class not found」或「autoload.php missing」
不是代码问题，是没跑 composer install --no-dev --optimize-autoloader，或者没清掉 vendor 目录残留。
- 上线前务必删干净旧
vendor/和composer.lock（除非你确定 lock 文件和当前环境匹配） -
--no-dev不只是省空间，还能避免phpunit等开发依赖引发的 autoloader 冲突 - 如果用 Laravel Octane，还要额外加
--classmap-authoritative，否则热重载可能找不到新类 - 检查
autoload段是否误删了"psr-4": {"App\": "app/"}—— 这个漏掉就真找不到AppHttpControllers...
PHP 版本不匹配导致 composer install 失败
Laravel 10 要求 PHP 8.1+，但错误信息往往藏在日志深处，只显示「Your requirements could not be resolved」，实际是 PHP 版本被 platform 配置锁死了。
- 看
composer.json里有没有"config": {"platform": {"php": "8.0.0"}}—— 这是人为降级，删掉或改成匹配的版本 - 用
php -v和composer show php对比真实版本和 Composer 认为的版本，后者可能受platform干扰 - Docker 部署时，别只改
Dockerfile的 FROM，还要确认composer install命令跑在同一个 PHP 环境下，否则容器内 PHP 版本和宿主机不一致会静默失败
--no-dev 或一个没删干净的 vendor。Laravel 本身不复杂，Composer 的隐式行为才是真坑。 
