必须在composer.json的require中写死无修饰符版本（如"vendor/package": "1.2.3"）或用等号语法（"vendor/package": "=1.2.3"），并运行composer update vendor/package更新composer.lock，否则composer install仅按lock文件还原，不读取json中的新约束。
想让 composer install 每次都装同一个版本，光靠 composer.lock 不够稳——必须在 composer.json 的 require 里写死无修饰符的纯数字版本，比如 "guzzlehttp/guzzle": "7.5.0"；加了 ^、~、dev- 或 @dev 都不算锁死。
怎么在 composer.json 里真正锁死一个包
只有两种写法能确保 Composer 绝不自动升级：
-
"vendor/package": "1.2.3"—— 无任何前缀/后缀，最常用也最可靠 -
"vendor/package": "=1.2.3"—— 等号语法（Composer 2.2+ 支持），语义更明确
常见错误写法："monolog/monolog": "^2.8" 允许升到 2.99.99；"laravel/framework": "dev-main" 每次 update 都可能拉新提交；"symfony/console": "v6.4.0" 会被 Composer 自动转成 ^6.4.0，不是锁死。
改完 composer.json 后，必须运行 composer update vendor/package（不能只 install），否则 composer.lock 里还是旧版本或宽泛约束。
用 composer require 命令安装指定版本时的坑
命令行看似简单，但符号含义极易误判：
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
-
composer require guzzlehttp/guzzle:7.5.0→ 正确，写入"guzzlehttp/guzzle": "7.5.0" -
composer require guzzlehttp/guzzle=7.5.0→ 等价于上一条，=是可选语法糖 -
composer require guzzlehttp/guzzle:^7.5.0→ 错误，实际允许升到7.99.99 -
composer require monolog/monolog:v2.9.1→ 虽能装对 Tag，但默认写入"^2.9.1"，不是锁死
如果已存在宽泛约束（如 "^2.0"），直接 require xxx:2.8.0 可能被忽略——建议先 composer remove vendor/package，再重装精确版。
为什么改了 composer.json 还是装错版本
根本原因永远是 composer.lock 优先级高于 composer.json：
-
composer install只读composer.lock，完全不看composer.json里的新约束 - 若
lock文件里仍存着"monolog/monolog": "^2.0"，哪怕你把json改成"2.8.0"，install依然装2.0范围内最新版 - 本地缓存或 Packagist 上没发布该版本（如你写
"1.2.3"，但作者只打了1.2.2和1.3.0"），Composer 会 fallback 到最近可用版本
验证是否真锁死：打开 composer.lock，搜索包名，确认 version 字段是完整字符串（如 "2.8.0"），且 source.reference 是确定的 commit hash，不是分支名（如 main 或 dev-main）。
CI/CD 和团队协作中最容易被忽略的点
锁版本不是写完就结束的事，关键在落地环节：
-
composer.lock必须提交进 Git，删掉它等于放弃依赖控制 - CI 流水线必须用
composer install，严禁composer update（后者会重算整个依赖图） - 上线前加一道保险：
composer install --locked，它会校验lock里每个版本是否仍满足json中的约束，不满足直接报错 - PHP 版本不匹配会导致“明明写了正确版本却装不上”——例如某包
composer.json声明"php": ">=8.0"，而 CI 环境是7.4，Composer 会跳过该版本去选兼容的旧版
真正难的不是语法，而是理解 composer.json 是声明、composer.lock 是契约、Git 提交和 CI 执行方式才是契约生效的最后防线——三者缺一不可。
