微服务部署必须用composer install锁定依赖，而非update；lock文件是主动控制的产物，需严格校验存在性、提交状态及版本精确性（如"2.9.1"而非"^2.9"），CI/CD中禁用update，部署固定使用--no-dev等参数确保一致性。
微服务部署流水线里，composer.lock 不是“自动生成”的结果，而是你主动控制的产物——只要流程里漏掉一个环节，它就会失效。
composer install 才算真正锁定，不是 composer update
CI 脚本里写 composer update，等于把所有依赖重新解析一遍，composer.lock 形同虚设。微服务对版本敏感，一次 update 可能带进不兼容的 patch 版本（比如 guzzlehttp/guzzle 从 7.5.0 升到 7.5.1，但某个 SDK 内部用了被移除的私有方法）。
- 流水线第一步必须检查
composer.lock是否存在且未被.gitignore忽略 - 部署命令固定为
composer install --no-dev --no-interaction --no-progress - 禁止在生产机上装 Composer 或执行任何
composer命令；打包阶段就该完成 vendor 目录构建
精确版本号必须写死在 composer.json 中
"monolog/monolog": "^2.9" 看似指定了主版本，实则允许安装 2.9.x 全系列，不是锁定。微服务之间共享基础包时，这种“浮动”会引发跨服务行为不一致。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 真正锁死只有一种写法：
"monolog/monolog": "2.9.1"（纯数字字符串，无^、~、*） - 用
composer require monolog/monolog:2.9.1添加依赖，比手动改 JSON 更可靠（避免空格、v前缀等隐性错误） -
require-dev里的包同样要写死，否则composer update会升级phpunit/phpunit导致测试环境与生产不一致
改了 composer.json 后必须同步更新 lock 文件
微服务镜像构建时若只改了 composer.json 但没跑 composer update，composer install 仍会装旧版——因为 install 完全忽略 json 里的新约束，只认 lock 里的记录。
- 推荐做法：
composer update monolog/monolog --no-dev（只更新目标包，避免连带升级其他依赖） - 验证是否生效：
composer show monolog/monolog，看输出的versions行是不是你想要的完整版本字符串 - 提交前检查
composer.lock：搜索包名，确认"version"字段和"source"."reference"都已更新
最容易被忽略的是：composer.lock 提交到 Git 后，CI 脚本却仍调用 update；或者本地开发时删了 lock 文件再 install，相当于重走依赖解析流程。微服务环境下，这些操作带来的版本漂移很难回溯。
