内容摘要：上周帮朋友排查一个线上故障，最后发现是URL里多了一个空格。对，就一个空格，导致整个订单查询接口返回404。运维查了半小时服务器，开发翻了两小时代码，最后我在浏览器地址栏里看到了那个不该存在的%20。

上周帮朋友排查一个线上故障，网站最后发现是网站URL里多了一个空格。对，网站就一个空格，网站导致整个订单查询接口返回404。网站运维查了半小时服务器，网站开发翻了两小时代码，网站最后我在浏览器地址栏里看到了那个不该存在的网站%20。

这事听起来离谱，网站但每天都在发生。网站URL这玩意儿，网站大多数人天天用，网站却很少认真看它一眼。网站你复制粘贴、网站点击跳转、网站扫码打开，它就像空气一样存在。直到出了问题，你才意识到它其实是一串有严格规则的字符序列。

拆开看，URL到底长什么样

拿一个真实地址举例：

https://shop.example.com:8443/product/list?category=book&page=2#reviews

拆解一下。https 是协议，告诉浏览器用什么方式跟服务器说话。shop.example.com 是主机名，DNS 会把它翻译成 IP 地址。:8443 是端口，不写的话 https 默认走 443。后面的 /product/list 是路径，指向服务器上的具体资源。?category=book&page=2 是查询字符串，用来传参数。最后的 #reviews 是锚点，只在浏览器端起作用，压根不会发给服务器。

很多人不知道锚点不参与网络请求。我曾经见过一个后端同事对着日志纳闷：为什么前端说带了锚点参数，服务器这边完全看不到。原因就在这——# 后面的内容浏览器自己消化了，请求行里根本没有它。

编码这件事，坑最多

URL 里能直接出现的字符是有限制的。字母、数字、连字符、下划线、点、波浪号，这些没问题。其他字符，比如中文、空格、&、=、?，都得转义。空格转成 %20，中文“书”转成 %E4%B9%A6，这是 UTF-8 字节的十六进制表示。

问题在于，不同语言、不同框架对编码的处理并不一致。JavaScript 的 encodeURIComponent 和 Java 的 URLEncoder 在空格的处理上就不一样——前者给 %20，后者给 +。如果你用 Java 编码、JavaScript 解码，空格就变成了加号。这种 bug 不报错，只是数据悄悄变了，排查起来极其痛苦。

还有个经典场景：查询参数里本身要传一个 URL。比如回调地址 callback=https://a.com/page?x=1。这里的 ? 和 = 必须编码，否则服务器解析时会把 x=1 当成外层 URL 的参数。正确写法是 callback=https%3A%2F%2Fa.com%2Fpage%3Fx%3D1。我见过不少开发者在这里翻车，尤其是对接第三方支付接口的时候。

路径和参数，别混着用

RESTful 风格流行之后，很多人喜欢把标识符塞进路径里，比如 /user/12345/order/67890。这没问题，语义清晰。但有些参数天然不适合放路径——分页、排序、过滤条件。你硬要写成 /product/page/2/sort/price，读起来是顺了，可一旦要加第三个维度，路径就长得没法看。

我的判断标准很简单：这个参数是不是资源的唯一标识？是，放路径。不是，放查询字符串。别纠结什么 SEO 友好不友好，那是另一回事。

大小写和结尾斜杠

域名不区分大小写，Example.COM 和 example.com 一样。但路径部分，理论上区分。实际上很多服务器配置成不区分，导致开发者以为无所谓。换个服务器环境，/API/User 和 /api/user 可能就变成两个不同的路由。我吃过这个亏，后来统一强制小写，省心。

结尾斜杠也是。/product 和 /product/ 在某些框架里是两个不同的路由，一个返回列表，一个返回详情。更麻烦的是，有些 CDN 或反向代理会自动做重定向，把不带斜杠的跳到带斜杠的，或者反过来。这一跳，POST 请求可能变成 GET，请求体直接丢了。

URL 不是什么高深的技术，但它的细节足够多，多到每个人都觉得自己懂，直到那个 %20 出现。