脚手架必须用 create-project 而非 init，因后者仅生成空 composer.json，无法提供开箱即用骨架（如 public/、artisan、.env.example 及自动初始化逻辑）；create-project 可拉取 type 为 "project" 的模板包，执行 post-create-project-cmd 脚本完成密钥生成、环境文件复制等。
脚手架必须用 create-project，别碰 init
新建项目不是写库，不需要从空 composer.json 开始填。你真正要的是一个开箱即用的骨架：带 public/、artisan、.env.example 和自动执行的初始化逻辑——这些 init 绝对给不了。
-
create-project会拉取整个模板包（比如myteam/skeleton），解压目录、安装依赖、运行post-create-project-cmd脚本（生成密钥、复制环境文件等） -
init只输出 10 行 JSON，之后还得手动配 autoload、require 框架、建 Git 仓库、设 Web 根目录——多数人卡在第二步 - 内部模板包的
type必须设为"project"，否则create-project不认它为可实例化骨架
post-create-project-cmd 脚本必须放在模板包的根级 composer.json
这个钩子只在新项目生成后、首次进入其目录时触发，且只认顶层 scripts 下的 post-create-project-cmd 字段（全小写，不能驼峰，不能漏短横线）。
- 脚本工作目录是新建项目根目录（如
myapp/），不是模板源码目录，所以路径别写../template/src - 避免交互式操作（如
readline()），CI 环境下会卡住；改用预设值或环境变量注入 - 常见任务：复制
.env.example→.env、运行php artisan key:generate、清空.git并重新 init（避免继承模板仓库历史）
私有模板包必须正确配置 repositories 和 type
团队内部脚手架通常托管在私有 Git 仓库（如 GitLab 或 GitHub Enterprise），不声明 repositories，create-project 就找不到包。
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
-
repositories必须写在使用方的composer.json（不是模板包自己的），且type设为"vcs"，URL 用 HTTPS 或 SSH 地址 - 若模板只有
dev-main分支，需显式加--stability=dev参数，否则默认只搜stable - 国内访问慢？临时切回官方源：
composer config -g repo.packagist composer https://packagist.org，别长期依赖镜像——私有包往往不在镜像中同步
脚手架模板本身要固化团队基建契约
模板包的 composer.json 不是“示例”，而是团队开发环境的起点契约。它必须自带不可绕过的约束：
-
"minimum-stability": "stable"+"prefer-stable": true，防止新项目一上来就引入@dev包 -
"autoload"严格按 PSR-4 声明，如"MyTeam\App\": "app/"，禁用files或classmap -
"config"中预置"sort-packages": true和"allow-plugins"白名单（如"phpstan/extension-installer"），防插件失控 -
"php"版本约束写在require下（如"php": "^8.2"），不用platform—— 后者在 CI 中易被忽略
复杂点不在命令怎么敲，而在于模板包是否真把 composer.json 当契约来维护。每次 create-project 都是在签一次约，合约内容错了，后面所有环境一致性都无从谈起。
