唯一正解是 composer update vendor/package-name，必须写全命名空间如 monolog/monolog；不加参数时仅更新该包及其子依赖，非全量更新；常见错误包括缺 vendor 前缀、误用不存在的 --only 选项或忽略 --dev 参数。
composer update vendor/package-name 是唯一正解
想只更新单个包，必须显式写出完整命名空间，比如 composer update monolog/monolog。不加任何参数时，它不会升级其他根级依赖，但会检查并可能更新该包的子依赖——这是 Composer 的默认行为，不是 bug，也不需要加 --only（这个选项根本不存在）。
常见错误包括：composer update monolog（缺 vendor 前缀，报错）、composer update --only monolog/monolog（命令行拒绝识别）、或直接运行 composer update（全量更新，非你所要）。
- 包名必须和
composer.json中require或require-dev字段完全一致，大小写敏感 - 如果包只在
require-dev里，得加--dev参数，否则提示 “Package not found in composer.json” - 执行前确保本地已
git pull对应分支（尤其用dev-xxx别名时），否则 Composer 找不到新 commit
为什么 lock 文件里多了几行变动？
composer.lock 变动范围比预期大，不一定代表其他包被升级了。常见原因有：
- PHP 版本或扩展（如
ext-intl）声明变了，触发平台兼容性重计算，导致无关包的 hash 更新 - 目标包的新版本放宽了子依赖约束（例如从
"psr/log": "^1.1"改成"^1.0 || ^2.0"），Composer 自动拉取了满足条件的更高版 -
composer.lock文件本身有损坏（比如手动编辑引入不可见字符、缩进错乱），导致解析降级为宽松模式
验证方式：用 git diff composer.lock 看哪些包的 version 或 source 字段真变了；没变的只是 dist.shasum 或 platform 相关字段，基本可忽略。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
--dry-run 和 --no-update-with-dependencies 的实际用途
这两个参数不是“锦上添花”，而是防止翻车的关键开关：
-
composer update monolog/monolog --dry-run：预览将变更哪些包，重点关注输出中有没有非预期的Updating xxx行。有就别直接跑，先查子依赖约束 -
--no-update-with-dependencies（Composer 2.2+）：真正禁用子依赖更新，但前提是当前composer.lock中子依赖版本已满足目标包的新要求，否则报 conflict 错误，不妥协 -
--with-all-dependencies是反向操作——它会递归升级所有层级依赖（含require-dev里的），慎用，除非你明确要重刷整条依赖链
别信 --no-update，它让 update 命令变成空操作，既不改 vendor 也不重算 lock，毫无意义。
更新后最易忽略的环节
命令成功返回不代表万事大吉。真正的问题往往出现在运行时：
- 目标包 API 有破坏性变更（比如方法签名改了、类被 deprecated），而你的调用代码没同步改，测试不覆盖就上线，等报错才发觉
- 子依赖虽未升级，但新版本对 PHP 小版本有更严要求（如从 8.1 升到仅支持 8.2+），CI 环境没对齐就失败
- 用了
path类型仓库，composer update不会自动同步本地代码变更，得手动rm -rf vendor/myorg/mylib && composer install
建议更新后立刻跑 composer show monolog/monolog 确认版本，并快速过一遍该包被调用的核心路径，比盯着终端输出是否带 OK 有用得多。
