真正锁定依赖需在composer.json中写死三位号如"monolog/monolog": "2.11.0"，执行composer update monolog/monolog更新lock文件，提交composer.lock至Git，并在部署时仅运行composer install；缺一不可。
Composer 锁定依赖，靠的不是 composer.lock 文件本身，而是 composer.json 里写死的纯数字版本号 + composer.lock 提交进 Git + 部署时只跑 composer install —— 少一个环节，锁定就失效。
composer.json 里怎么写才算真正锁定
必须用无修饰符的三位点号版本，比如 "monolog/monolog": "2.11.0"。任何带 ^、~、*、dev-、@dev 的写法都不算锁定。
-
"monolog/monolog": "^2.11"→ 允许升到2.12.0，甚至2.99.9 -
"monolog/monolog": "2.11"→ 行为不一致：Composer 2.0+ 解析为2.11.0，旧版可能当2.11.x处理，别赌 -
"monolog/monolog": "2.11.0 as 2.11.0"可以，但没必要；"2.11.0"就够了
改完 composer.json 后必须立刻执行什么命令
只改 composer.json 不运行命令，等于没改。必须立即执行 composer update monolog/monolog（指定包名）。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 不能只跑
composer update（无参数）：它会重新解析整棵树，可能连带升级其他包 - 不能删掉
vendor再跑composer install：如果composer.lock还没更新，install 仍会装旧版 - 验证是否生效：
composer show monolog/monolog输出应为2.11.0；再跑一次composer update monolog/monolog，若提示Nothing to install or update，才算锁住
为什么 composer.lock 不是“开关”，而只是快照
composer.lock 本身不执行任何逻辑，它只是记录当前依赖树的快照：每个包的精确 version、dist.sha256、安装路径、完整依赖链。它起作用的前提是——你用 composer install 来读它。
- CI 或新同事执行
composer install时，完全忽略composer.json的约束，只认lock里的版本 - 如果
composer.lock被删或没提交 Git，composer install就退化成按composer.json重解析，哪怕你写了"2.11.0"，也可能装上2.11.1（尤其镜像源缓存了新版本） -
composer install --locked是上线前最后一道保险：它校验lock里每个版本是否仍满足composer.json的约束，不满足直接报错退出，不让你稀里糊涂上线
临时跳过某个包更新的实操方式
这不是长期锁定，而是单次操作绕过。适用于调试兼容性问题或 CI 中临时压制某包变更。
- Composer 2.2+：用
composer update --ignore=laravel/framework，跳过该包及其子依赖的更新检查 - 兼容旧版：显式列出要更新的包，漏掉那个就行，例如
composer update symfony/console phpunit/phpunit - 注意：
--ignore不解除依赖校验——如果其他包在composer.json中硬性要求monolog:^3.0，仍会冲突报错 - 别信
composer update --lock：它只重写 lock 文件结构，不改变已安装包，也不防下次 update
最容易被忽略的其实是「闭环」：改 composer.json → 运行 composer update 包名 → 检查 composer.lock 和 composer show 输出一致 → 提交 lock 到 Git → 部署时只用 composer install。断在任意一环，锁定就形同虚设。
