刚初始化的项目如何生成composer.json？Composer init向导带你快速起飞
直接运行 composer init 确实能快速生成一份基础的 composer.json 文件，但这里有个常见的“陷阱”：交互式向导过程中，如果填错或漏填了某些关键字段（比如 autoload 或 require-dev），很容易导致后续的自动加载失败，或者测试依赖压根不生效。
为什么 composer init 填完还报错 “Class not found”？
这个问题困扰过不少开发者。核心原因往往出在向导进行到 Autoloading 这一步时，很多人习惯性地直接按了回车跳过。结果呢？生成的 composer.json 里压根没有 "autoload" 配置区块，PHP 自然找不到你的类文件，报错也就成了必然。
- 正确的做法是，在向导询问时，必须手动选择
psr-4标准，并准确填写命名空间与目录路径的映射关系，例如"App\": "src/"。 - 这里有个细节需要注意：如果你的代码都放在
src/目录下，但配置时手误写成了"App\": "app/"，那么即便之后执行了composer dump-autoload，类加载依然会失败。 - 所以，填完所有信息后先别急着退出，最好立刻检查一下生成的
composer.json文件，确认里面是否包含了完整的"autoload"和"autoload-dev"配置区块。
如何跳过向导、用命令行一次性生成最小可用配置？
对于需要在 CI 流程中初始化项目，或者追求脚本化、避免人工交互出错的场景，其实有一条命令就能搞定。关键在于把所有必要的字段通过参数一次性传递进去：
composer init --name="myvendor/myproject" --description="My awesome project" --type="project" --license="MIT" --homepage="https://example.com" --require="php:^8.1" --autoload="psr-4:App\:src/" --no-interaction
这里有几个技术要点：--autoload 参数的值格式是 规则:命名空间:路径，各部分之间用英文冒号分隔。另外，在 Shell 中书写时，命名空间的反斜杠需要转义，所以要写成两个 。最后，--no-interaction 这个开关至关重要，它能确保命令直接执行完毕，而不会中途停下来等待人工输入。
composer init 生成的 require-dev 为什么没包含 phpunit？
这其实是个理解上的偏差。向导在列举开发依赖时，确实会把 phpunit/phpunit 作为一个常用示例展示出来，但它并不会自动帮你添加进去——它的角色是帮你填空，而不是替你决定项目该用什么依赖。
- 如果你确实需要添加测试框架，必须在向导询问
Which packages would you like to require for development?时，手动输入phpunit/phpunit:^10这样的完整包名和版本约束。 - 输入时也得留神，如果版本号写错了（比如在 PHP 8.2 环境下却指定了
^9.6版本），后续执行composer install时就会因为版本冲突而失败。 - 因此，一个更稳妥的流程是：先用
composer init生成项目骨架文件，之后再单独执行composer require --dev phpunit/phpunit:^10来引入测试依赖，这样步骤更清晰，也不容易出错。
话说回来，生成 composer.json 文件本身并不复杂，真正的麻烦在于 autoload 的路径和命名空间映射关系。这个配置一旦写错，错误往往不会立刻暴露出来，而是要等到你第一次尝试 new App\SomeClass() 时才会突然崩溃。所以，生成配置后的第一件事，不是继续写业务代码，而是务必立即执行 composer dump-autoload -o，并亲自验证一个最简单的类文件能否被成功加载。这才是避免后续连环坑的关键所在。
