在Docker Compose中运行的React应用应使用哪个API请求URL？

核心问题定位 #

• axios请求的URL结构完全不符合通用格式规范。标准URL的固定结构为协议://主机地址:端口/资源路径，你编写的http://hikrr_api://api:4000将镜像名hikrr_api错误放在了主机位置、将服务名api错分到了路径段。浏览器解析该URL时，会直接将hikrr_api识别为主机地址发起DNS查询，最终抛出getaddrinfo ENOTFOUND hikrr_api的找不到主机错误，这也是curl日志中出现http://hikrr_api//api:4000这类双斜杠异常路径的直接原因。
• 混淆了Docker Compose内置网络的作用边界。Compose提供的「通过服务名做DNS解析」的内部网络能力，仅对同一Compose网络下运行的容器生效。你的React代码最终是运行在用户本地的浏览器环境中，浏览器本身并不接入Docker的内部网络，完全无法识别api这类Docker内部服务名——哪怕修正URL结构写成http://api:4000，浏览器依旧会报地址解析失败的错误。
• 错误将镜像名当做可解析的网络标识使用。image: hikrr_api是Docker给本地镜像打的标签，仅用于镜像的构建、本地存储和版本识别，既不会参与Docker内部的DNS解析，也不存在对应的可访问网络地址。

正确配置方案 #

• 适配当前浏览器端运行的基础场景：因为你在docker-compose中已经通过ports: - "4000:4000"将api服务的4000端口映射到了宿主机，浏览器作为宿主机上运行的程序，可以直接通过本地回环地址访问api服务，修正后的axios请求代码为：

axios({
  method: 'GET',
  url: 'http://localhost:4000/你的后端接口路径',
  params: {
    search: search,
    take: take,
    skip: skip
  },
  cancelToken: new CancelToken(c => {
    cancel = c;
  })
})

• 开发体验优化的可选方案：如果希望避免硬编码localhost:4000的地址、同时解决跨域问题，可以给React开发服务器（运行在GUI容器内的Node进程）配置代理规则——将前端所有以/api开头的请求，代理转发到http://api:4000（因为这个代理进程跑在GUI容器内部，属于Compose网络的成员，可以正常通过服务名api解析到后端api服务）。此时前端的axios请求直接写相对路径即可，例如url: '/api/search'，不需要写全量地址。

内容的提问来源于stack exchange，提问作者slatermorgan