composer.lock 不该出现在 argocd 管理的 git 仓库里，因为它不是 kubernetes 声明式配置，而是 php 构建阶段的依赖快照，与集群运行时状态无关；argocd 只同步 yaml/json 资源清单，不解析或执行应用层构建逻辑。
Composer 的 composer.lock 文件不能直接交给 ArgoCD 同步到 Kubernetes 集群 —— 它不是声明式基础设施配置，也不参与集群状态收敛。
为什么 composer.lock 不该出现在 ArgoCD 管理的 Git 仓库里？
ArgoCD 监控的是 Kubernetes 资源清单（YAML/JSON），比如 Deployment、ConfigMap、Helm Chart values.yaml 或 Kustomize base/ 目录。而 composer.lock 是 PHP 应用构建阶段的产物，属于应用代码层依赖快照，和集群运行时状态无关。
常见误操作包括：
- 把整个 PHP 项目（含
vendor/和composer.lock）直接塞进部署仓库，当成“配置”提交给 ArgoCD - 在 Helm
templates/中硬编码composer install命令，指望 ArgoCD 在集群里执行它 - 把
composer.lock当作版本标识，用它触发 ArgoCD 同步（实际不会生效）
合规发布路径：composer.lock 只在 CI 构建阶段起作用
真正的依赖锁定必须发生在镜像构建环节，而不是 ArgoCD 同步环节。流程应该是：
- 开发提交代码 + 更新
composer.json→ 触发 CI 流水线 - CI 使用
composer install --no-dev --prefer-dist --optimize-autoloader生成确定性vendor/，并固化到镜像中 - CI 构建并推送带语义化标签的镜像（如
myapp:v1.2.3-php8.2） - 更新部署仓库中对应
Deployment.spec.template.spec.containers[0].image字段，指向新镜像 - ArgoCD 检测到 YAML 变更，同步该镜像版本到集群
此时 composer.lock 已完成使命：它只存在于 CI 构建上下文，不进入 GitOps 配置仓库，也不暴露在集群中。
多环境发布时如何保证依赖一致性？
不同环境（dev/staging/prod）必须使用同一镜像 ID，而非靠各自重新 composer install。否则会出现：
- Staging 环境用
composer install重装依赖，但网络波动导致拉取了不同 minor 版本的包 - Prod 环境因缓存或镜像 registry 权限问题，加载了旧版
vendor/ - ArgoCD 对比时无法感知这些差异 —— 因为它只看 YAML，不看容器内文件系统
正确做法是：
- CI 流水线为每次成功构建生成唯一镜像 digest（如
myapp@sha256:abc123...） - 部署仓库中所有环境的
image:字段都引用这个 digest，而非 tag - 必要时用 Helm 的
values.yaml或 Kustomizepatches区分环境配置，但绝不区分依赖安装逻辑
如果真要审计 PHP 依赖，该怎么做？
想追溯某次上线用了哪些 Composer 包？别指望 ArgoCD 日志。应该：
- 在 CI 构建阶段，把
composer show --format=json输出存为 artifact，并关联到镜像元数据（如 OCI annotations） - 用
cosign verify或notation list查验镜像签名时附带的 SBOM（软件物料清单） - 在 ArgoCD Application 页面的
Sync Status下点击具体资源，跳转到 Git 提交，再从该 commit 关联的 CI 流水线详情页查依赖报告
ArgoCD 不负责解释应用层依赖，它只忠实地把 Git 里的 YAML 变成集群里的对象。把 composer.lock 塞进部署仓库，等于让交通信号灯去管汽车发动机型号 —— 不在它的职责边界内。
