包名错误或版本不兼容是主因；需核对标准包名（如spatie/laravel-permission，非下划线或中文名）及composer.json中laravel/framework版本约束，不匹配时须加版本号安装。
为什么composer require装不上包？先查包名和版本约束
绝大多数失败不是 Composer 问题，而是包名写错或 Laravel 版本不匹配。Laravel 生态没有“插件”概念，只有标准 Composer 包，比如 spatie/laravel-permission，不是 spatie/laravel_permission（下划线错误）或 “权限插件” 这类中文描述。
必须确认两点：
- 去包的 GitHub 页面或 Packagist 页面，抄完整、准确的包名（含斜杠，不用下划线）
- 打开该包的
composer.json，检查"require": {"laravel/framework": "^10.0"}这类声明，确保它支持你当前的 Laravel 版本（运行php artisan --version查看） - 若不匹配，加版本约束安装，例如
composer require spatie/laravel-permission:^6.0（对应 Laravel 10），而不是默认 latest
装完没反应？服务提供者和配置文件可能没注册
Laravel 5.5+ 虽有自动发现（Auto-Discovery），但不是所有包都支持，尤其老包或自定义包。装完后如果命令不出现、类找不到、配置没生成，大概率是服务提供者没加载。
手动补救步骤：
- 编辑
config/app.php，在'providers' => []数组里追加服务提供者类，例如Spatie\Permission\PermissionServiceProvider::class - 运行
php artisan vendor:publish --provider="Spatie\Permission\PermissionServiceProvider"，生成config/permission.php - 某些包（如
laravel/scout）还需额外初始化：运行php artisan scout:install建表
composer require vs composer update：什么时候用哪个？
日常添加新扩展包，只用 composer require vendor/package。它会更新 composer.json、下载包、写入 composer.lock，并触发 post-autoload-dump 等钩子。
Laravel Cloud
下载
Laravel Cloud（cloud.laravel.com）。此技能用于处理所有 Laravel Cloud 请求，包括搜索和读取数据。只要任务涉及 Laravel Cloud，即使用此技能。
别用 composer update 来“装包”，除非你明确想升级整个依赖树——这极易引发冲突。特别注意：
-
composer update vendor/package看似精准，但一旦漏写包名，就会执行全量更新，可能破坏现有环境 - 团队协作中，
composer.lock必须提交 Git，否则composer install在其他机器上无法还原一致依赖 - 生产部署应始终用
composer install --no-dev，避免 dev-only 包被误装
装完后 php artisan 报错？重点检查 autoload 和密钥
常见现象是命令存在但执行报 Class not found 或 Call to undefined function，根源往往不在包本身，而在框架加载链断裂。
快速排查项：
- 运行
composer dump-autoload强制重建自动加载映射（尤其手动改过composer.jsonautoload 后） - 确认
.env中APP_KEY已生成；若为空，运行php artisan key:generate - 清缓存：依次执行
php artisan config:clear、php artisan cache:clear，避免旧配置干扰 - 检查
vendor/autoload.php是否被正确引入——所有 Artisan 命令入口都依赖它，漏掉就全盘失效
最易被忽略的是 autoload 配置与服务提供者注册的耦合性：一个包即使物理文件已存在，若没进 providers 数组或没触发 package:discover，它就等于没“通电”。别只盯着 require 成功与否，要验证它是否真被 Laravel 认出来。
