精确锁定某包用=版本号（如"guzzlehttp/guzzle": "=7.8.1"），只升指定包用composer update vendor/package，多包联动升级用composer update a b --with-dependencies，冲突时用composer why-not定位。
想精确控制某个包不升级、只升某几个、或联动升一组？靠模糊约束（比如^2.0）或凭感觉运行composer update，迟早出问题。真正起效的，是组合使用composer.json里的版本写法 + 命令参数 + composer.lock的提交规范。
用=版本号语法彻底锁死单个包
这是最硬核、最无歧义的锁定方式。它不参与语义化版本计算，也不响应任何自动升级逻辑。
-
"guzzlehttp/guzzle": "=7.8.1"—— 只认这个 exact 版本，7.8.2或7.9.0都不会装 - 别用
"7.8.1"（没等号），它等价于^7.8.1，仍允许 patch 升级；也别用~7.8.1，它允许到7.9.0之前的所有版本 - 如果该包是间接依赖（比如被
laravel/framework拉进来的），必须在根composer.json中显式声明并加=，否则约束不生效 -
composer outdated仍会显示有更新，但composer update不会应用——这不是 bug，是设计行为
只更新指定包，避免连锁反应
目标明确时，直接传包名给composer update，它是默认最保守的行为。
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
-
composer update monolog/monolog—— 只更新该包及其**显式声明的子依赖**（如它 require 的psr/log），其他包完全不动 - 千万别加
--with-dependencies或--with-all-dependencies，除非你真需要联动升级；加了就可能把symfony/polyfill-php80这类共用包也拉高，引发兼容问题 - 如果要同时升两个包，写成
composer update monolog/monolog guzzlehttp/guzzle，不要用引号、不要带版本号、不要空格混用逗号 - 执行前检查
git status，确保composer.lock没被意外修改；升级后必须提交新 lock 文件，否则协作环境不一致
多包联动升级时控制求解边界
当多个包存在隐性依赖耦合（比如都依赖 psr/cache，但各自要求不同版本），需主动扩大求解范围，但不能失控。
-
composer update a/package b/package --with-dependencies是黄金组合：它把目标包 + 它们各自直接 require 的包一起放进 SAT 求解器，解决“半升不升”导致的运行时报错 -
--with-all-dependencies会把整个依赖树纳入重算，但依然受composer.json中约束限制（比如"^9.0"不会升到 v10），只是耗时更长，CI 中建议加超时保护 - 遇到冲突别猜，用
composer why-not vendor/package:^x.y查完整阻塞链，输出类似：myapp requires vendor/package (>=6.0) → foo/bar requires vendor/package ( - 所有联动操作的前提是团队共用同一份已提交的
composer.lock，否则求解起点就不一致
CI/CD 中防止意外升级的关键配置
线上构建最怕依赖悄悄变，光靠写法不够，命令参数和流程必须卡死。
- Docker 构建中，
COPY composer.lock .必须在composer install之前，且路径正确；漏掉或顺序反了，install就退化为update - CI 脚本里必须加
--no-interaction --prefer-dist --no-progress --no-updates，其中--no-updates是防升级的核心开关，它强制跳过 lock 文件同步逻辑 - 如果项目用了
replace声明虚拟包（比如用自研 fork 替代原版），记得在 CI 中验证composer show输出是否真的没装被 replace 的包 -
composer.lock被 git 忽略、或未提交、或合并时手动删了冲突标记——这三类操作在生产部署中出现一次，就足以让“稳定环境”变成“随机故障现场”
