Composer不支持HTTP缓存语义，仅认网络层代理或内网镜像源；必须同时配置http-proxy和https-proxy，且https-proxy值须以http://开头；项目级repositories会静默覆盖全局镜像配置。
Composer不支持HTTP缓存代理，只认网络层代理和镜像源
所谓“跨网络隔离域的缓存代理”，在 Composer 场景下实际只有两种可行路径：走 http-proxy/https-proxy 网络层代理（绕过防火墙），或切到内网镜像源（如 https://mirrors.tencent.com/composer/）。Composer 本身没有解析 Cache-Control、处理 ETag 或复用 304 的能力，它压根不理解标准 HTTP 缓存语义。
常见错误是把 Nginx 反向代理配成“缓存代理”后，发现 composer install 依然慢——那不是缓存没生效，而是 Composer 根本没走你配的 Nginx，它直连了 repo.packagist.org。必须明确：镜像源 ≠ 缓存代理，代理 ≠ 镜像源，二者不能混用，也不能共存。
http-proxy 和 https-proxy 必须同时配置，缺一不可
Composer 对协议硬隔离：http-proxy 只管 HTTP 请求，https-proxy 才负责建立 CONNECT 隧道转发 HTTPS 流量。而 packagist.org、GitHub 等全部走 HTTPS，漏掉 https-proxy 就等于让 HTTPS 请求裸奔进内网——结果就是卡在 Loading composer repositories，无报错、无超时、无日志。
-
https-proxy的值必须以http://开头，哪怕代理服务本身是 HTTPS；填https://或省略协议会静默失效 - 用户名或密码含
@、:、/时，必须用rawurlencode()编码，否则 URI 解析截断，报Invalid URI supplied - NTLM 认证代理原生不支持，必须前置
cntlm或px做中转，再让 Composer 连127.0.0.1:3128
镜像源配置被项目级 repositories 覆盖是高频静默故障
全局设了阿里云镜像，但某个租户项目仍连不上外网？大概率是它的 composer.json 里写了 "repositories": {"packagist.org": false} 或自定义了无效源。Composer 优先使用项目级配置，全局镜像会被完全忽略。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
排查方法很简单：
- 进项目目录执行
composer config --list | grep repositories.packagist.url，看输出是否为你预期的镜像地址 - 检查
composer.json是否含repositories字段；若有，删掉或显式重写为有效镜像："repositories": {"packagist.org": {"type": "composer", "url": "https://mirrors.aliyun.com/composer/"}} - 临时验证：运行
composer config --unset repositories（不加-g），再试composer install
Docker 构建中 vendor 层缓存失效，根源不在 Composer
CI 构建耗时暴涨、RUN composer install 总是重下包，问题通常不在代理或镜像，而在 Docker 构建层被破坏：只要 COPY . . 出现在 composer install 前，哪怕只改了一个空格，整个 vendor 层缓存就全丢。
真正起效的写法只有这一种顺序：
-
COPY composer.json composer.lock ./—— 必须最早、单独一行，且文件已提交 Git -
RUN composer install --no-dev --no-scripts --optimize-autoloader --prefer-dist—— 参数要锁死行为 -
COPY . .—— 放最后，并确保.dockerignore包含/vendor
BuildKit 的 --mount=type=cache 能加速下载，但解决不了 vendor 层复用问题；反而在 CI 多 job 并发时容易因 id 冲突导致依赖解析失败。更稳的做法是在 GitHub Actions 中用 actions/cache 缓存 ~/.composer/cache 目录。
