URL 与 URI：你真的懂网址吗？
每次在浏览器地址栏敲下一串字符，背后都有一套严谨的规则在运转。今天我们就来拆解这个每天见面的老朋友——URL。
我个人习惯把 URL 比作「互联网门牌号」。你想想看，没有门牌号，快递员怎么找到你家？没有 URL，浏览器就找不到服务器上的资源。但这里有个坑——很多人把 URL 和 URI 混着用，其实它们不完全是一回事。
URL 的组成结构
先看一个完整的 URL 长什么样：
https://www.example.com:8080/path/to/resource?name=alice&age=25#section2拆开来看，一共六个部分：
| 组成部分 | 示例 | 说明 |
|---|---|---|
| 协议 | https |
告诉浏览器用什么方式通信 |
| 主机 | www.example.com |
服务器域名或 IP 地址 |
| 端口 | :8080 |
服务器上的具体入口 |
| 路径 | /path/to/resource |
资源在服务器上的位置 |
| 查询参数 | ?name=alice&age=25 |
传递给服务器的额外数据 |
| 锚点 | #section2 |
页面内的定位标记 |
关键点：协议和主机是必选项，其他部分按需出现。端口默认值可以省略——HTTP 默认 80，HTTPS 默认 443。
协议（Scheme）
协议决定了通信的「语言」。除了常见的 http 和 https，还有 ftp、mailto、file 等。我记得刚入行时，有个同事把 https 写成了 http，结果用户数据明文传输，被安全团队抓了个正着。嗯，从那以后我对协议字段格外敏感。
主机（Host）
主机可以是域名，也可以是 IP 地址。域名最终会通过 DNS 解析成 IP。这里有个细节——localhost 和 127.0.0.1 都指向本机，但 localhost 走的是回环接口，不经过网卡，速度更快。我在本地调试时习惯用 localhost，部署到线上才换成正式域名。
端口（Port）
端口号的范围是 0-65535，但 0-1023 被系统保留。为什么需要端口？一台服务器可以同时跑 Web 服务、邮件服务、数据库服务，端口就是区分这些服务的「门牌号」。我曾经排查过一个诡异的问题：浏览器访问 http://example.com 一直超时，最后发现服务器上 HTTP 服务跑在 8080 端口，而 80 端口根本没开。
路径（Path）
路径表示资源在服务器上的位置。它和文件系统的路径很像，但本质上是虚拟的——服务器可以任意映射路径到实际文件或动态生成的内容。
查询参数（Query）
查询参数以 ? 开头，多个参数用 & 分隔。格式是 key=value。注意：查询参数是明文传输的，千万别放密码或令牌。我见过有人把 session ID 直接写在 URL 里，结果日志一泄露，整个系统就沦陷了。
避坑指南：查询参数中的特殊字符需要 URL 编码。比如空格变成 %20，中文变成 %E4%B8%AD%E6%96%87。我曾经因为忘记编码，导致一个搜索功能在用户输入「&」时直接崩了。
锚点（Fragment）
锚点以 # 开头，用于定位页面内的某个位置。它只在浏览器端生效，不会发送到服务器。你想想看，点击一个带锚点的链接，浏览器直接滚动到对应元素，根本不需要重新请求服务器。
URI 与 URL 的区别
很多人以为 URL 和 URI 是同一个东西，其实不然。URI 是统一资源标识符（Uniform Resource Identifier），URL 是统一资源定位符（Uniform Resource Locator）。
说白了，URI 是一个更宽泛的概念，它标识一个资源。URL 是 URI 的一种，它不仅标识资源，还告诉你如何访问它。举个例子：
https://example.com/file.pdf既是 URI 也是 URLurn:isbn:0-486-27557-4是 URI 但不是 URL（它标识一本书，但没告诉你去哪下载）
还有一个概念叫 URN（统一资源名称），它只标识资源，不提供访问方式。三者的关系可以用一张图表示：
记忆技巧：URL 是「能点开的 URI」，URN 是「只能查的 URI」。日常开发中我们接触的几乎都是 URL，但 RFC 文档里统一用 URI 这个术语。
绝对路径与相对路径
在 HTML、CSS、JavaScript 中引用资源时，路径写法直接影响资源能否正确加载。这里分两种情况：
绝对路径
绝对路径从根目录开始，或者包含完整的协议和主机名：
<!-- 完整 URL -->
<img src="https://example.com/images/logo.png">
<!-- 协议相对路径（继承当前页面的协议） -->
<img src="//example.com/images/logo.png">
<!-- 根相对路径（从域名根开始） -->
<img src="/images/logo.png">绝对路径的好处是稳定——不管当前页面在哪，都能正确找到资源。坏处是如果域名变了，所有引用都得改。
相对路径
相对路径基于当前文件的位置来计算目标资源的位置：
<!-- 同级目录 -->
<img src="logo.png">
<!-- 上级目录 -->
<img src="../images/logo.png">
<!-- 上上级目录 -->
<img src="../../images/logo.png">相对路径的优点是灵活——整个站点迁移到新域名，路径不用改。缺点是容易搞混层级。我见过一个项目，嵌套了七八层目录，结果 ../../../../../ 写得跟密码一样，维护起来简直噩梦。
最佳实践：在大型项目中，我建议统一使用根相对路径（以 / 开头）。这样既避免了域名耦合，又不会因为目录层级变化而出错。
路径解析规则
浏览器解析相对路径时，遵循以下规则：
- 以
/开头：从域名根目录开始查找 - 以
./开头：从当前目录开始查找 - 以
../开头：从上级目录开始查找 - 直接写文件名：等同于
./文件名
举个例子，当前页面在 https://example.com/docs/page.html：
| 写法 | 解析结果 |
|---|---|
/css/style.css |
https://example.com/css/style.css |
./images/pic.jpg |
https://example.com/docs/images/pic.jpg |
../js/app.js |
https://example.com/js/app.js |
data.json |
https://example.com/docs/data.json |
避坑指南：我曾经在 Nginx 配置里把 try_files 写错了，导致所有相对路径的资源都返回 404。排查了半天才发现，问题出在 /api 这个路径被当作文件系统路径处理了。记住：URL 路径是虚拟的，不要和文件系统路径划等号。
好了，URL 和 URI 的核心概念就讲到这里。你可能会问：为什么搞这么复杂？其实就是为了让互联网上的资源能被唯一标识和准确定位。没有这套规则，浏览器根本不知道去哪找你要的东西。