composer install严格按composer.lock安装以确保环境一致，缺失lock则报错或退化为update；composer.update忽略lock，重解析composer.json并更新所有依赖。
Composer 依赖管理的核心就三件事：声明、安装、锁定。不理解 composer.json 和 composer.lock 的分工，迟早会在部署或协作时出问题。
为什么 composer install 和 composer update 不能混用
这两个命令行为完全不同，不是“换种写法”，而是面向不同场景：
-
composer install只看composer.lock—— 如果 lock 文件存在，它会严格按里面记录的版本号（包括子依赖的精确哈希）安装，确保所有环境一致；没有 lock 文件时才退回到解析composer.json并生成新 lock。 -
composer update直接忽略 lock 文件，重新根据composer.json中的版本约束（如^7.0或~2.4）计算最新兼容版本，更新所有依赖并重写 lock 文件。 - CI/CD 流水线或生产部署必须用
composer install；开发中加新功能或主动升级才用composer update，否则容易把线上跑得好好的版本意外升掉。
composer require 添加依赖时的隐含动作
执行 composer require guzzlehttp/guzzle:^7.5 不只是下载包，它会连锁触发四件事：
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 修改
composer.json的require字段，加入该包及指定版本约束； - 立即执行一次
composer update行为（仅针对这个包及其子依赖），而非install； - 更新
composer.lock，记录实际安装的完整版本树； - 刷新
vendor/autoload.php，让新类能被自动加载——但不会自动帮你写use语句或调用代码。
注意：composer require 默认添加到 require（生产依赖），如需只在开发时用（比如 PHPUnit），得加 --dev 参数，否则会把测试工具打进生产包。
本地开发和 CI 环境必须共用 composer.lock
这个文件不是“可选缓存”，而是依赖一致性契约：
- Git 提交时必须包含
composer.lock，否则队友composer install装出来的版本可能和你本地不同； - Docker 构建或 GitHub Actions 中，如果只拷贝
composer.json却漏了 lock 文件，composer install就会退化成update，导致构建结果不可复现； - 运行
composer install --no-dev时，lock 文件里仍保留 dev 依赖信息，只是跳过安装——所以删 lock 再装，和保留 lock 再加--no-dev，行为不等价。
最容易被忽略的一点：当你改了 composer.json 但没运行任何命令，那些改动根本不会生效；composer.lock 才是真实生效的依据。别信“我改了 require 就等于加了依赖”，没跑命令=没发生。
