composer init 是交互式向导而非一键创建，需严格按 vendor/name 格式填包名、带邮箱的 author、匹配环境的 minimum-stability 和 autoload 路径，否则导致 validate 失败、autoload 失效或 install 报错。
直接运行 composer init 就能生成 composer.json，但别盲目回车
它不是“一键创建”，而是交互式向导——每一步填错，后面都可能白干。比如 Package name 必须是 vendor/name 格式（如 myorg/myapp），漏掉 vendor 段或写成 myapp，后续发布包、autoload 映射、甚至某些 CI 工具都会报错。
- Author 字段必须带邮箱，格式为
John Doe <john></john>；只写名字或用中文邮箱（如张三@163.com）会导致composer validate失败 -
Minimum Stability默认是stable，没问题；但如果你项目要依赖dev-main分支的包，得手动改成dev，否则composer require会拒绝安装 - 填完所有项后，Composer 会预览最终的
composer.json内容——这是唯一一次检查机会，输no可重来，输yes就写盘，不可撤回
非交互模式初始化：适合脚本、CI 或快速验证
想跳过问答？--no-interaction 是必须的，但它不接受“半参数”：缺任何一个必需字段（如 --name、--author），命令直接失败，不会给你默认值。
- 最小可用命令：
composer init --no-interaction --name="myorg/myapp" --author="Me <me>"</me> - 加依赖要拆开写：
--require="php:^8.1" --require="guzzlehttp/guzzle:^7.8"，不能合并成一个字符串 - 如果项目已有
src/目录且用App\命名空间，建议顺手加上 autoload：--autoload="psr-4:App\=src/"，否则后续要手动改composer.json
在老项目里运行 composer init 的真实代价
它不会扫描你已有的类或文件，也不会自动推断 PHP 版本要求。你填的 minimum-stability、autoload、require 全靠自己判断——填错一个，composer install 可能装错版本，或导致 class not found。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 老项目 PHP 版本低（比如 7.4），但误填了
--require="php:^8.1"，composer install会直接报错退出 - 没配
autoload，哪怕composer install成功，require 'vendor/autoload.php'也加载不了你自己的类 - 如果项目目录结构不标准（比如类在
lib/而非src/），交互式流程里选 PSR-4 后填错路径，autoload 就失效
composer init 不该做的事：别指望它帮你选包、定版本、查兼容性
它只是 JSON 生成器，不是依赖分析工具。输入 monolog/monolog，它不会告诉你当前 PHP 版本是否支持 ^3.0，也不会提醒你 phpunit/phpunit:^9.0 和 php:^8.3 是否冲突。
- 版本约束别乱打
*或dev-main：生产环境应优先用^2.0这类语义化版本 - 开发依赖（
require-dev）和运行依赖（require）别混填：比如把phpunit写进require，上线时会多装一堆无用包 - 生成完立刻跑：
composer validate检查语法，composer install验证能否真正落地——这两步卡住，90% 是 init 时某项填错了
最常被忽略的是 autoload 配置和 PHP 版本约束的匹配性：init 时填了 PSR-4 映射，但没确认命名空间是否真和文件结构一致；写了 php:^8.2 却忘了服务器还是 8.1——这种细节不现场验证，上线前才暴露，就晚了。
