composer install不解析版本约束，仅严格按composer.lock中记录的精确版本、哈希值和依赖树还原安装；缺失或损坏lock文件时才退化为composer update行为，启动sat求解器重新解析^、~等约束并生成新lock。
composer install 不看版本约束，只认 composer.lock；真正解析 ^、~、>= 这些符号的，只有 composer update。
composer update 才真正执行版本约束解析
很多人改完 composer.json 里的 "monolog/monolog": "^3.0" 就直接跑 composer install，结果装的还是 2.x —— 因为 install 完全不读这些符号，它只照着 composer.lock 里记录的精确版本还原。只有 update 启动 SAT 求解器，把所有 require、conflict、PHP 版本要求一起建模求解。
-
composer update会重新生成composer.lock，覆盖原有记录 -
composer update monolog/monolog只更新该包及其子依赖，不碰其他已锁定项 - 加
--with-all-dependencies才会让间接依赖也参与重算（比如你升级 laravel/framework，它带进来的 symfony/* 也可能被连带调整）
^ 和 ~ 的锚定逻辑完全不同，不是“松紧程度”差异
^1.2.3 和 ~1.2.3 看似接近，但它们锁的是不同坐标：前者锚定主版本（MAJOR），后者锚定你写到的最左非零段（即第三位 PATCH 所在层级）。这直接决定哪些版本能过筛。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
-
^1.2.3→>=1.2.3 && ：允许升到 <code>1.99.99，只要主版本还是 1 -
~1.2.3→>=1.2.3 && ：卡死次版本为 2，只放行修订号（PATCH）变动 -
^0.8.2和~0.8.2都只到0.8.x，但原因不同：^因 SemVer 规定 0.x 的 MINOR 升级视为 breaking，自动降级为仅 PATCH；~则是锚点落在第二位（8），自然只放开第三位 -
^0.0.3锁死到0.0.3（不允许任何升级），而~0.0.3允许升到0.0.999
星号 * 在版本约束中非法，别试
"monolog/monolog": "1.*" 或 "^1.*" 会直接报 Invalid version string。Composer 不支持 shell 式通配符，* 唯一合法位置是分支别名（如 dev-main），且此时 ^/~ 失效。
- 想匹配所有 1.x 版本？写
"^1"（等价于>=1.0.0） - 想匹配所有 1.2.x？写
"^1.2"或"~1.2"，不是"1.2.*" - 分支开发时用
"dev-main"可以，但上线前必须切回稳定标签或提交哈希，否则部署不可控
锁文件缺失或损坏时，install 会退化为 update 行为
没有 composer.lock 或它校验失败（比如手动编辑后哈希不匹配），composer install 就不再“还原”，而是启动完整解析流程——这时才真正读 composer.json 里的约束，也才可能报出 Your requirements could not be resolved。
- CI 构建失败但本地正常？先
cat composer.lock | grep php，确认锁文件里记录的 PHP 最低版本和你当前环境一致 - 同事装完能跑，你装完 Class not found？大概率是 Composer 版本不同（如 2.4.3 vs 2.5.0），SAT 求解器在相同
composer.json下选出了不同的子依赖版本 - 团队必须提交
composer.lock，且禁止手动编辑——它是协作契约，不是缓存
真正容易被忽略的点是：约束生效的前提，永远是 lock 文件被正确生成并提交；而一旦你依赖了 0.x 的包，^ 的“兼容”承诺就形同虚设，必须查 CHANGELOG 或 issue 确认变更是否安全。
