composer install只装lock文件里写的版本，因其完整锁定整棵依赖树（含所有传递依赖）的精确版本、源类型和校验哈希，跳过解析直接还原；缺失lock则退化为update，触发不可控的CSP求解。
Composer 管理复杂层级的传递依赖，核心不是“手动处理”，而是靠依赖解析器自动构建并收敛依赖树——只要版本约束合理、锁文件存在，它几乎不让你操心中间层。
composer install 为什么只装 lock 文件里写的版本
因为 composer.lock 不只是记录你直接 require 的包，它完整保存了整棵树：根项目 → 直接依赖 → 传递依赖 → 传递依赖的传递依赖……每一层的包名、版本号、源类型（dist/git）、校验哈希全在。执行 composer install 时，Composer 跳过解析，直接按 lock 文件逐个下载安装。
- 没有
composer.lock？composer install会退化为composer update，触发完整解析 - lock 文件被删或损坏？你会看到
Package "foo/bar" is not present in the lock file错误 - 团队协作中漏传 lock 文件，CI 环境可能装出和本地不一致的传递依赖，引发
Class not found或行为差异
composer update 怎么决定该装哪个传递依赖版本
它跑的是一个约束满足问题（CSP）求解过程：把所有 require 字段（包括各层 composer.json 里的）转成逻辑条件，再用回溯算法找一组满足全部条件的版本组合。不是“取最新”或“取最早”，而是“唯一可行解”。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 例如：
monolog/monolog要psr/log ^2.0，symfony/console要psr/log ^1.0 || ^3.0，Composer 可能选psr/log 3.0.0—— 因为 2.x 不满足后者，1.x 不满足前者 - 如果某包声明了
"conflict": {"psr/log": "，那即使其他包都兼容 2.x，Composer 也会报错退出 - 运行
composer update --dry-run可预览哪些传递依赖会被升级，避免盲更
怎么查清某个传递依赖是从哪来的
靠 composer depends 和 composer show --tree，而不是翻 vendor 目录或猜。
-
composer depends psr/log：列出所有直接或间接依赖psr/log的包，含版本约束，一眼定位冲突源头 -
composer show --tree myproject/app：从根项目展开完整依赖树，缩进显示层级，├── monolog/monolog v3.5.0下面跟着它的子依赖 -
composer why-not psr/log:2.99.0：若你想强制装某个版本但失败，它会告诉你“因为 symfony/console requires ^3.0”
真正容易被忽略的点是：传递依赖的版本不是静态的，它随你每次 composer update 重算——哪怕你没动 composer.json，只要上游包发了新版本且约束宽松（比如用了 ^3.0），它的子依赖就可能悄悄升级。所以别跳过 composer.lock，也别在生产环境跑 composer update。
