应显式声明版本约束而非依赖默认规则；精确版本（如"2.9.0"）严格锁定，波浪号（如"~2.9.0"）等价于>=2.9.0 && <2.10.0，插入号（如"^2.9.0"）等价于>=2.9.0 && <3.0.0。
直接在 composer.json 的 require 字段里写约束，不是“设置”而是“声明”——Composer 按你写的约束去选版本，不写默认用 ^ 规则，但生产环境强烈建议显式控制。
精确版本 vs 波浪号 vs 插入号：选哪个取决于你敢不敢放行更新
不同约束行为差异极大，选错会导致意外升级或锁死过时包：
-
"monolog/monolog": "2.9.0"：只装这个版本，连2.9.1都不认。适合核心日志组件等不能有任何偏差的场景 -
"monolog/monolog": "~2.9.0"：等价于>=2.9.0 ，允许小版本（bugfix）更新，但不会跨 <code>2.9.x → 2.10.x -
"monolog/monolog": "^2.9.0"：等价于>=2.9.0 ，允许所有兼容更新，包括 <code>2.10.0、2.15.3，但拒绝3.0.0
注意：^1.0.0 和 ^0.9.0 行为完全不同——前者按 SemVer 主版本锚定，后者按次版本锚定（因为 0.x 被视为不稳定），容易踩坑。
PHP 版本约束必须和 platform 配合，否则 install 会翻车
你在 composer.json 里写 "php": "^8.2"，只是告诉 Composer “我需要 PHP 8.2+”，但它默认拿当前运行的 PHP 版本去校验。如果本地是 PHP 7.4，composer install 直接报错。
立即学习“PHP免费学习笔记（深入）”；
- 开发时想模拟目标环境？加
"config": {"platform": {"php": "8.2.10"}}，仅影响composer update解析依赖 - 部署时强制按某 PHP 版本安装？用命令行参数：
composer install --platform=php:8.2.10，它比config.platform优先级更高，且对install和update都生效 - 别混用：如果
composer.lock是用 PHP 8.3 生成的，又在 PHP 8.1 环境跑install，即使配了platform，也可能因扩展缺失失败——这时必须加--platform=ext-xxx:1.2.3补全扩展信息
依赖冲突时，why-not 比瞎猜管用十倍
执行 composer update 报错说无法解析依赖，别急着删 composer.lock 或降版本。先定位谁在挡路：
-
composer why-not vendor/package:1.5.0：列出所有阻止该版本安装的其他依赖及其约束 -
composer show vendor/package：看它自己声明了哪些 PHP/扩展要求，是否和你的平台配置对不上 -
composer depends vendor/package：查哪些包依赖它，改上游可能比硬顶下游更省事
常见陷阱是某个 dev-only 包（比如 phpunit/phpunit）带了宽松的 php: ^7.3 || ^8.0，却卡死了主应用升级到 PHP 8.3 的路径——这种得单独处理 require-dev 或用 --with-dependencies 精确更新。
锁定文件不是可选项，是上线前最后一道保险
composer.lock 不是缓存，是契约。只要它存在，composer install 就完全忽略 composer.json 里的约束符号，只装文件里记的 SHA 和版本号。
- CI/CD 流水线必须跑
composer install（不是update），否则每次构建都可能拉到不同版本 - 团队协作必须提交
composer.lock到 Git，否则“在我机器上好好的”问题必然复现 - Composer 2.5+ 开始，如果
composer.lock缺少composer.json声明的包，install直接失败——这是故意设计的保护机制，别绕过
真正难的不是写约束，而是在“足够灵活”和“绝对可控”之间找那个每天都要重新权衡的点。比如一个长期维护的 SaaS 后台，^ 可能带来安全补丁，但也可能引入未测接口变更；这时候 ~ 或精确版本 + 定期人工 update 反而更稳。
