Composer升级依赖锁定_Composer升级版本号规则解析【入门】
修改composer.json后直接执行install命令不会更新依赖，因为install严格遵循composer.lock文件中的锁定版本。必须运行update命令重新解析依赖并更新lock文件，install才会安装新版本。update并非总是升级到最新版，而是在满足约束的兼容版本中选择最高的。
很多开发者都遇到过这样的困惑：明明在composer.json里把版本号从^2.11改成了^2.12，但执行composer install后，依赖纹丝不动。这背后其实是一个关键概念没搞明白：真正决定安装哪个版本的，不是.json文件里的版本范围，而是composer.lock文件。
简单来说，composer install的任务是“按图索骥”——它完全依照composer.lock中记录的精确版本号进行安装，根本不会去重新计算依赖。所以，无论你把.json里的约束改得多宽，只要不更新.lock文件，install命令就只会忠实地还原旧版本。
为什么改了版本号，install却没反应？
这正是问题的核心。当你把composer.json中的"monolog/monolog": "^2.11"改成"^2.12"甚至"^3.0"后，直接运行composer install是无效的。因为这条命令的逻辑是：如果composer.lock存在，就无视.json中的版本约束，直接安装.lock里锁定的版本。
于是就会出现一个常见的“假象”：执行composer show monolog/monolog，发现版本依然是2.11.0，让人误以为命令失效了。
正确的做法是：修改composer.json后，必须运行composer update monolog/monolog来触发依赖解析。这条命令会重新计算满足新约束的版本，并更新composer.lock文件。之后，再运行install才会安装新版本。
这里还有一个容易踩的坑：如果monolog/monolog不是你项目直接声明的依赖，而是某个第三方包的子依赖，那么直接在根目录的composer.json里修改是没用的。你需要先把它明确添加到项目的require列表中，再进行版本锁定。
composer update 到底按什么规则选版本？
很多人以为update就是“更新到最新版”，其实不然。它的工作流程要严谨得多：它会从当前所有已满足约束的兼容版本中，选择语义化版本号最高的那个。这个选择还必须被整个依赖关系图所接受，同时不能违反config.platform或其他包的约束。
举个例子，约束"^2.11.0"允许升级到2.x.x系列中的任何版本，但绝不会跳到3.0.0。而"~2.11"实际上等价于">=2.11.0, <2.12.0"，这意味着连2.11.1都可能因为其他约束而被跳过。
依赖冲突是另一个复杂点。假如你的项目要求monolog/monolog: ^2.11，但另一个已安装的包要求^3.0，那么Composer在解析时可能会被迫将monolog/monolog升级到3.0.0，以满足所有依赖。
面对这种不确定性，有两个命令非常实用：
- 运行
composer update --dry-run可以预览即将安装的版本，比盲目猜测可靠得多。 - 使用
composer prohibits monolog/monolog:3.0.0可以快速定位是哪个包在阻止升级到特定版本，比why-not命令更直接。
如何安全地只升级一个包？
默认情况下，composer update vendor/package在升级目标包时，也可能连带升级它的直接依赖。如果你想控制影响范围，可以借助一些选项。
希望影响最小化？可以加上--with-dependencies参数。它会升级目标包及其所有直接依赖，但不会深入到间接依赖的层级。
想要彻底隔离？更稳妥的做法是，先确认当前子依赖的版本，然后在composer.json里把它们也明确固定下来（例如"psr/log": "3.0.0"），再执行update。
最保险的策略是：使用composer update vendor/package-a vendor/package-b，显式列出所有你允许更新的包。没被列出的包，就绝对保持不动。
需要注意的是，如果某个子依赖被多个包共同使用，且版本要求冲突，那么--with-dependencies可能会执行失败。这时就必须手动调整composer.json中的版本约束来调和冲突。
composer.lock被意外修改，后果有多严重？
千万别把composer.lock当成一个普通的缓存文件。它是确保团队协作和部署环境一致性的“唯一凭证”。一次无意识的lock文件变更被提交到Git，就可能导致CI/CD流水线构建出与本地开发环境完全不同的vendor/目录。
典型的灾难场景是：本地phpunit运行得好好的，版本是9.6.13，但CI却报错Class 'PHPUnit\Framework\TestCase' not found。一查才发现，因为lock文件被更新，CI实际安装的是接口已经重构的10.0.0版本。
如何防范？
- 养成习惯：将
git status composer.lock纳入日常检查清单。 - 在CI脚本的开头，加入
composer validate --strict命令，可以拦截因.json和.lock不一致而导致的构建。
如果lock文件已经出了问题，怎么修复？
记住，不要手动编辑composer.lock。可以使用composer update --lock命令，它只会刷新文件的哈希、URL等元数据，而不会改变任何包版本。如果lock文件已损坏，最稳妥的办法是从Git恢复上一个干净的版本，然后重新运行composer install。
最后，一个最容易被忽略的要点：即使你在composer.json里写死了版本"2.11.0"，只要composer.lock文件没有提交到仓库，或者在CI环境中被脚本误删，那么composer install命令就会自动退化成composer update的行为。这时，所有你以为的“版本锁定”都将形同虚设。
PHP开发中，定位类文件不应依赖composerdump-autoload（仅重新生成映射文件，不会自动发现新类）。有效方法：使用composershow--path查包路径并结合PSR-4规则定位；或使用ripgrep搜索类定义；IDE跳转需确保索引正确，来避免误定位。并且避免直接修改vendor目录。
composershow列出所有包及版本（含开发依赖），--direct查看顶层依赖，--name-only输出纯包名，--format=json输出JSON。composeroutdated检查可更新包，composershow-t显示依赖树层级。版本号基于composer.lock，不保证vendor真实状态，需先运行composerinstall（或-
使用composerclear-cache命令可以安全地清除缓存，仅清理缓存目录下的内容。安装新版本需要先删除composer.lock后执行install或update，CI/CD中务必加--no-interaction参数。在缓存目录下files/可以删除旧包以释放空间，vcs/可以安全清除，repo/不建议删除该目录以免影响依赖解析。
Composer的稳定性配置中，minimum-stability是硬性过滤闸，低于该级别的版本被直接忽略；require里加@后缀可精准授权单个包；prefer-stable仅在候选版本中影响选择；子依赖的minimum-stability可能覆盖项目设置，需用stability-flags压制，以此确保依赖版本符合预期。
Composer不安装PHP扩展，仅当执行install或update时，会检查ext-xxx是否启用，若缺失则中断并报错。扩展声明须在require或require-dev中，版本号仅用于约束，无实际校验作用。扩展名必须与php-m输出的模块名完全一致。config.platform仅模拟环境，不能绕过运行时校验。
使用Phinx时需要手动配置phinx.php或phinx.yml文件并补全数据库连接信息；迁移文件须手写up和down方法，并仔细检查字段类型及索引细节；多环境切换时必须严格确认配置优先级和命名格式，否则极易导致迁移失败甚至报错。
使用replace时需注意：它仅仅声明替代关系，不会自动删除旧包，也不会继承旧包的autoload配置。因此，开发者必须手动移除旧包，并完整配置autoload，同时添加conflict字段来避免依赖冲突。另外，replace适用于替换具体包，而实现接口则应使用provide。
Composer是Yii根基，需正确配置composer.json区分require与require-dev，准确设置入口文件autoload.php路径，用create-project安装而非直接require核心库，锁死版本约束防兼容问题，并注意cookieValidationKey等环境配置。
Postman是一套面向API全生命周期的开发与测试平台，可在Mac上发送和调试多种协议请求，管理集合、环境及认证信息，并完成脚本测试、模拟服务、监控、文档发布和团队协作。它适合开发、测试及运维人员使用，提供个人免费方案。
Docker Desktop 是 Docker 官方为 Mac 提供的容器开发环境，集成 Docker Engine、命令行工具、Compose、Build、Kubernetes 与图形化管理界面。
Android Studio 是 Google 面向安卓应用开发提供的官方集成开发环境，基于 IntelliJ IDEA 构建。它整合智能代码编辑、Gradle 构建、界面预览、设备模拟、性能分析、调试测试及 APK 分析等工具。
PixPix 是面向品牌、卖家和内容团队的在线 AI 图片视频创作平台，提供图视频 Agent、无限画布、图片生成、视频生成、自然语言编辑及商品套图、产品精修和带货视频等电商工具。
Postman 是面向 API 全生命周期的开发与协作平台。Windows 桌面版可用于构建和发送 HTTP、GraphQL、gRPC、WebSocket、MQTT 等请求，并提供环境变量、集合、脚本测试、模拟服务、监控、文档及团队工作区等
Docker Desktop 为 Windows 开发者提供集成式容器环境，内置 Docker Engine、命令行工具、Compose、Build 与 Kubernetes 等组件，可在本机完成镜像构建、容器运行、日志查看和资源管理。