composer init 共问7个问题，仅name（须vendor/name格式）和description关键，require可空，其余如author、homepage等留空更安全；跳过交互可用--no-interaction参数、手写最小JSON或复制修改。
composer init 会问什么，哪些可以跳过
执行 composer init 就是交互式生成 composer.json，它一共问 7 个问题，但多数可直接回车跳过。关键字段只有 name（推荐填）、description（建议写一句用途）、require（依赖项，可空着后续手动加）。其他如作者邮箱、关键词、homepage、type，默认留空完全不影响使用。
常见错误是强行填满所有项，结果填了不存在的包名或错乱的版本约束，导致后续 composer install 报错 Could not find package xxx。
-
name：格式必须是vendor/name（如myorg/mytool），不能只写mytool，否则发布到 Packagist 会失败 -
require那步输入php: ^8.1是合法的，但别输成php >=8.1—— Composer 不识别这种写法，会静默忽略 - 如果项目不打算发布，
author和homepage留空最安全，避免日后泄露内部信息
不交互生成 composer.json 的三种可靠方式
想跳过提问直接生成，有且只有三种实用路径：用 --no-interaction + 参数预设、手写最小化 JSON、或从已有项目复制改写。别信“一行命令全自动”的脚本，它们往往硬编码了 PHP 版本或 license，反而埋坑。
最稳的是手写基础结构：
{
"name": "myapp/cli-tool",
"description": "A simple CLI utility",
"type": "project",
"require": {},
"autoload": {
"psr-4": {
"App\\": "src/"
}
}
}
-
"type": "project"表示这是最终应用，不是可复用的库；写成library会导致某些工具（如 GitHub Dependabot）误判依赖关系 -
"autoload"块不加也行，但一旦开始写类，立刻补上，否则composer dump-autoload找不到文件 - 别在
require里提前写死 dev-only 包（如phpunit/phpunit），它们该进require-dev
为什么 vendor 目录没生成，或者 autoload 失效
生成 composer.json 后不等于项目就“就绪”了。composer install 才真正拉取依赖并生成 vendor/autoload.php。如果跳过这步，require 'vendor/autoload.php' 必然报错 failed to open stream。
- 首次运行
composer install时，若composer.json里require为空，vendor/仍会创建，但里面只有composer/自身目录 —— 这是正常现象，不是失败 - 修改
composer.json后必须再跑一次composer install或composer update，否则变更不生效 - 如果用了
autoload.psr-4但类还是找不到，检查路径是否拼错："App\\": "src/"意味着App\Foo必须放在src/Foo.php，而不是src/App/Foo.php
Windows 下 composer init 中文路径或空格报错怎么办
在中文目录或含空格的路径（如 C:\Users\张三\my project）下运行 composer init，常卡在 “Package name” 步骤或生成错误的 name 字段。根本原因是 Composer 内部调用某些 shell 工具时未正确转义路径。
- 最简解法：cd 到纯英文无空格路径下再执行，比如
D:\work\myapp - 不要试图用引号包裹路径来“修复”，
composer init --working-dir "C:\Users\张三\my project"依然大概率失败 - 如果必须在中文路径开发，跳过
init，直接手写composer.json（参考上面第二段），然后composer install即可，完全绕过交互环节
复杂点在于：Composer 对路径的容忍度取决于底层 PHP 环境和 Windows 版本，同一份 composer.json 在 WSL 里能跑，在原生 CMD 里可能 autoload 失败 —— 这种差异往往被忽略，直到换环境部署才暴露。
