应使用 composer create-project laravel/laravel my-app 创建 Laravel 项目，它直接拉取完整可运行骨架，自动配置 autoload、生成 .env 和 APP_KEY、初始化 vendor；而 composer init 仅生成空配置，易致 Class not found、依赖不一致或扩展缺失等隐形错误。
别用 composer init 初始化新项目，直接上 composer create-project。它不是“多一个选项”，而是面向应用项目的正确起点——init 生成空配置，create-project 拉的是可运行骨架，自带 autoload、.env、key 生成、vendor 初始化，一步到位。
为什么 composer init 容易失败又难调试
它卡在作者格式（John Smith <john></john>）只是表象，真正的问题是：生成的 composer.json 默认没写 autoload，也没声明 PHP 版本约束，更不校验扩展。结果就是：
- 类文件放对了位置，
new AppHttpController()仍报Class not found - 本地装的
guzzlehttp/guzzle是 v7.8，CI 上install却拉到 v7.5，因没composer.lock或版本范围太宽 - 你手动
git cloneLaravel 仓库再composer install，失败提示ext-pdo_mysql missing——但create-project会在下载前就检查并报错
这些都不是网络或权限问题，是初始化方式选错了。
composer create-project 的实操要点
它本质是「远程模板 + 本地安装」的原子操作，不是下载完再跑 install。关键参数和陷阱：
立即学习“PHP免费学习笔记（深入）”；
- 必须指定完整包名：
composer create-project laravel/laravel myapp，不能只写laravel - 加
--prefer-dist强制走压缩包而非 git clone，避免网络中断或 SSH 权限问题 - 加
--no-interaction跳过交互（适合 CI），但得提前确认目标包支持无参初始化 - 若要指定 PHP 版本兼容性，不是改命令，而是在目标骨架的
composer.json里已声明"php": "^8.1"——你拉的是别人验证过的环境
执行后，你会立刻得到一个带 vendor/autoload.php、.env、artisan（Laravel）或 think（ThinkPHP）的完整目录，不是一堆待填坑的 JSON 字段。
什么情况下才该用 composer init
只有一种场景：你要发布一个别人 require 的库，不是自己跑的 Web 应用。比如写个通用的身份证校验工具、CLI 命令行小工具、或私有 SDK。
- 运行
composer init后，务必把type设为library，不是默认的project -
autoload必须配，哪怕只有一行："psr-4": {"MyLib\": "src/"}，末尾双反斜杠和斜杠都不能少 - 类路径必须严格匹配命名空间：
MyLibValidatorIdCard→src/Validator/IdCard.php，大小写敏感 - 本地测试用
composer dump-autoload+php -r 'new MyLibValidatorIdCard();'，不报错才算结构过关
应用项目里硬套 init，等于把汽车引擎拆下来手装——不是做不到，但每颗螺丝都得自己校验扭矩。
最常被忽略的一点：无论用哪种方式，vendor/autoload.php 的引入路径必须基于入口文件位置动态计算。放在 public/index.php 就得写 require __DIR__.'/../vendor/autoload.php';，而不是想当然的相对路径。这点在部署到 Nginx 或 Apache 子目录时，会直接导致白屏且无日志。
