Class not found 错误主因是自动加载未刷新，应优先执行 composer dump-autoload；若包未被发现，再运行 php artisan package:discover 并检查 composer.json 中 autoload 和 extra.laravel 配置是否合规。
装完包却报 Class not found 或命令不存在，不是包没装上，而是 Laravel 没“认出”它——自动加载没刷新、服务提供者没注册、或自动发现被关了。
composer require 后类找不到？先跑 dump-autoload
执行 composer require vendor/package 只是把包写进 vendor/ 并更新 composer.json，不会自动重生成类映射。Laravel 加载新类时会去 vendor/autoload.php 查表，这张表没更新就查不到。
- 立刻运行
composer dump-autoload强制刷新映射 - 检查该包的
composer.json是否含有效autoload，例如："psr-4": {"Spatie\Permission\": "src/"} - 若包用的是
classmap或自定义路径，dump-autoload更不可跳过
php artisan package:discover 没输出你的包名？看自动发现开关
Laravel 5.5+ 默认启用自动发现，但前提是包的 composer.json 里没设 "dont-discover": ["*"]，且声明了 extra.laravel 配置段。
Laravel Cloud
下载
Laravel Cloud（cloud.laravel.com）。此技能用于处理所有 Laravel Cloud 请求，包括搜索和读取数据。只要任务涉及 Laravel Cloud，即使用此技能。
- 运行
php artisan package:discover，观察终端输出是否含你的包名（如SpatiePermissionPermissionServiceProvider） - 没出现？查该包源码的
composer.json：确认有"extra": {"laravel": {"dont-discover": false}}（或干脆没这一段） - 若被
dont-discover屏蔽，就得手动加providers到config/app.php
composer install 和 composer update 到底该用哪个？
生产环境部署脚本里写 composer update 是高危操作——它会忽略 composer.lock，重新解析所有依赖，可能升到不兼容版本。
- 新项目克隆、CI/CD 流水线、线上部署：必须用
composer install --no-dev - 只升级某个包（比如修复安全漏洞）：用
composer update vendor/package --with-dependencies -
composer require是添加新包的唯一推荐方式；手改composer.json后再跑update容易误触全量升级
私有包装不上？权限、autoload、Git 标签三者缺一不可
加了 repositories 却提示 Could not find package，大概率卡在这三个地方：
- 私有包自己的
composer.json必须含"name": "acme/internal-utils"和完整autoload（如"psr-4": {"Acme\InternalUtils\": "src/"}） - Git 仓库要有带
v前缀的语义化标签（如v1.2.0），否则 Composer 不认作可安装版本 - 若用 Git SSH 地址，确保部署机已配好对应 SSH key 并能
git clone成功
最常被忽略的是：包装进 vendor/ 不等于能用，Laravel 的“识别链”（autoload → discover → service provider → config）断在任一环都会静默失败。别急着删 vendor，先盯住 composer dump-autoload 和 php artisan package:discover 的输出。
