新项目拉代码后必须用 composer install，它读取 composer.lock 精确还原依赖版本；composer update 会忽略 lock 文件、按 composer.json 重新解析并升级包，易引发不兼容问题。
composer install 和 composer update 到底该用哪个？
新项目拉代码后必须用 composer install，不是 composer update。前者读 composer.lock 精确还原依赖版本，后者会无视 lock 文件、按 composer.json 重新解析并升级所有可更新包——这在团队协作或生产环境里等于主动引入不兼容变更。
- 本地开发完新功能、新增了包，才用
composer update（最好指定包名，比如composer update guzzlehttp/guzzle） -
composer install在 CI/CD 或部署脚本中是标准动作，漏掉composer.lock提交会导致环境不一致 - 如果报错
Package operations: 0 installs, 0 updates, 0 removals，说明 lock 文件和 json 已同步，不用硬跑 update
Laravel 项目里为什么 vendor/autoload.php 不能手动 require？
因为 Laravel 的自动加载机制依赖 Composer 生成的 vendor/autoload.php，但它本身不是“入口文件”，而是被 bootstrap/autoload.php（Laravel 5.5+ 已移至 bootstrap/app.php）调用。直接 require 容易绕过框架初始化流程，导致 Facade、Service Provider 或配置未加载。
- 启动入口始终是
public/index.php，它会载入bootstrap/app.php，再由其加载 Composer 自动加载器 - 写命令行脚本时，若需单独加载 Laravel 环境，应使用
require __DIR__.'/../vendor/autoload.php';+ 手动创建Application实例，而不是只 include autoload - 常见错误：在某个工具类里直接
require 'vendor/autoload.php'后调config('app.name')—— 此时 Config 服务根本没注册，返回 null
如何安全地升级 Laravel 主版本（比如 9 → 10）？
别直接改 composer.json 里的 "laravel/framework" 版本然后 run update。Laravel 主版本升级涉及大量破坏性变更，官方提供 laravel-shift 工具和升级指南，但实操中更可靠的是分三步走：
- 先确认当前项目 PHP 版本满足目标 Laravel 要求（例如 Laravel 10 需 PHP 8.1+），不达标先升 PHP
- 运行
composer update "laravel/framework" --with-dependencies，加上--with-dependencies是为了连带更新laravel/tinker、nesbot/carbon等强关联包，避免版本冲突 - 检查
php artisan about输出是否显示正确版本；再重点看storage/logs/laravel.log里有没有Target class [xxx] does not exist类错误——这往往是因为 Service Provider 被重命名或移除（如App\Providers\AppServiceProvider没问题，但旧版自定义的RepositoryServiceProvider可能已被弃用）
为什么 composer dump-autoload 有时不生效？
这个命令只是重新生成自动加载映射，不解决类找不到的根本问题。它常被误用成“修复找不到类”的万能键，其实只有两类情况真正需要它：
- 你新增了非 PSR-4 规范的类（比如放在
app/Helpers/下但没在composer.json中声明files加载），加完配置后必须 dump - 修改了
composer.json中的autoload或autoload-dev配置（比如加了新的 PSR-4 namespace），否则新路径不会进自动加载列表 - 如果刚新建了一个
app/Models/User.php就报错，大概率是命名空间写错（应为App\Models\User）或文件名大小写不匹配（Linux 下user.php≠User.php），这时候 dump 没用
composer update 带来的间接依赖变更，而日志里只有一行 Call to undefined method ...，得顺着 stack trace 往上翻两层，才能发现是某个第三方包悄悄升级后改了接口。 
