composer init 按固定顺序提问：Package name（vendor/name，小写+短横线）、Description、Author（name ）、Type（默认library）、License（SPDX ID）、Require/require-dev（包名+版本，逗号分隔）；可跳过交互用--name、--description等参数批量生成；默认不配置autoload，需明确回答PSR-4提示；生成后应运行composer validate验证，并注意config.platform.php以防环境不一致。
直接运行 composer init 就能交互式生成 composer.json，但默认行为容易踩坑——比如不设 autoload、忽略 PHP 版本约束、把开发依赖误写进生产依赖。
composer init 会问你哪些问题？
它按固定顺序提问，每步都影响最终文件结构。关键字段包括：
-
Package name：格式为vendor/name，必须小写字母+短横线，例如myorg/myapp；如果留空，会用当前目录名自动推导，但可能含非法字符（如大写、空格） -
Description：纯描述，不影响功能，但发布到 Packagist 必须填写 -
Author：格式为name <email></email>，邮箱不是必须，但建议填，否则后续composer validate会警告 -
Type：默认library，如果是可执行项目（如 CLI 工具），应改为project -
License：填MIT、GPL-3.0-or-later等 SPDX ID，别写 “Apache” 这种模糊值，否则composer validate报错 -
Require和require-dev：支持包名+版本号，如php: ^8.1或monolog/monolog: ^3.0；多个用逗号分隔，但注意不能混用空格和逗号（php:^8.1, monolog/monolog:^3.0✅，php: ^8.1 monolog/monolog: ^3.0❌）
如何跳过交互，用命令行参数自动生成？
适合 CI/CD 或批量初始化，避免手动输错。所有参数必须一次性给全，漏掉 --name 或 --description 会失败。
composer init --name="myorg/myapp" --description="My awesome app" --author="Alice <alice@example.com>" --type=project --license="MIT" --require="php:^8.1" --require="guzzlehttp/guzzle:^7.8" --require-dev="phpunit/phpunit:^10.4"
注意：--require 和 --require-dev 可多次使用，但每个只能跟一个依赖（即不能写 --require="php:^8.1 guzzlehttp/guzzle:^7.8"）。
为什么生成的 composer.json 缺少 autoload 配置？
composer init 默认不加 autoload，哪怕你答了 “yes” 给 “Do you want to define your main namespace?”，它也只在交互末尾提示 “Would you like to use PSR-4 autoloading?”，而这个选项是可选的——很多人直接回车跳过，结果生成的文件里没有 autoload 段。
使用约定式提交（Conventional Commits）生成标准化的 Git 提交信息。适用于以下场景： (1) 暂存更改时需要提交信息； (2) 审查 diff 时希望获得结构化摘要； (3) 编写 PR 描述或变更日志（changelog）条目； (4) 用户明确要求“为本次更改编写提交信息”。 该功能会分析已暂存/未暂存的 diff，并生成按类型（type）划分范围的提交信息。
补救方式只有手动编辑，或删掉 composer.json 重跑 init 并明确回答 yes 到 PSR-4 提问。常见写法：
{
"autoload": {
"psr-4": {
"MyApp\": "src/"
}
}
}
路径 src/ 必须存在，否则 composer dump-autoload 会报错 “Class not found”。命名空间末尾的反斜杠 \ 是必须的，少写会触发 PSR-4 解析失败。
生成后必须立刻验证和安装吗？
不用。但有两件事建议马上做：
- 运行
composer validate：检查 JSON 格式、license 合法性、字段缺失（如没name或description） - 运行
composer install前先确认 PHP 版本是否匹配require.php字段，否则会卡在依赖解析阶段，报错类似Your requirements could not be resolved to an installable set of packages. - 如果项目已有
vendor/目录，init不会清空它；但后续install会按新composer.json重建，旧包可能被删
最常被忽略的是 config.platform.php 的设置——当本地 PHP 版本高于线上时，不显式声明平台版本，composer install 可能装入不兼容的扩展（如 ext-gd 8.2+ 特性），上线就报错。
