CI中执行composer update vendor/package-name仍全量更新，是因为漏写vendor/前缀或加引号导致命令失效而回退至全量；加--no-update-with-dependencies可禁用子依赖升级，但需确保当前子依赖版本已满足目标包新版本约束。
CI里执行composer update vendor/package-name为什么还是全量更新？
因为命令写错了。漏掉vendor/前缀（比如写成composer update monolog）会让Composer找不到匹配项，静默 fallback 到全量更新；加引号（"monolog/monolog"）在某些CI环境的shell中会被截断或忽略，等效于无参数执行。CI必须用裸包名：composer update monolog/monolog，不加空格、不加引号、不加任何额外开关。
如何确保只动目标包，不连带升级子依赖？
加--no-update-with-dependencies（Composer 2.2+ 支持）。它禁用目标包主动声明的子依赖升级，但前提是当前已安装的子依赖版本**已满足**该包新版本的require约束。否则会报Your requirements could not be resolved并中断——这不是命令失效，是依赖图本身不合法。
- 先查目标包依赖：
composer show monolog/monolog，看它的requires列表 - 再确认本地锁文件里对应子依赖版本是否兼容，例如
psr/log是否 ≥3.0.0 - 若不确定，先加
--dry-run预览：composer update monolog/monolog --no-update-with-dependencies --dry-run
CI流水线里怎么避免composer.lock被意外污染？
关键不是“跳过lock更新”，而是**控制更新入口唯一性**。CI应严格禁止composer update无参数执行；所有包升级必须走明确的composer update vendor/package-name，且每次只允许一个包。升级后立即git diff composer.lock检查变更范围：
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 只应出现
packages或packages-dev下该包名的version、source.reference、dist.shasum字段变化 - 如果
platform或platform-check块变了，说明用了--ignore-platform-reqs，生产CI严禁使用 - 发现无关包变动，立刻回退并查
composer why-not vendor/xxx定位冲突源
想升到特定版本，但CI不允许手动改composer.json？
那就不能用composer update。必须用composer require vendor/package-name:1.2.3 --update-with-dependencies——它会自动重写composer.json并触发更新。注意两点：
-
require命令在CI中本质是“新增包”，若该包已存在，它会先卸载旧版再装新版，可能触发不必要的autoload重建 - 务必加
--update-with-dependencies，否则子依赖版本可能不匹配新主包，导致安装失败 - 上线前必须验证
composer.lock里该包的version字段是否真为1.2.3，别只信终端输出
真正难控的从来不是命令怎么写，而是目标包的require声明和当前composer.lock里其他包的约束之间是否咬合得上——这点在CI里没法绕开，只能靠composer show和composer why-not提前暴露。
