前端开发中为什么要使用 URL().origin 提取接口根地址

文章目录

前言
一、如何从一个完整接口地址中，稳定、规范地提取"接口根地址？
[二、.origin 的定义](#二、.origin 的定义)
- [Origin = protocol + hostname + port](#Origin = protocol + hostname + port)
总结

前言

在前端项目中，接口配置通常类似如下形式

javascript 复制代码

{
  "API_BASE_URL": "http://192.168.100.32/toll/html"
}

在实际业务中，我们经常需要基于该接口地址，拼接静态资源路径或文件访问路径，例如

javascript 复制代码

logo = "upload/logo.png"

期望得到最终地址：

javascript 复制代码

http://192.168.100.32/upload/logo.png

一、如何从一个完整接口地址中，稳定、规范地提取"接口根地址？

标准做法：使用 URL 对象

URL 是浏览器内置的 URL 解析器，遵循 WHATWG URL 标准。

它会将一个字符串 URL 解析为结构化对象，而不是简单文本

javascript 复制代码

const url = new URL("http://192.168.1.32/toll/html");

javascript 复制代码

| 属性         | 含义  | 示例值                    |
| ---------- | --- | ---------------------- |
| `protocol` | 协议  | `http:`                |
| `hostname` | 主机名 | `192.168.1.32`        |
| `port`     | 端口  | ``                     |
| `pathname` | 路径  | `/toll/html`    |
| `origin`   | 源   | `http://192.168.1.32` |

二、.origin 的定义

Origin = protocol + hostname + port

特点：

永远不包含路径

永远不包含 query

永远不包含 hash

自动处理端口

避免做法：

字符串截取

正则解析

require 拼接网络路径

总结

.origin 能准确提取接口根地址，并不是巧合，而是因为：

URL 在 JavaScript 中是一个被浏览器严格解析的结构化对象，而不是普通字符串。

在涉及接口、资源路径、跨域、同源判断的场景中，始终优先使用 URL 对象，而不是手写规则