新部署或上线 laravel 项目必须用 composer install；仅修改 composer.json 明确升级依赖时才用 composer update。install 读 composer.lock 确保版本一致、安全可复现；update 忽略 lock 文件，可能引入破坏性变更。
composer install 和 composer update 到底该用哪个？
新部署 Laravel 项目或上线时，必须用 composer install；只有明确要升级依赖版本（比如改了 composer.json 里的 "laravel/framework": "^10.40"）才用 composer update。
常见错误现象：composer update 在生产环境跑，结果拉下不兼容的 symfony/console 补丁版，导致 php artisan 直接报 Class not found。
-
install读composer.lock，装完全一致的版本，安全、可复现 -
update忽略lock，按composer.json重新解析依赖树，可能引入破坏性变更 - Laravel 官方文档和 GitHub Actions 模板里，CI/CD 部署步骤全写的是
composer install --no-dev --optimize-autoloader
为什么 vendor/autoload.php 不能手动 require？
Laravel 启动流程依赖 Composer 自动生成的自动加载逻辑，尤其是 PSR-4 映射和 classmap 优化；手写 require 'vendor/autoload.php' 看似能跑，但会绕过 Laravel 的服务提供者注册机制和配置加载顺序。
使用场景：只在写独立脚本（比如导出数据的 export.php）且不调用任何 Laravel 核心类时，才考虑手动引入；日常开发中所有入口都走 public/index.php 或 artisan。
- 手引 autoload 会导致
config/app.php不生效，AppServiceProvider不注册 -
php artisan tinker会直接失败，报Class 'IlluminateFoundationApplication' not found - 正确做法是统一用 Laravel 提供的入口，哪怕只是跑一个命令，也走
php artisan command:run
如何安全地更新 laravel/framework？
不能直接 composer update laravel/framework，必须配合官方升级指南，因为 Laravel 主版本升级常伴随配置文件结构变化、废弃方法移除、中间件签名变更等隐性破坏点。
性能 / 兼容性影响：跳过 minor 版本（比如从 10.28 直升 10.45）通常没问题；但跨大版本（9 → 10）必须重跑 php artisan storage:link、检查 bootstrap/app.php 是否还存在、确认 APP_KEY 是否被重新生成。
- 先看 Laravel 10 升级指南，重点查「Breaking Changes」小节
- 执行前备份
.env和config/下所有自定义配置文件 - 更新后立刻运行
php artisan config:clear && php artisan cache:clear，否则缓存旧配置导致路由 404 或中间件失效
autoload-dev 里的测试类为啥总在生产环境报错？
因为 composer.json 中 "autoload-dev" 下的 PSR-4 映射（比如 "Tests\": "tests/"）默认只在 dev 环境生效；但如果你用了 --no-dev 安装却没清掉已生成的 autoloader，就会残留测试类路径，而生产环境又没装 phpunit，一调用就 Class 'PHPUnitFrameworkTestCase' not found。
最容易被忽略的地方：CI 构建后没运行 composer dump-autoload --no-dev，导致 vendor/composer/autoload_psr4.php 里还留着 "Tests\" 条目。
- 上线部署命令必须带
--no-dev，且之后补一句composer dump-autoload --no-dev - 检查
vendor/composer/autoload_psr4.php文件，确认没有"Tests\"或"Feature\"这类开发专用命名空间 - 如果用了 Pest 测试框架，它的
Pest\命名空间也属于autoload-dev，同样要清理
