改了镜像仍触发高额出网流量，是因为配置未真正生效或上游拉取仍走公网——如satis默认直连packagist.org、镜像url为公网地址、项目级repositories覆盖全局配置、未设代理或限速，导致请求被云厂商计为出方向流量。
为什么改了镜像还触发高额出网流量
镜像源配置本身不产生带宽费用，但一旦 composer install 或 satis build 发起的请求走的是公网地址（比如 https://mirrors.aliyun.com/composer/），就会被云厂商计为「出方向流量」。阿里云轻量服务器超免费额度后 0.8 元/GB，腾讯云 CVM 若未走 NAT 网关或代理，curl 请求全算公网出口——一次 CI 构建可能多花几百元。
如何确认当前镜像是否走内网
别只看命令输出，要查真实生效地址：
- 运行
composer config -g repo.packagist，输出必须是内网地址，例如http://10.0.1.100:8080/；若仍是https://mirrors.aliyun.com/composer/，说明没生效 - 执行
composer install -vvv，观察日志里实际发起的GET请求 URL 是否匹配你配的内网地址 - 在 CI 节点上直接
curl -I http://10.0.1.100:8080/packages.json，确认返回 200 且无重定向
同步过程中的限流与代理控制
即使用了内网镜像，若上游仍需拉取官方源（如 satis 构建），就得主动限速防突发流量：
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 用
timeout 300包裹构建命令，避免单次卡死拖垮整条流水线 - 加
trickle -s -u 1024（限速 1MB/s）控制出网带宽，防止瞬时峰值打爆账单 - 给
satis build配http.proxy：在config.json中设"proxy": "http://squid.internal:3128"，所有外网请求收敛到可控出口 - 用
packagist-mirror替代satis，它支持mirror.source指向已缓存的内网 Nginx 服务，彻底规避公网拉取
CI/CD 中最易漏的带宽黑洞
这些配置看似无关带宽，实则每项都直接影响出网量：
-
composer update必须禁用——它会反复请求 provider 文件并触发镜像站反向拉取，而composer install --no-interaction --prefer-dist只读composer.lock和本地缓存 -
--no-dev和--no-scripts不仅提速，更减少 ZIP 下载次数和子进程调用带来的额外网络往返 - 项目级
composer.json中若写了"url": "https://your-satis.example.com"，而该域名解析到公网 IP，就等于给每个构建节点开了独立出口权限
真正关键的不是“有没有镜像”，而是所有同步动作是否收敛到一个可控、可审计、可限速的出口点。漏掉代理、DNS 绑定或内网地址校验中任意一环，带宽成本就可能失控。
