vendor/autoload.php 未生效是因为 composer require 仅更新依赖而未刷新自动加载，需运行 composer dump-autoload 并确认包的 autoload 配置正确，必要时注册服务提供者和门面。
composer require 之后为什么 vendor/autoload.php 没生效？
不是没生效，是 Laravel 的自动加载机制没触发——composer require 只写入 composer.json 并更新 vendor/，但不会自动重生成类映射。Laravel 默认用 classmap 加载核心和部分扩展包，而新包若没声明 autoload 或未被扫描，就找不到。
- 执行
composer dump-autoload强制刷新自动加载（尤其加了自定义命名空间或本地包时） - 确认该包的
composer.json里有正确的autoload字段（如"psr-4": {"Foo\": "src/"}），否则 Laravel 不知道从哪找类 - 如果包只提供 Facade 或 Service Provider，别忘了在
config/app.php中注册providers和aliases（Laravel 5.5+ 的自动发现功能仅对声明了extra.laravel.dont-discover以外的包有效）
Laravel 项目中该用 --dev 还是直接 require？
取决于这个包是否参与运行时逻辑。很多开发者误把测试工具、代码生成器甚至 IDE Helper 当成“开发期才需要”，结果上线后报错。
- 运行时依赖（如
guzzlehttp/guzzle、spatie/laravel-permission）必须无--dev安装，否则线上环境composer install --no-dev会删掉它 -
--dev只适用于真正不进生产流程的工具：比如phpunit/phpunit、barryvdh/laravel-ide-helper、larastan/larastan - 一个简单判断：如果代码里写了
use或调用了它的类/函数，它就是运行时依赖
如何安全升级一个已安装的第三方包？
直接 composer update vendor/package 看似快，但容易忽略约束冲突和隐式副作用。Laravel 对版本敏感，尤其涉及 illuminate/* 组件的包。
- 先查包的 GitHub 主页或 Packagist 页面，看它是否明确标注支持当前 Laravel 版本（例如 Laravel 10 要求 PHP 8.1+，而某些老包只到 PHP 7.4）
- 用
composer why vendor/package查谁依赖它，避免升级后破坏链路 - 升级前删掉
vendor/和composer.lock是危险操作；应保留lock文件，用composer update vendor/package --with-dependencies控制范围 - 升级后务必跑一遍
php artisan config:clear && php artisan cache:clear，有些包会在服务启动时缓存配置或路由
为什么 composer install 在 CI 环境失败，但本地正常？
根本原因是环境差异被 composer.lock 隐蔽了：它锁定了具体版本，但没锁 PHP 版本、扩展、OS 行为等运行前提。
- CI 报
ext-gd not found或mbstring extension missing？不是 Composer 问题，是 Docker 镜像或 runner 缺少 PHP 扩展 - 遇到
Class not found却确定已安装？检查 CI 是否用了--no-dev，而某个包的生产代码意外依赖了--dev下的工具类（少见但存在） - 最稳妥做法：CI 中执行
composer install --no-interaction --optimize-autoloader --no-progress，并确保 PHP 版本和扩展与本地php -v和php -m一致
包管理不是“装上就行”的事，Laravel 的生命周期、Composer 的 autoload 时机、PHP 环境的硬性要求，三者咬合稍有错位，就会在看似无关的地方报错。
