URL 的完整结构：协议、主机、端口、路径、查询、锚点

一个 URL 看起来是一整串字符，但它内部有严格的结构划分——协议、主机、端口、路径、查询参数、锚点各自占据固定的位置，浏览器和服务器都靠这套结构来解析"该往哪里发请求、发什么请求"。

目录

1. URL 的完整结构
2. 协议和主机：决定连接到哪
3. 端口：默认值经常被省略
4. 路径、查询参数和锚点

1. URL 的完整结构

一个完整的 URL 按固定顺序拼接各个组成部分：

https://user:pass@www.example.com:8080/path/to/page?id=1&sort=asc#section2
└─协议┘  └──用户信息──┘└────主机────┘└端口┘└──────路径──────┘└───查询───┘└锚点┘

浏览器解析 URL 时严格按这个顺序拆解，每一部分的边界都由固定的分隔符标出：:// 分隔协议和后面的部分，@ 分隔用户信息和主机，: 分隔主机和端口，/ 开始路径，? 开始查询参数，# 开始锚点。

2. 协议和主机：决定连接到哪

协议（https、ftp、ws 等）决定了浏览器该用哪种规则和服务器通信；主机（www.example.com）是域名或 IP 地址，决定了这个请求最终要发到互联网上的哪一台服务器——浏览器会先把域名通过 DNS 解析成 IP 地址，再建立网络连接。用户信息部分（user:pass@）现代场景已经很少使用（主要历史用途是在 URL 里直接携带 FTP 或 HTTP Basic Auth 的登录凭证），出于安全考虑，现代浏览器对这种写法普遍有额外的警告或限制。

3. 端口：默认值经常被省略

端口指定了服务器上具体哪个"门"在监听这个请求。每种协议都有一个约定的默认端口——HTTP 默认是 80，HTTPS 默认是 443——当 URL 没有显式写端口时，浏览器会自动使用对应协议的默认端口，这也是为什么日常看到的网址几乎都不带端口号：不是没有端口，只是恰好用的是默认值不需要写出来。只有服务运行在非默认端口时（比如本地开发环境常用的 :3000、:8080），才需要在 URL 里显式写出端口号。

4. 路径、查询参数和锚点

• 路径（Path）：/path/to/page，标识服务器上的具体资源位置，早期直接对应服务器文件系统的目录结构，现代 Web 应用里更多是应用内部路由规则的映射，不一定对应真实文件
• 查询参数（Query String）：?id=1&sort=asc，用 & 分隔的多个 键=值 对，用于向服务器传递额外的参数（筛选条件、分页、排序方式等），本质上是 GET 请求携带数据的标准方式
• 锚点（Fragment，#）：#section2，只在浏览器本地生效，不会被发送到服务器——浏览器收到页面后，会根据锚点值定位到页面内对应 id 的元素并滚动过去；现代单页应用（SPA）也常借用锚点或配合 History API 来实现"不刷新页面也能改变地址栏"的路由效果

理解"锚点不发给服务器"这一点很重要——如果需要服务器知道某个筛选/状态信息，必须放在查询参数里，放在锚点后面服务器是完全看不到的。

在线工具：URL地址解析