用 composer create-project 创建项目最快，但会覆盖本地 composer.json 且不初始化 Git 仓库；它克隆完整项目骨架并安装依赖，与当前目录无关，仅支持 type="project" 的包。
直接说结论：用 composer create-project 创建项目最快，但默认行为会“删掉”你本地已有的 composer.json，且不自动初始化 Git 仓库——这两点最容易踩坑。
create-project 和 require 的本质区别
很多人误以为 create-project 就是 “带安装的 require”，其实它干的是另一件事：从指定包（比如 laravel/laravel）的最新稳定版中，把整个项目骨架「克隆+安装依赖」下来，然后清空原 .git 目录（防冲突），再执行一次 composer install。
它不往你当前目录装包，而是新建一个目录；也不读取你当前的 composer.json，哪怕你在项目根目录下运行，它也会无视并覆盖。
-
composer require foo/bar：往现有项目加依赖，改当前composer.json和vendor/ -
composer create-project foo/bar myapp：拉一个完整新项目到myapp/，和当前目录完全无关
常用参数与避坑组合
默认命令如 composer create-project laravel/laravel blog 看似简单，但实际开发中几乎总要加参数：
-
--stability=dev：拉dev-main或dev-develop分支（Laravel 11 默认只发 stable，想试新特性必须加） -
--remove-vcs：删掉模板自带的.git（推荐加，避免后续git init出错） -
--no-interaction：CI/脚本里必加，否则卡在 “Do you want to remove the existing VCS?” 提示 -
--prefer-dist：优先下 zip 包而非 git clone，快且干净（默认已启用，不用显式写）
典型安全组合：composer create-project laravel/laravel blog --stability=dev --remove-vcs --no-interaction
为什么有时提示 “Could not find package”？
不是网络问题，常见原因就三个：
- 包名拼错，比如写成
laravel/framework（这是组件，不是可创建的项目模板） - 没加版本约束，而该包最新版是
dev，但你的 Composer 全局minimum-stability是stable（此时加--stability=dev就行） - 包本身没声明
"type": "project"—— 这是关键。只有 type=project 的包才被create-project认可，否则报错或静默失败
查一个包是否支持：composer show vendor/name | grep type，输出含 project 才能用 create-project。
自定义模板项目怎么让它支持 create-project？
如果你自己维护一个项目模板（比如公司内部 PHP 脚手架），只需两步：
- 在
composer.json里加："type": "project" - 确保根目录有
index.php、public/或其他典型入口结构（非强制，但用户预期如此）
不需要写任何额外脚本或钩子。create-project 只认 type 字段，识别后自动执行 install 流程。发布时打个 tag（如 v2.0.0），别人就能用 composer create-project yourorg/my-scaffold myapp v2.0.0 拉指定版本。
最常被忽略的一点：create-project 不会执行你 scripts 里的 post-root-package-install，除非你手动加 --no-scripts 再手动跑——但它默认是跳过的。想自动初始化配置？得靠 post-create-project-cmd 钩子，且必须在模板的 composer.json 里明确定义。
