URI 是整条地址的完整写法，域名只是其中"门牌号"那一段；从协议头往后依次拆出 scheme、authority、path、query、fragment 五段，任何一条链接都能看明白。很多人把浏览器地址栏里的内容统称为"网址"，其实那串字符的正式名字叫 URI，它对结构有严格的语法约束，见 RFC 3986，搞懂这套语法，排查跳转、配置 Nginx、写爬虫时都会少走很多弯路。
域名和URI有什么区别？先分清这几个容易混淆的概念
日常沟通里三个词经常混着用，但它们的边界很清楚，URI 是统一资源标识符，负责"唯一指认一个东西"；URL 是统一资源定位符，属于 URI 的子集，额外说明了"怎么拿到它"；域名则是主机名的一部分，只解决"找哪台服务器"，行业共识认为，绝大多数 Web 场景下人们说的 URI 实际上就是 URL,因为定位信息已经足够。
三种写法放在一起对比
| 写法示例 | 属于什么 | 缺少的部分 |
|---|---|---|
example.com |
域名 | 协议、路径 |
https://example.com |
URL（也是 URI） | 路径默认为 |
mailto:hi@example.com |
URI，不是 URL | 没有网络定位信息 |
从表中能看出关键差异：mailto: 这种写法依然是合法的 URI，但它不指向网络位置，所以不算 URL，新手常犯的错是把域名当成 URI 的全部，看到 /api/v1/user?id=3 就不知道怎么读,其实前面的协议和主机被浏览器省略显示了。
一条完整 URI 的零件拆解
拿 https://www.shop.com:8443/goods/list.html?cat=book&page=2#review 举例：
https是 scheme，决定用什么协议通信www.shop.com是 host，也就是域名8443是 port 端口，不写就按协议给默认值，HTTP 是 80，HTTPS 是 443/goods/list.html是 path 路径，指向服务器上的资源cat=book&page=2是 query 查询串，参数之间用&分隔review是 fragment 片段，只在浏览器内部生效，不会发送给服务器
最后这一点很实用，做单页应用时用锚点切换视图，服务端日志里永远看不到 后面的内容,前端和后端对不上账时先想起这条。
新手怎么看懂域名URI结构？按顺序逐段切分
正确的读法是从左往右，遇到什么符号就切一刀，不要凭感觉猜,整个过程可以固化成三步。
第一步：认协议头
冒号之前的部分就是 scheme，只允许字母、数字、加号和减号，看到 https:// 就知道后面会走加密传输；看到 ftp:// 说明是文件传输；看到 file:/// 说明指向本地磁盘，路径里不会出现域名，协议头决定了后面整段内容的解释方式,读错了后面全错。
第二步：切出 authority 部分
之后、第一个 、、 之前的内容，统称 authority，内部还可能包含 用户名:密码@主机:端口 的结构，带用户信息的写法现在很少见，Chrome 一类浏览器遇到会直接提示风险,因为视觉上容易被钓鱼利用。
主机部分要注意国际化域名，中文域名在传输时要转成 punycode，中国"对应的形式是 xn--fiqs8s 开头的一串字符，这是 IDNA 标准规定的编码方式，你在地址栏看到中文能正常显示,是因为浏览器帮你做了还原。
第三步：处理 path、query、fragment
路径部分区分大小写，/User 和 /user 在多数 Linux 服务器上是两个不同资源，这点和域名正好相反域名和协议头都不区分大小写，路径末尾的斜杠也有讲究，/blog 和 /blog/ 在部分框架里会触发不同的路由规则,甚至引起一次多余的重定向。
查询串里的参数顺序在语法上没有意义，但实际会影响缓存命中率，CDN 通常把完整 query 当作缓存键，?a=1&b=2 和 ?b=2&a=1 会被缓存成两份，白白拉低命中率，参数多的时候，可以考虑在 CDN 后台开启"忽略参数顺序"。
中文和特殊字符怎么处理
URI 只允许一小部分 ASCII 字符直接出现，其余都得做百分号编码，编码规则是按 UTF-8 取出字节，每个字节写成 %XX，中"字的 UTF-8 是三个字节，编码后变成 %E4%B8%AD，空格在路径里编码成 %20，在查询串里也可以写成 ,两种写法服务端一般都能识别。
命令行里验证编码结果最直接：
python3 -c "from urllib.parse import quote; print(quote('中文 测试'))"
输出的 %E4%B8%AD%E6%96%87%20%E6%B5%8B%E8%AF%95 就是可以直接拼进链接的形式。
浏览器地址栏里的域名URI怎么拆解？三个可验证的方法
光看文档容易记不牢，动手拆一次印象最深,下面三个方法覆盖了日常调试的大部分场景。
开发者工具的 Network 面板
按 F12 打开开发者工具，切到 Network，刷新页面，点任意一条请求，右侧 Headers 里的 Request URL 就是完整 URI，这个方法的最大价值是能看到浏览器实际发出的内容，包括被自动补全的默认端口和编码后的参数,比对着地址栏猜准确得多。
curl 命令看请求行
curl -v "https://www.example.com/api/list?page=1"
加 -v 之后会打印请求行和请求头，第一行形如 GET /api/list?page=1 HTTP/1.1，注意这里只出现 path 和 query，主机名在后面的 Host 头里，这就直观说明了 URI 在 HTTP 协议里是被拆开传输的。
用标准库解析，避免手写正则
Python 里用 urllib.parse.urlsplit，Node 里用内置的 URL 对象,都能一次性拿到各个字段：
from urllib.parse import urlsplit
u = urlsplit("https://www.example.com:8443/a/b?x=1#top")
print(u.scheme, u.hostname, u.port, u.path, u.query, u.fragment)
自己写正则去抠域名和参数，遇到带端口、带用户信息、带 IPv6 方括号地址的情况极容易翻车，标准库已经处理了这些边界，没必要重复造轮子，业内专家指出,解析类漏洞里有相当一部分源于手写的字符串截取逻辑。
国内网站域名URI解析有哪些容易踩的坑
部署在国内服务器上的站点，有几个细节和纯技术文档的描述不太一样,提前知道能省不少时间。
- 未备案域名访问会被拦截：据工信部相关规定，境内服务器上的网站需要完成 ICP 备案，未备案域名在 80 和 443 端口上的访问可能被阻断，URI 语法完全正确也打不开页面,排查方向不该放在解析上。
- 路径大小写与 Windows 服务器的差异：本地开发在 Windows 上跑，
/Images/和/images/都能访问，迁到 Linux 就 404，这是文件系统大小写敏感性导致的，不是 URI 写错了。 - 反向代理改写路径：Nginx 的
proxy_pass结尾带不带斜杠，会让转发出去的路径完全不同,调试时优先看代理配置而不是前端代码。 - 编码二次处理：参数在 Nginx、网关、后端框架里各解码一次，中文参数容易出现乱码，用
curl -v逐层确认是最快的定位办法。
域名注册价格便宜会影响URI结构吗
不会，域名首年几十元还是几百元，续费价格高低，只影响你持有这个域名的成本，和 URI 的语法结构没有任何关系，换个注册商、换个后缀，https://主机/路径?参数 这套写法照样成立，真正需要花钱留心的是 HTTPS 证书和 CDN 流量，它们会间接影响你最终看到的地址形态，比如是否强制跳转、是否带 www 前缀，选域名时更该关心的是后缀长度和记忆成本，.com 与 .cn 在解析层面没有功能差别。
域名URI常见问题解答
域名URI解析时端口号一定要写吗？
不用，协议有默认端口，HTTP 走 80，HTTPS 走 443，省略时浏览器会自动补上，只有在使用非标准端口，比如本地开发的 3000、8080，或者反向代理映射到 8443 时，才需要显式写出来，写出来也不会出错，只是地址变长,分享给别人时显得不够清爽。
域名URI里问号后面的参数顺序能随便换吗？
从语法角度可以，服务端按参数名取值，顺序不影响结果，但缓存层面有影响，多数 CDN 默认把完整查询串当缓存键，顺序一变就是两个不同的资源，缓存命中率会下降，参数超过三四个时，建议在 CDN 后台把不参与业务判断的跟踪参数加入忽略列表,或者开启参数排序功能。
域名URI中井号后面的内容为什么服务器收不到？
因为 RFC 3986 明确规定 fragment 由客户端处理，不参与 HTTP 请求，浏览器在发出请求前就会把 及其后内容截掉，只把 scheme、host、path、query 发出去，所以指望用锚点传参给后端是行不通的，需要传递的数据必须放进 query 或者请求体里,这一条是所有前端路由方案设计时的基本前提。