微服务集群必须用composer install而非update，因其严格按composer.lock安装固定版本，确保各服务SDK（如auth-sdk）版本一致，避免JWT解析异常等静默故障；update会重算依赖引发版本漂移。
composer install 不是“装依赖”的通用命令，而是微服务部署链里必须卡死的确定性动作——它只认 composer.lock，拒绝任何版本漂移。
为什么微服务集群里必须用 composer install 而不是 update
微服务强调各子系统独立演进、独立部署，但底层 SDK（如统一认证 client、日志上报包、配置中心适配器）必须版本一致。一旦某个服务执行 composer update，就可能把 auth-sdk 从 2.1.3 升到 2.2.0，而其他服务还锁在 2.1.3，结果就是 JWT 解析字段名不一致、traceId 透传丢失等静默故障。
-
composer install严格按composer.lock安装，哪怕composer.json里写的是"auth-sdk": "^2.1"，它也只装 lock 文件里记录的2.1.3 -
composer update会重新解析依赖树，触发版本重算——这在开发期调试可以，在 CI/CD 流水线或线上发布时等于主动引入不确定性 - 多语言网关（如 Kong、APISIX）后接 PHP 微服务时，若某服务因
update引入了新扩展依赖（如ext-igbinary），而网关容器没装该扩展，直接 502
composer install 卡在 “Loading composer repositories” 怎么破
这不是命令错了，是默认走 packagist.org 的 CDN 在国内超时。微服务通常有数十个子项目并行构建，一个卡住就拖慢整条流水线。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 别改每个项目的
composer.json的repositories字段——团队协作时容易覆盖冲突，且镜像地址硬编码后无法随环境切换 - 全局配置阿里云镜像：
composer config -g repos.packagist composer https://mirrors.aliyun.com/composer/ - CI 环境建议加环境变量兜底：
COMPOSER_REPO_PACKAGIST=https://mirrors.aliyun.com/composer/ - Docker 构建阶段可提前注入：
RUN composer config -g repos.packagist composer https://mirrors.aliyun.com/composer/，避免每次 RUN 都卡住
生产服务器上能不能跑 composer install
能，但不该——尤其当你的微服务跑在无状态 Pod 或 Serverless 环境里时，直接在运行时安装等于把构建风险搬进生产。
- 服务器常缺 Composer 运行环境（比如只有
php-fpm镜像，没装php-cli和unzip） -
composer install需要写vendor/和生成autoload_*.php，而生产目录往往权限受限（www-data不能写 webroot） - 如果
composer.lock里声明了"ext-redis": "*"，但服务器没装 redis 扩展，错误提示是模糊的Your requirements could not be resolved，而非明确指出缺扩展 - 正确做法：在 CI 构建阶段用与生产一致的 PHP 镜像（如
php:8.2-cli-slim）执行composer install --no-dev --optimize-autoloader --classmap-authoritative，然后把整个vendor/打包进镜像
微服务间 SDK 版本不一致怎么强制对齐
靠人工盯 composer.lock 文件不现实。真正可控的方式是把公共 SDK 声明为“平台约束”，让 Composer 在解析阶段就报错。
- 在根
composer.json里加"platform": {"php": "8.1.0", "ext-redis": "5.3.7"}，比写"php": "^8.1"更精准，避免因 minor 版本差异导致symfony/cache选用不同驱动 - 所有微服务的
composer.json都继承同一份私有仓库配置："repositories": {"my-sdks": {"type": "composer", "url": "https://pkgs.internal.company.com"}}，确保auth-sdk、config-client等只从内部源拉取 - CI 流水线加检查脚本：对比各子服务
composer.lock中指定 SDK 的 version 字段是否完全一致，不一致则阻断发布 - 注意：不要用
composer require --update-with-dependencies强制升级——它会连带更新 SDK 的间接依赖，可能破坏兼容性
微服务不是把单体拆开就完事，而是把依赖契约钉死在 lock 文件里；composer install 就是那个锤子——敲下去之前，得确认所有钉子（SDK 版本、PHP 平台、扩展约束）都已对齐，否则一锤下去，松动的是整个服务网格。
