Composer安装成功需三步冒烟测试：空目录下composer init生成composer.json；composer install安装monolog/monolog等最小包；验证vendor/autoload.php是否自动生成。
Composer 安装成功 ≠ 项目能跑起来。光看 composer --version 输出版本号，只说明二进制文件在 PATH 里，不说明 PHP 环境、网络、缓存、autoload 或依赖解析链路通不通。
怎么快速确认 Composer 基础链路跑得通
别只信 composer --version，它绕过了真实执行环境。真正冒烟测试要走三步：
- 在空目录下运行
composer init，全程回车默认，看是否能生成composer.json；卡在 “Package name” 或报Could not load package，基本是网络或镜像源问题 - 紧接着跑
composer install，哪怕只装一个最小包（如monolog/monolog）；失败时注意报错类型：mkdir(): Permission denied是缓存目录无写权限，command not found: php是 PHP 没进 PATH - 检查是否生成了
vendor/autoload.php—— 它不是手动补的，是install过程中自动生成的；没这文件，说明流程中断，重来前先删掉整个vendor/和composer.lock
验证 composer.json 配置有没有硬伤
composer validate 是唯一官方校验命令，但它默认只查 JSON 语法和字段结构，不联网、不解析依赖、不验 PHP 版本兼容性。
- 基础校验：直接运行
composer validate，报错会带精确行号列号（如line 12 at column 5），常见元凶是末尾逗号、中文引号、BOM 头（可用xxd composer.json | head查） - 必须加
--strict：否则拼错字段名（如requre）、用非 SPDX 的 license（如"MIT License"）、写错 type（如"libary"）都不会报错 - CI/CD 中建议组合使用：
composer validate --strict --no-check-publish（跳过 Packagist 发布检查，防网络超时） +composer install --dry-run（真做依赖求解，但不写文件）
为什么 validate 通过了，install 却失败
因为 validate 不干这些事：不查包是否存在、不验版本约束是否合法（如 "monolog/monolog": "999.0.0"）、不判断 "php": ">=8.0" 在当前 PHP 环境下是否满足。
- 真正暴露依赖问题的是
composer install --dry-run或composer update --dry-run，它们会启动完整依赖求解器，模拟全过程 - 私有包名写成
"myorg/mylib"却没配repositories？validate沉默，install --dry-run才报Could not find package - 改过
composer.lock手动？validate不感知，要用composer validate --lock校验 lock 与 json 是否一致
vendor 文件完整性怎么确认
Composer 默认不校验已安装包的文件是否被删或损坏。你删了 vendor/foo/bar/src/Helper.php，install 不报错，直到运行时报 Class not found。
- 没有内置命令能“扫描 vendor 所有文件并比对 hash”，
composer install --dry-run只看 lock，不读磁盘内容 - 可靠做法永远是删掉整个
vendor/目录，再跑composer install—— 所有文件从composer.lock重建，这才是唯一可信的完整性验证 - 空文件夹（如
vendor/bin/下啥都没有）通常不是异常，而是对应包没声明bin配置，或用了--no-bin-links
最常被忽略的一点：每次改完 composer.json，顺手跑一遍 composer dump-autoload -o，不然 autoload 映射可能还是旧的，类加载错误会误导你去怀疑依赖本身。
