应使用 composer create-project 初始化 laravel 项目，它完整拉取骨架、安装依赖、执行脚本并生成环境；而 laravel new 因封装过深、版本滞后、调试困难已被官方弃用。
直接用 composer create-project 拉模板，别碰 laravel new
官方已明确不推荐用 laravel/installer（即 laravel new），它封装过深、版本滞后、PATH 和 symlink 问题频发，出错时连 Composer 日志都看不到。真实项目初始化必须走 composer create-project，这是唯一能完整复现骨架 + 依赖 + 脚本钩子 + 环境初始化的路径。
create-project 命令必须带全三个参数
命令格式固定为：composer create-project <package><directory><version></version></directory></package>，三者缺一不可——漏掉 <version></version> 可能拉到预发布版（如 11.x-dev），漏掉 <directory></directory> 会让 Composer 尝试推导目录名，但在 Windows WSL 或 Docker 挂载卷里常因权限失败。
-
<package></package>必须是完整包名，如laravel/laravel；支持 Git URL（git@github.com:myorg/my-laravel-starter.git）或本地路径（../templates/laravel-11-base） -
<directory></directory>目标文件夹不能已存在，否则直接报错退出（不会覆盖） -
<version></version>必须用引号包裹，如"11.*"或"^11.0"；写成11.*（无引号）会被 shell 当作通配符展开，大概率匹配到当前目录下的文件，而非 Laravel 版本
加这几个选项才能跑得稳
默认行为在 CI/CD、Docker 构建或国内网络下极易卡住或出错，每次都要显式加：
-
--no-interaction（简写-n）：跳过 Git 凭据输入、是否初始化仓库等所有交互，否则可能永远挂住 -
--prefer-dist：强制从压缩包安装（比 Git clone 快且稳定），尤其适合自动化流程 -
--remove-vcs：删掉模板自带的.git目录，避免新项目继承错误历史 -
--no-scripts：调试模板时有用，可先禁用post-create-project-cmd（如自动生成.env），确认模板结构无误后再启用
典型命令：composer create-project laravel/laravel myapp "11.*" --no-interaction --prefer-dist --remove-vcs
装完不是结束，立刻验证三件事
常见静默失败点根本不会报错，但后续 php artisan 全挂：
- 检查
vendor/autoload.php是否存在且可读——Windows WSL 或 Docker volume 挂载时，Composer 可能跳过 symlink 步骤导致缺失 - 运行
php artisan tinker，能进入交互式控制台才代表 autoloader 和基础命令链正常 - 确认
.env有内容且APP_KEY已生成（create-project默认会执行key:generate，但加了--no-scripts就不会）
如果 vendor/autoload.php 不存在，别直接 composer require 补依赖——这会破坏 Laravel 骨架预设的 autoload 规则和脚本钩子。应进项目目录执行 composer install --no-interaction，再手动补密钥：php artisan key:generate。
