包名错误或版本不兼容是主因；需核对标准包名（如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.json autoload 后）
• 确认 .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 认出来。