Composer安装失败主因是PHP版本、依赖冲突或稳定性设置不匹配；require为运行时依赖，require-dev仅开发期使用；autoload失效多因PSR-4路径配置错误或未执行dump-autoload。
composer require 安装失败：找不到包或版本冲突
最常见的情况是 composer require vendor/name 报错，比如 Could not find package 或 Your requirements could not be resolved。本质不是命令写错了，而是当前项目 PHP 版本、已装包、composer.json 中的 minimum-stability 或 prefer-stable 设置和目标包不匹配。
- 先确认包名拼写正确，去 packagist.org 搜一下，看是否真存在，且支持你用的 PHP 版本（页面右上角会标
PHP ^8.0这类） - 如果包是
dev-开头的开发版，而你没设"minimum-stability": "dev"，就会被跳过；临时解决可加--stability=dev参数 - 已有包锁定了旧版本（如
"monolog/monolog": "^1.0"），而新包依赖^2.0，Composer 就会拒绝安装——这时得手动升级冲突包，或删掉composer.lock和vendor/重装（仅限开发环境）
require 和 require-dev 的区别不是“要不要用”，而是“什么时候装”
require 是运行时必需的，比如 guzzlehttp/guzzle 发 HTTP 请求；require-dev 是开发期才需要的，比如 phpunit/phpunit 或 friendsofphp/php-cs-fixer。关键影响在部署：
- 线上执行
composer install --no-dev时，require-dev下的包根本不会下载，省空间也少风险 - 但如果你在
src/里写了use PhpCsFixerFinder;并且没做条件加载，运行时就会报Class not found——因为这个类只在require-dev里 - CI 脚本里漏了
--no-dev，可能把测试工具打到生产镜像里，白占几十 MB
autoload 自动加载不生效：命名空间、路径、PSR-4 对不上
自己写的类放进 src/ 后，new AppServicesUserService() 报错 Class not found，大概率是 composer.json 里 autoload 配置没对齐。
- 检查
"psr-4": {"App\": "src/"}—— 注意末尾斜杠不能少，App\的双反斜杠是 JSON 里转义必须的 - 确保文件路径和命名空间严格对应：
src/Services/UserService.php→namespace AppServices; - 改完
composer.json必须跑composer dump-autoload，否则 Composer 还按旧映射找 - 如果类在
lib/或helpers/这种非标准目录，用files类型加载更直接："autoload": {"files": ["helpers/functions.php"]}
第三方类库引入后 Class not found：别急着重装，先查 autoload_files.php
明明 composer require foo/bar 成功了，vendor/foo/bar/src/Helper.php 也存在，但 new FooBarHelper() 还是报错。问题常出在包本身没配 autoload，或用了自定义加载逻辑。
- 打开
vendor/composer/autoload_files.php，搜包名，看有没有注册它的文件——没有就说明它没声明自动加载方式 - 去该包的
composer.json（在vendor/foo/bar/下）里看autoload字段，有些老包只写"classmap": ["src/"]，需运行composer dump-autoload才生成映射 - 极少数包（比如某些 WordPress 插件）根本不走 Composer 加载，得手动
require_once或用files方式引入
new 都会跪；而 require-dev 和 --no-dev 的配合稍有疏忽，就可能让测试代码混进生产环境。这些地方不报语法错误，但运行时才暴露，查起来特别费时间。 
