依赖管理核心是 composer.json 声明意图、composer.lock 锁定现实，install 严格还原锁文件环境，update 重新解析依赖树；CI/CD 必须用 install 保障可重现构建，lock 文件是环境契约而非中间产物。
先说核心结论：依赖管理这事儿，可别当成“装完就跑”的一次性操作。它真正的核心在于，用 composer.json 来声明你的意图，用 composer.lock 来锁定确切的现实，再让 composer install 和 composer update 这两个命令各司其职。线上环境里90%的“在我机器上是好的”这类不一致问题，根源往往就是用错了命令，或者忽略了锁文件的重要性。
为什么 composer install 突然失败，而 composer update 却能过？
这通常不是网络或者权限问题，而是Composer在严格执行它的语义规则。只要项目根目录下存在 composer.lock 文件，composer install 就会变成一个严格的“环境还原师”。它只认锁文件里白纸黑字记录的**精确版本号、哈希值、PHP版本要求以及扩展列表**。举个例子，如果你本地的PHP版本低于锁文件中声明的 "php": "^8.1" 这条最低要求，或者缺少了某个依赖包硬性要求的 ext-gd 扩展，它会立刻抛出 Your requirements could not be resolved 错误，毫不含糊。
而 composer update 的行为则截然不同。它会暂时把锁文件放到一边，重新打开 composer.json，根据里面相对宽松的版本约束（比如 "monolog/monolog": "^3.0"）去依赖仓库里寻找一个“理论上可行”的新版本组合。这个机制虽然能让安装过程继续进行，但也恰恰掩盖了环境已经发生漂移的风险——你装上的可能已经不是之前测试通过的那套代码了。
- 所以，遇到 install 失败，先别慌。运行
php -v和php -m | grep gd这类命令，核对一下当前环境的PHP版本和扩展是否与锁文件中的声明匹配。 - 千万别习惯性地删除
composer.lock重来。先确认是不是开发机、CI服务器和线上环境的PHP版本出现了不一致。 - 如果确实需要重建依赖树，务必先用
composer update --dry-run预览变更，再配合git diff composer.lock仔细看看，到底有哪些包的版本真的被动了。
composer require 加版本号到底写 ^3.0 还是 3.0.*？
这两种写法看似相似，实则差异巨大，直接决定了后续更新的行为和兼容性边界。^3.0 是语义化版本控制的推荐写法，表示允许自动升级到 3.x 系列的任何次版本（例如从 3.0.0 升到 3.5.2），但禁止跳到 4.0 这样的主版本。而 3.0.* 是一种旧式写法，等价于 ~3.0.0，它只允许进行补丁级别的更新（比如从 3.0.0 到 3.0.1），连升级到 3.1.0 都不行。
立即学习“PHP免费学习笔记（深入）”；
对于现代项目，强烈推荐使用 ^ 符号。它更符合语义化版本（SemVer）的惯例，也与Packagist上绝大多数包的发布节奏相匹配。不过，这里有个但书：有些历史包袱较重的老包可能并未严格遵守SemVer规范，有时会把破坏性变更塞进次版本更新里。遇到这种情况，就得退而求其次，使用像 3.0.5 这样的固定版本号，或者在 composer.json 中配置 "minimum-stability": "stable" 来兜底，避免引入不稳定的开发版本。
- 引入新包时，优先使用
composer require vendor/package:^3.0这样的格式，不要省略^符号。 - 生产项目在上线前，务必检查
composer.json中所有require条目是否都明确带有^或固定版本，避免隐含的*或空版本导致后续不可控的升级。 - 如果团队多人协作，建议统一在
composer.json顶部加上"prefer-stable": true配置，让Composer在解析时默认倾向于稳定版，而不是开发分支。
CI/CD 流水线里该跑 composer install 还是 composer update？
答案非常明确：在CI/CD流水线中，永远只应该运行 composer install，并且必须确保 composer.lock 文件已经提交到Git仓库中。因为流水线的核心目标是实现**可重现的构建**，而不是去探索最新的、未经测试的依赖组合。
一旦在部署脚本里错误地使用了 composer update，就等于把版本决策权完全交给了打包那一刻Packagist仓库的状态。今天能构建成功的代码，明天可能因为某个间接依赖发布了一个不兼容的补丁而突然失败。更糟糕的是，它会悄无声息地重写 composer.lock 文件。如果CI流程没有配置自动提交这个新锁文件，那么下一次部署时又会用回旧的版本，从而产生难以追踪的“幽灵差异”。
- 可以在CI脚本的开头加上一句
test -f composer.lock || (echo "ERROR: composer.lock missing" && exit 1)，作为防止锁文件漏提交的硬性检查。 - 在部署服务器上，应该禁用执行
composer update的权限。生产环境安装依赖时，使用composer install --no-dev --optimize-autoloader命令，确保只安装生产必需的依赖，并生成最优化的自动加载文件。 - 如果真的需要测试依赖升级，正确的做法是：单独创建一个分支，运行
composer update --dry-run预览变更，然后配合完整的自动化测试套件进行验证。测试全部通过后，再将变更合并到主干，并提交新的composer.lock文件。
怎么快速定位谁在阻止我升级某个包？
当你运行 composer update monolog/monolog 却报错提示“无法满足版本要求”时，别靠猜。Composer自带了一个非常实用的诊断命令：
运行 composer prohibits monolog/monolog:^3.5，它会清晰地列出所有直接或间接声明了与该版本冲突的约束的包，包括它们各自的 require 字段内容。常见的原因无非几种：可能是某个下游依赖包硬性绑定了 "monolog/monolog": "^2.0"；也可能是你的 composer.json 里写着 "php": "^7.4"，而你想升级的 monolog 3.5 却要求PHP 8.0+。
- 首先运行
composer prohibits命令，看清到底是哪个包卡住了升级路径，而不是盲目地去降低目标包的版本。 - 如果卡住的是你们团队自己维护的私有包，那就检查它的
composer.json是否锁死了旧版本。如果是第三方包，去它的Packagist页面看看是否已经停止维护了。 - 作为临时解决方案，可以使用
composer update monolog/monolog --with-all-dependencies来尝试连带升级相关依赖。但务必记录下哪些二级依赖也被动过了，并且补充相应的测试。
说到底，真正的难点从来不是记住命令怎么敲，而是深刻理解 composer.lock 不是可有可无的中间产物，而是一份严肃的**环境契约**；composer.json 里的每一个波浪号（~）或脱字符（^），都在无形中定义着你未来技术债的边界。修改一行版本号，可能会触发十层依赖的连锁反应。因此，每次执行 update 之后，别只盯着 composer.lock 文件的diff变化，更重要的是，确保你的测试套件全部通过，并仔细检查日志中是否有新的警告出现。
