composer install必须读composer.lock，因其设计目标是“复现已有环境”，只读取lock中记录的精确版本、拉取对应zip并解压到vendor，确保结果100%确定；无lock时会退化为不生成lock的update，导致环境不一致。
composer install 为什么必须读 composer.lock
因为 composer install 的设计目标就是「复现已有环境」——它完全跳过版本解析，只做三件事：读 composer.lock 里记录的包名和精确版本号、从缓存或远程拉取对应 zip、解压到 vendor。只要 lock 文件存在且完整，结果就 100% 确定。
常见错误现象是：CI 脚本里误写成 composer update，导致每次构建装的依赖版本都可能不同；或者团队没把 composer.lock 提交进 Git，新人 install 时实际触发了 update 行为（因无 lock），但不生成新 lock，后续协作全乱套。
- 没有
composer.lock时，composer install会退化为composer update，但不生成 lock 文件——这是隐性风险点 -
composer install --no-dev在生产环境必须加，否则会装测试用的 dev 依赖（如 phpunit），增大部署体积且可能引入安全面 - 如果
composer.lock和composer.json冲突（比如有人改了 json 却没提交 lock），composer install直接报错Your lock file does not contain a compatible set of packages，不能绕过，必须先对齐
composer update 实际在做什么
composer update 不是“升级某个包”，而是重跑整套依赖求解器：它丢掉 composer.lock，回到 composer.json 的版本约束（比如 "guzzlehttp/guzzle": "^7.0"），然后递归检查所有可用版本、PHP 版本兼容性、扩展要求、子依赖冲突……这个过程是 NP-hard 级别的计算，耗时长、结果不可预测。
哪怕只是从 guzzlehttp/guzzle v7.5.0 升到 v7.6.1，也可能因为内部方法签名变更、默认行为调整（比如重试策略变严格）导致线上请求失败。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
-
composer update monolog/monolog看似只更新一个包，实则会连带更新其全部子依赖（如psr/log），不是“只动这一行” -
composer update --dry-run必须先跑，看清它打算装哪些版本，再决定是否执行 - 安全补丁场景下，优先用
composer update --with-all-dependencies，而不是全量update，避免无关包被意外升级
什么时候该用 composer require 而不是 update
日常开发中新增依赖，别直接 composer update，用 composer require——它本质是受控的 update：只处理你指定的包，自动写入 composer.json 和 composer.lock，不会波及其他依赖。
比如要加 spatie/laravel-backup，运行 composer require spatie/laravel-backup 就够了；如果硬写 composer update spatie/laravel-backup，反而可能把 illuminate/support 这类底层包也顺手升了，引发兼容问题。
-
composer require "package/name:^3.0"可指定版本约束，比 edit json + update 更安全 - 移除包用
composer remove package/name（Composer 2.2+），它会同步清理composer.json和composer.lock，比手动删再update少出错 - CI/CD 流水线里绝对禁止出现
composer update，只允许composer install --no-dev
lock 文件没提交会导致什么后果
这是团队协作中最常踩的坑：composer.lock 被 .gitignore 误屏蔽，或新人 clone 后直接 composer install，结果装的是本地缓存里最老的兼容版本，跟主分支实际运行环境不一致——测试通过，上线就炸。
更隐蔽的是：有人 composer update 后忘了 git add composer.lock，其他人 install 时发现 lock 和 json 对不上，报错卡住，但没人知道到底该信谁的版本。
-
composer.lock必须和composer.json一起提交，且不能设为可选 - Git 钩子或 CI 检查可以加一条：
git diff --quiet HEAD composer.lock || echo "lock file changed, please commit it" - 如果项目历史里长期没管 lock，建议一次性
composer update --lock（仅重写 lock，不重装），再提交，把版本对齐拉回正轨
