“Composer反向代理”是伪命题，因Composer无反向代理模块，仅支持通过repo.packagist配置元数据镜像（如阿里云），该镜像为正向缓存代理，不接管ZIP包下载；包文件仍按composer.lock中原始dist.url下载，且安全依赖signature字段校验，需同时满足secure-http: OK和signature verification: OK才生效。
为什么“Composer反向代理”是个伪命题
Composer 本身不支持、也不需要你去配“反向代理”。它没有反向代理模块，也不接受 Nginx 或 Traefik 那类中间层转发请求。所谓“Composer 反向代理配置”，实际是混淆了两个完全不同的角色：packagist.org 是元数据源（只返回 packages.json 等清单），而 GitHub、GitLab 等才是包文件（.zip）的真实下载地址。你真正能干预的，只有 Composer 请求元数据时走哪个镜像 URL——这个镜像本身是正向缓存代理，不是你搭在本地的反向代理服务。
composer config -g repo.packagist https://mirrors.aliyun.com/composer/ 的真实作用
这条命令只是把元数据请求从 https://repo.packagist.org/ 指向阿里云镜像，但后续所有包文件下载仍默认走原始 dist URL（比如 GitHub 的 https://api.github.com/repos/.../zipball/...）。也就是说：
- 镜像只加速
packages.json、provider-*.json这类元数据拉取，不接管 ZIP 文件下载 -
composer.lock里记录的dist.url字段不会被镜像改写，删 lock 后重装才会触发新 URL 获取 - 若镜像未同步 signature 字段（如旧版 Laravel China 镜像），
composer diagnose会显示signature verification: FAIL，安全校验自动降级
想真正控制 ZIP 下载路径？只能改 composer.json 或用 --repository
要让 Composer 从你指定的地址下载 ZIP 包（比如内网 Satis、Toran 或 ghproxy），必须显式干预 dist URL。方式有两种：
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 项目级：在
composer.json的repositories数组中添加 type=package 条目，并手动写死dist.url，适用于私有包或高频更新包 - 临时覆盖：运行
composer install --repository=https://your-internal-mirror.com/，但该参数只影响元数据获取，对已锁在composer.lock中的 dist URL 完全无效 - 注意：
--repository-url是无效参数名，正确写法是--repository=（带等号）
企业自建镜像最常踩的坑：HTTPS + signature 校验断链
很多团队部署了 Satis 或 Toran，却忽略关键三点：
- 必须开启
security.signature true（composer config -g security.signature true），否则不校验签名 - 镜像服务必须原样透传 packagist.org 响应头中的
X-Content-Signature，不能丢、不能改、不能缓存过期 - 执行
composer diagnose后，输出里必须同时出现secure-http: OK和signature verification: OK才算真正生效；缺一不可
只要 signature 字段没同步到位，Composer 就会静默退回到无校验模式，这时候哪怕你用了 HTTPS，也等于裸奔。
