composer 不支持本地代理缓存中间件，其 http-proxy/https-proxy 仅作网络出口路由，镜像与代理不可共存，唯一原生缓存是 ~/.composer/cache 磁盘缓存，ci 必须缓存该目录并严格同步 composer.json 与 lock 文件。
Composer 没有“本地代理缓存中间件”这种东西，它不支持 HTTP 缓存代理（如 Squid、Nginx proxy_cache），也不提供可插拔的中间件机制来拦截或缓存包请求。所谓“镜像 + 代理 + 缓存”的混合方案，本质是混淆了三个独立层级：网络代理、源站镜像、本地磁盘缓存——它们不能嵌套，也不能共存生效。
composer config -g http-proxy 和 https-proxy 是什么
这是 Composer 的网络层代理配置，仅用于绕过防火墙或访问限制，不是缓存机制：
- 只影响 cURL 请求的出口路由，不保存响应、不复用 304、不解析 Cache-Control
-
http-proxy控制 HTTP 协议流量，https-proxy控制 HTTPS 流量——两者必须同时设置，否则部分请求直连超时 - 代理地址必须用
http://协议（即使目标是 HTTPS），且用户名密码需rawurlencode()处理特殊字符，例如pa@ss:word要写成pa%40ss%3Aword - 验证是否生效：运行
composer clear-cache && composer require monolog/monolog -vvv，在日志里搜Downloading，确认 URL 前缀是代理地址，而非https://packagist.org
镜像源（mirror）和代理不能共存
一旦你设置了 repo.packagist.org 的镜像 URL，Composer 就直接连接该镜像站点，完全跳过代理链路：
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 阿里云、腾讯云等镜像本质是 Packagist 元数据 + 包文件的完整同步副本，不是反向代理
- 配置
composer config -g repo.packagist.org url https://mirrors.aliyun.com/composer/后，再留着http-proxy可能导致 TLS 不匹配或 DNS 解析异常 - 团队内网自建镜像（如
https://mirror.internal.company.com）才是真·可控方案：它把外部不确定性收束为一次内网 HTTP 请求，CI 构建失败率下降 90% 以上 - 项目级镜像配置比全局更可靠——尤其当 CI 使用 runner 用户执行时，
-g配置可能根本读不到
真正起作用的是 ~/.composer/cache 目录
这才是 Composer 唯一原生支持的“缓存”，但它纯属本地磁盘缓存，与代理或镜像无关：
- 缓存分两层：
files/存下载的 .zip/.tar.gz 包，repo/存 packages.json 等元数据 - CI 中必须启用
actions/cache或类似机制缓存~/.composer/cache，否则每次构建都重下 - 私有 Git 包频繁更新时，别依赖
composer update自动拉取——应显式指定dist地址并禁用source克隆，否则会卡在 git clone -
--prefer-dist是默认行为，但某些私有包若未发布 dist，Composer 仍会 fallback 到 source，此时需在repositories中强制声明"dist": {...}
敏捷流程中最容易被忽略的原子性问题
每次功能提交必须同时包含 composer.json 和 composer.lock 的变更，否则：
- 只改
composer.json不提交 lock → 同事composer install拉到的版本和你本地不一致 - 只提交 lock 文件没说明升级原因 → 无法追溯为何引入某个次版本，CI 失败后排查成本翻倍
- 在
post-update-cmd中执行耗时脚本（如打包前端、生成文档）→ 表面composer update成功，实则阻塞后续 CI 步骤，且错误日志被吞掉 -
require-dev包误入生产环境：CI 必须用composer install --no-dev --optimize-autoloader，而不是靠删掉--no-dev
