多团队共用 composer.json 时，composer update “悄悄改版本”是因为 ^/~ 约束、本地环境差异及 lock 文件 content-hash 不校验平台导致依赖不一致；需统一 lock 管理、强制平台检查、规范私有包发布与约束。
多个团队共用同一个composer.json时，为什么composer update总在“悄悄改版本”
因为 Composer 默认按 ^ 或 ~ 解析版本约束，不同团队本地的 composer.lock 可能由不同时间、不同 PHP 版本、不同插件环境生成，导致 composer update 拉取的依赖实际版本不一致。
- 团队 A 运行
composer update时 PHP 是 8.1，某些包会装 v3.x；团队 B 在 PHP 8.0 下运行，同一行约束可能降级到 v2.9.x -
composer.lock中的content-hash不校验平台差异，只校验composer.json内容，所以“看起来没改”，实则依赖树已偏移 - CI 流水线若未固定
COMPOSER_PLATFORM_CHECK=1，会跳过平台检查，进一步放大不一致风险
如何让多团队对齐同一套依赖快照
核心不是禁止 update，而是控制谁、何时、以什么方式生成 composer.lock。
- 所有团队必须从同一份
composer.lock提交开始工作，禁止本地执行composer update后直接提交 - 升级依赖必须走统一 PR：由专职维护者（或 CI 脚本）在干净容器中运行
composer update --with-all-dependencies，并附带 PHP/OS 环境声明 - 在
composer.json顶层加"platform-check": true，并在 CI 中设置COMPOSER_PLATFORM_CHECK=1，强制校验 PHP 扩展和版本 - 使用
composer install --no-dev部署时，确保composer.lock已包含dev依赖的完整解析结果（否则--no-dev可能漏掉间接依赖）
composer require 跨团队协作时最常踩的三个坑
看似只是加一行包，但多团队环境下极易引发隐性冲突。
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 某团队执行
composer require monolog/monolog:^3.0，另一团队已有symfony/console:^5.4，而monolog:^3.0要求php:>=8.1—— 若未开启平台检查，composer install仍会成功，但运行时报Fatal error: Uncaught TypeError - 使用
composer require --dev添加测试工具（如phpunit/phpunit），但未同步更新autoload-dev配置，导致其他团队跑测试时类找不到 - 团队各自
require同一包的不同子集（如laravel/frameworkvsilluminate/database），Composer 会尝试合并，但可能因版本约束冲突回退到旧版，且不报错，只静默降级
私有包发布节奏怎么和主项目解耦又不失控
不能靠“大家自觉升”，也不能全锁死——得靠约束机制把发布权收口。
- 所有私有包必须发布带
stable标签的版本（即非dev-main），主项目的composer.json中禁用minimum-stability: dev - 用
composer config repositories.my-org '{"type": "composer", "url": "https://packages.myorg.com"}'统一指向私有源，禁止直接path或vcs引入本地路径 - 私有包每次发布前，需触发一个轻量 CI：拉取所有依赖它的主项目仓库，运行
composer update --dry-run，失败则阻断发布 - 主项目中对私有包的版本约束建议用
^x.y.0（而非^x.y），避免小版本更新意外引入破坏性变更（比如myorg/utils的v1.2.3 → v1.2.4改了某个 helper 函数签名）
真正难的不是写规则，是让所有团队的 composer.lock 文件在 Git 中始终可比对、可追溯、可验证。一旦有人绕过流程手动生成 lock，整条链就不可信了。
