Composer不提供网络代理或网关功能，仅负责PHP依赖安装；网关（如Kong、Traefik）独立运行于容器网络中，其通信与Composer代理配置无关，后者仅影响composer install下载行为。
Composer 本身不提供网络代理或网关功能，它只是 PHP 的依赖管理工具；所谓“Composer 微服务网络代理网关集成”是常见误解——真正承担网关职责的是独立服务（如 Kong、Traefik、Nginx），而 Composer 只负责在各微服务项目中安装 SDK、客户端库或网关适配组件（比如 hyperf/gateway 或 symfony/messenger）。
为什么 composer config -g http-proxy 不影响网关通信
网关（如 Kong、Traefik）运行在容器里，其出站请求走的是容器自身的网络栈，和宿主机上 Composer 的代理配置完全无关。Composer 的 http-proxy 和 https-proxy 只控制 composer install 时下载包的行为，对运行时的 HTTP 调用零影响。
- 现象：配好了 Composer 代理，但微服务调用第三方 API（如微信、OpenAI）仍超时 → 这不是 Composer 的事，得查服务容器内的
curl或 SDK 是否走对了代理 - 关键点：PHP 进程发起的 HTTP 请求（如 Guzzle、cURL）默认不读取 Composer 配置，需显式设置
proxy选项或环境变量HTTP_PROXY - 例外情况：某些 SDK（如
consul-php-client）会自动读取HTTP_PROXY，但前提是容器启动时该变量已注入，不是靠 Composer 配置传递
微服务调用网关时的 DNS 和端口陷阱
在 docker-compose.yml 中，后端服务（如 user-service）调用网关，或网关反向代理后端，最容易卡在 DNS 解析失败或连接被拒。根本原因不是代码写错，而是网络归属没对齐。
- 错误写法：
http://localhost:8000/api/users—— 容器里localhost指自己，不是宿主机，更不是网关容器 - 正确写法：
http://api-gateway:8000/api/users，前提是两者在同一自定义网络（如gateway_net） - 检查手段：进容器执行
nslookup api-gateway，若返回server can't find api-gateway，说明服务没加对网络，或网络名拼错 - 端口注意：网关容器的
8000是容器内监听端口，ports字段只影响宿主机映射，不影响内部通信
Hyperf/Symfony 服务如何对接网关路由
框架本身不自动注册到网关，必须靠显式配置让网关知道“谁提供 /api/users”。Kong、Traefik 等不识别 PHP 框架，只认 HTTP 地址和健康接口。
- Kong：用 Admin API 添加
Upstream，目标地址填http://user-service:9501（Hyperf 默认端口），不是http://localhost:9501 - Traefik：在服务标签里加
traefik.http.routers.user.rule=PathPrefix(`/api/users`)，并确保user-service加入了 Traefik 所在网络 - Symfony：若用 Messenger 做异步通信，
SERVICE_USER_URL环境变量应设为http://user-service:8000，而非网关地址——网关只管同步 HTTP 流量，消息队列走的是另一套通路 - 健康检查：网关做负载均衡前会轮询
/health，Hyperf 要暴露该路由，Symfony 要配好framework.health，否则服务上线即被剔除
最常被忽略的一点：网关和服务之间若跨了两个不同网络（比如网关在 frontend，服务在 backend），又没在 networks 下同时声明两者，那它们根本 ping 不通——Docker 的网络隔离是硬性的，没有“默认放行”，也没有“自动桥接”。
