composer init 仅生成基础 composer.json 文件，不安装依赖、不初始化 Git、不生成源码；需手动补 autoload、删无用字段、确认 type 类型。
composer init 会生成什么文件
执行 composer init 的本质是交互式创建 composer.json，它不会自动安装依赖、不初始化 Git 仓库、也不生成任何源码文件。你得到的只是一个基础结构的 JSON 配置——仅此而已。
常见错误现象：运行完以为项目就“能跑了”，结果 composer install 报错，或 autoload 不生效，其实只是因为 composer.json 里没填 autoload 字段，或者 name 格式不合法（比如含空格或大写字母）。
-
name必须是vendor/package格式，如myorg/myapp；用myapp或MyApp会导致后续 packagist 发布失败 - 如果跳过
autoload设置，composer dump-autoload就不会生成映射，require类文件时直接报Class not found - 交互中选 “no” 跳过 license，字段会写成
"license": []，但 Composer 2.2+ 会警告并建议补全
跳过交互，用命令行参数快速初始化
手动敲十几次回车太慢，尤其 CI 或脚手架场景下，应直接用参数预设值。关键是把必须字段一次性给全，否则 composer init 仍会卡在某个提问上。
典型用法：
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
composer init --name=myorg/myapp --description="My CLI tool" --type=project --license=MIT --php=8.1 --require="monolog/monolog:^2.0"
注意点：
-
--require和--require-dev只接受vendor/package:version格式，不能写成"monolog/monolog": "^2.0"（引号和冒号位置错就会失败） -
--php设的是config.platform.php，影响依赖解析，不是简单注释；设成7.4却装了只支持 8.0+ 的包，install会静默降级或报错 - 如果当前目录已有
composer.json，init会提示覆盖，不会合并——想保留原有配置？别用init，直接手改或用composer config
初始化后立刻要做的三件事
刚生成的 composer.json 是“半成品”。不处理这三项，接下来大概率踩坑：
- 补
autoload：哪怕只是 PSR-4，也得写清楚命名空间和路径，例如："autoload": { "psr-4": { "MyApp\": "src/" } }，然后跑一次composer dump-autoload - 删掉无用字段：交互生成的
authors是数组，但如果你没填，可能留着空对象{}，某些校验工具（如 PHPStan + composer plugin）会报 schema 错误 - 检查
type：默认是library，但你建的是应用？得改成project，否则composer install --no-dev在部署时可能漏掉关键 bin 脚本
为什么有时候 composer init 报错“Could not find package…”
这不是网络问题，也不是包不存在，而是你在交互中输错了包名格式，比如：
- 输入
monolog/monolog ^2.0（中间有空格）→ 实际被当做一个包名，Composer 去 packagist 搜monolog/monolog ^2.0，当然 404 - 输入
monolog/monolog:^2.0但本地镜像源没同步最新数据（如私有 Satis），也会提示找不到——此时换composer clear-cache再试 - 用了带特殊字符的 vendor 名（如
my-org/my-app），而 packagist.org 不允许-在 vendor 段，会拒绝收录，但init本身不校验，直到你 push 到 packagist 才暴露
真正要验证包是否存在，别信 init 的提示，用 composer show monolog/monolog 或直接访问 https://packagist.org/packages/monolog/monolog
