Composer仅负责PHP依赖管理，不参与云原生配置或Sidecar集成；其正确用法是在构建阶段执行composer install --no-dev --optimize-autoloader，运行时通过环境变量读取Sidecar地址，严禁运行时执行composer update。
Composer 本身不管理云原生应用的运行时配置，也不直接参与 Sidecar 模式集成——它只负责 PHP 依赖的解析、下载与自动加载。把配置管理或容器协作逻辑塞给 composer.json，会踩进设计边界错误的坑。
Composer 的配置能力仅限于 PHP 项目自身
它能通过 extra 字段存任意键值，也能用 scripts 触发命令（比如生成 config 文件），但这些都发生在构建阶段，且只影响当前 PHP 应用进程。它无法：
- 向 Kubernetes Pod 注入环境变量
- 修改 Sidecar 容器的启动参数
- 读取 ConfigMap / Secret 或与 etcd 交互
- 控制容器网络拓扑（如 localhost 通信）
真正的配置注入必须由平台层完成：K8s 的 envFrom、Docker Compose 的 environment、Azure App Service 的应用设置，才是正确出口。
Sidecar 模式下 Composer 的合理定位
在 Sidecar 架构中（例如业务容器 + wecom-sidecar），Composer 只应在主 PHP 容器内使用，且需满足：
- composer install --no-dev --optimize-autoloader 必须在构建镜像时执行，而非运行时
- composer.lock 必须提交到仓库，确保各环境依赖完全一致
- 若主容器需调用 Sidecar（如 http://localhost:8080/send），该 URL 不应写死在 composer.json 或包内，而应通过 getenv('WECOM_SIDECAR_URL') 读取环境变量
- 私有包仓库（如 GitLab Package Registry）的认证凭据，不能明文写进 auth.json 提交，应通过 CI/CD 的 secret 注入或挂载为只读 volume
容易被忽略的构建与运行时分离点
很多人试图让 Composer 在容器启动时执行 composer update，这在云原生环境是危险操作：
- 镜像不可变性被破坏，违反 OCI 标准
- 启动延迟不可控，触发 K8s liveness probe 失败
- 无网络或私有源不可达时，容器直接 CrashLoopBackOff
正确做法是：所有依赖在 CI 流程中通过 composer install 锁定并打包进镜像；运行时只做轻量初始化（如 symlink 配置、chown 日志目录）。Sidecar 的健康检查、重试、熔断等，也必须由其自身实现，而非指望 Composer 插件来兜底。
