该用 composer install——它按 composer.lock 精确还原依赖，确保环境一致；composer update 则按 composer.json 重新解析并升级到最新兼容版本，仅适用于本地开发或漏洞修复。
composer install 和 composer update 到底该用哪个
装包时最常混淆的两个命令，本质区别在于：前者按 composer.lock 精确还原依赖版本，后者按 composer.json 重新解析并升级到满足约束的最新兼容版本。
团队协作或上线部署必须用 composer install——它跳过版本计算，直接读 lock 文件安装，快且确定；本地开发想尝新或修复已知漏洞，才手动跑 composer update。
- CI/CD 流水线里写错成
composer update，可能悄悄升了某个间接依赖，导致行为不一致 -
composer install在没生成composer.lock时会自动 fallback 成 update 行为，但这是例外，不是常态 - 想只更新某一个包？用
composer update vendor/package-name，别全量刷
require 和 require-dev 的边界在哪
区分运行时依赖和开发期依赖，不是为了“看着整齐”，而是直接影响生产环境体积、安全扫描范围和 autoload 效率。
require 里的包会被所有环境加载，require-dev 只在本地 composer install 时安装（除非加 --no-dev），且默认不参与自动加载优化。
- 测试工具（如
phpunit/phpunit）、代码质量工具（如phpstan/phpstan）必须放require-dev - 把
monolog/monolog放错到require-dev，线上日志就直接挂掉 -
autoload-dev配置只影响require-dev包的类加载路径，别指望它让 dev 包的类在生产可用
composer.lock 不提交 = 每次都是盲装
composer.lock 不是缓存文件，是依赖快照——它记录了每个包的确切版本、hash、PHP 扩展要求、甚至嵌套依赖树。没它，composer install 就退化成 update。
Git 忽略 composer.lock 是常见错误，尤其初学时觉得“反正有 json 就够了”。结果就是：你本地能跑，CI 报错，同事拉代码后 vendor 目录和你完全不一样。
- 私有项目、开源库、SaaS 后端服务，都必须提交
composer.lock - 只有纯库（library）项目可不提交 lock，因为它是被别人 require 的，不该锁定下游环境
- 修改
composer.json后，记得立刻composer update --lock或执行一次install来刷新 lock
autoload 自动加载失效的几个硬核原因
类找不到（Class not found）不一定是命名空间写错，很可能是 autoload 配置没生效、PSR 规则不匹配，或者 vendor 重装后未重新 dump。
composer dump-autoload 不是万能刷新键，它只重建自动加载映射，不解决路径错误或 PSR-4 声明与实际目录结构不符的问题。
- 新增了一个
src/Helper/Utils.php，但composer.json中autoload.psr-4写的是"App\": "src/"，那必须用new AppHelperUtils()，少一层命名空间就找不到 - 改了目录结构后没运行
composer dump-autoload -o（优化模式），开发时可能不报错，但生产用opcache就会卡住 -
classmap方式要手动维护，删了文件却忘了dump-autoload，就会残留无效路径
依赖管理不是记几个命令的事，关键是理解 lock 文件的契约意义、autoload 的路径绑定逻辑，以及 dev 和 prod 两套依赖的物理隔离机制。这些地方一旦模糊，问题往往出现在深夜上线前五分钟。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
