镜像配置与代理设置是互斥的两种机制：镜像仅改composer元数据源地址，代理仅控制http/https流量转发，二者不可混用；国内开发应优先用镜像，代理仅适用于内网强制出口或mtls私有源场景。
镜像配置和代理设置根本不是同一层机制
镜像配置改的是 Composer 去哪拿元数据（packages.json、p2/xxx.json），代理设置改的是 HTTP 流量怎么转发。两者不能混用，也不能互相替代——设了镜像，http-proxy 就自动失效；开了代理，镜像地址就完全不走。
常见误操作是：一边执行 composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/，一边又配 http-proxy，结果 Composer 只认镜像 URL，代理字段被忽略，且不报错。
- 镜像只控制源站域名和路径，不干预 dist 文件下载地址（那个由
composer.lock或包自身composer.json决定） - 代理只在直连真实源（如
packagist.org或私有 Packagist）时起作用，且必须同时配http-proxy和https-proxy - 镜像站本身不参与 TLS 握手，也不支持客户端证书（mTLS），所以“用代理连镜像站”这种需求在技术上不成立
什么时候该用镜像，什么时候必须用代理
国内开发环境绝大多数情况应该优先用镜像——因为 packagist.org DNS 污染、TLS 握手失败、首字节延迟高，不是网络慢，是请求压根发不出去。而代理只在两种场景下不可替代：
- 公司内网强制走统一出口，且不允许直连外部 HTTPS 域名（此时镜像站也被拦截，只能靠代理透传）
- 要访问启用了 mTLS 的私有 Packagist（镜像无法代理客户端证书，必须用
https-proxy透传）
注意：create-project 默认忽略全局镜像，但不会绕过代理；如果项目模板里自带 repositories 字段，代理依然生效——它只管流量路由，不管源声明逻辑。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
代理配置漏掉 https-proxy 就等于没配
Composer 对协议严格分离：http-proxy 只处理 HTTP 请求，https-proxy 才负责建立 CONNECT 隧道转发 HTTPS 流量。Packagist 全量走 HTTPS，漏掉任一，就会卡在 Loading composer repositories，无错误、无超时、只干等。
- 两条命令都得执行：
composer config -g http-proxy http://127.0.0.1:8080和composer config -g https-proxy http://127.0.0.1:8080 -
https-proxy的值必须仍是http://开头，哪怕代理服务监听 TLS 端口；填https://或省略协议头会静默失效 - 用户名或密码含
@、/、:时必须 URL 编码，否则解析截断，报Invalid URI supplied
验证配置是否真生效，别信命令输出
运行 composer config -g repo.packagist 有输出 ≠ 镜像在用；composer config -g http-proxy 不为空 ≠ 代理已走通。真正有效的验证方式只有两个：
- 加
-vvv运行composer install，日志里出现GET https://mirrors.aliyun.com/composer/packages.json（镜像）或Proxy CONNECT（代理）才算落地 - 用
tcpdump或Wireshark抓包，确认实际连接的目标 IP 和端口，比任何配置检查都可靠
最常被忽略的点是：项目级 composer.json 中的 repositories 字段会彻底屏蔽全局镜像，而代理配置则会被项目级 config.http-proxy 覆盖——它们的优先级规则完全不同，不能套用同一套理解去调试。
