最稳方式是明确指定包名、版本和路径并加--no-interaction等选项；create-project适用于创建完整项目骨架，require仅用于添加库。
直接用 composer create-project 创建项目模板，最稳的方式是明确指定包名、版本和安装路径，并禁用交互式提示——否则它可能卡在 Git 凭据输入或交互式配置上。
什么时候该用 create-project 而不是 require
当你需要一个完整可运行的项目骨架（比如 Laravel、Symfony Starter、或私有模板仓库），而不是单纯引入某个库时，create-project 才是正确选择。它会：
- 克隆整个仓库（或下载 dist 包），而非只安装依赖
- 执行
post-create-project-cmd脚本（如生成.env、清空缓存） - 自动初始化
vendor/和autoload.php，无需再跑composer install
如果只是加个 SDK 或工具包，用 composer require 更轻量。
create-project 必须传的三个参数
命令格式为：composer create-project <package><directory><version></version></directory></package>，三者缺一不可（除非用了别名或全局默认）：
-
<package></package>：必须是 Composer 包名（如laravel/laravel），支持vendor/name、Git URL（git@github.com:user/repo.git）、本地路径（../my-template） -
<directory></directory>：目标文件夹名，若不存在则创建；若存在且非空，命令会直接报错退出（不会覆盖） -
<version></version>：可以是分支名（dev-main）、标签（v2.1.0）、约束（^2.0）；省略时默认用stable版本，但可能不是你想要的最新版
示例：composer create-project laravel/laravel myapp "10.*"
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
关键选项：绕过交互、跳过脚本、控制源类型
默认行为容易卡住或执行冗余操作，这几个选项几乎每次都要加：
-
--no-interaction（简写-n）：跳过所有交互提示（尤其避免 Git SSH 密码卡住） -
--no-scripts：不执行post-create-project-cmd等脚本（调试模板时很有用，防止自动生成错误配置） -
--prefer-dist：强制从压缩包安装（更快、更稳定），比--prefer-source（克隆 Git）更适合 CI 或模板分发 -
--remove-vcs：删掉.git目录（新项目不该继承模板的提交历史）
常用组合：composer create-project -n --no-scripts --prefer-dist --remove-vcs laravel/laravel myapp "10.*"
私有模板和 Git 仓库的坑
用 Git URL 拉取私有模板时，常见问题不是权限，而是 Composer 默认走 HTTPS 协议，而你的 composer.json 中可能写了 SSH 地址（如 git@gitlab.com:group/template.git）。这时要：
- 确保本地已配置 SSH key 并能
ssh -T git@gitlab.com连通 - 在
composer.json的repositories中显式声明类型：{"type": "vcs", "url": "git@gitlab.com:group/template.git"} - 避免在命令行中混用协议：不要用
https://...URL 却期望 SSH 认证
另外，私有仓库若没打 tag，默认会装 dev-main，但 create-project 对 dev- 分支的支持不稳定，建议至少打一个 v1.0.0 tag。
真正麻烦的不是参数记不住，而是不同模板对 post-create-project-cmd 的实现五花八门——有的删 README.md，有的重写 composer.json name 字段，有的甚至硬编码了数据库 host。用之前最好先 --no-scripts 跑一遍，看清楚生成了什么再决定是否启用。
