你有没有遇到过这种情况：明明URL看起来是对的，参数也传了，后端却只收到一半参数值。更诡异的是，本地测得好好的，一到线上就出问题。排查半天，最后发现罪魁祸首竟然是那个看起来人畜无害的“&”符。

是的，就是这个英文半角的and符号，在URL传值这条链路里坑过无数人。它既是查询参数的标准分隔符，又是很多参数值里会自然出现的字符。当“分隔符”和“内容”撞在一起，问题就来了。这篇文章不聊玄学，就把我自己和身边同事这些年踩过的坑、最后沉淀下来的处理姿势完整捋一遍，包括“&”为什么会引发问题、URL编码到底做了什么、前端和后端各自该怎么处理、以及几类高频事故的现场还原。不管是刚入门的前端新人，还是写后端接口的老手，大概率都能找到自己曾经留下的血泪证据。

1. “&”符在URL里的角色与第一颗雷

先从最基础的说起。一个完整的URL其实是这样的：

scheme://host/path?query#fragment

scheme是协议，host是域名和端口，path是路径，fragment是页面内锚点。而中间那个query，也就是查询字符串，就是我们今天的主战场。查询字符串是一串“键=值”的组合，多个组合之间用“&”隔开。比如：

https://example.com/search?keyword=手机&page=2&sort=price

这里就有三个参数，keyword、page和sort，分别对应手机、2和price。服务端拿到这个字符串后，会先按“&”切分成三段，再按“=”把每一段拆成键和值，最后塞进一个结构化的对象里。这是标准行为，几乎所有语言和框架都是这么解析的。

1.1 查询参数解析规则：按“&”切分的标准流程

如果把查询字符串比作一张去超市采购的购物清单，那“&”符就是清单上的分号，用来区分“苹果、两斤”和“香蕉、三把”。按“&”切开之后，每一段再按“=”分成“物品”和“数量”。这个流程太自然了，自然到很多人压根没想过：如果买的东西名字里本身就有分隔符号，比如“苹果&香蕉”，这清单还怎么读？

放在URL传值里就是同一个道理。当参数值里含有“&”时，名字叫“&”的分离器会把一个值拦腰截断。比如：

/search?keyword=苹果&香蕉

服务端按“&”一切，得到两个参数：

• keyword = 苹果
• 香蕉 = （空）

后面那个“香蕉”因为等号都缺了，通常直接被忽略，或者被记成一个空值的怪参数。用户明明搜的是“苹果&香蕉”，结果后端拿到的是“苹果”，搜索结果自然完全对不上。

1.2 字符串拼接URL的“经典事故”

这个坑的触发点几乎都是同一个：前端习惯用字符串硬拼URL。类似这样：

let keyword = '苹果&香蕉'; let url = '/search?keyword=' + keyword;

看上去没毛病，字符串拼起来嘛。但拼出来的结果是：

/search?keyword=苹果&香蕉

浏览器一解析，“&”立刻把参数切开了。keyword只剩“苹果”，“香蕉”直接变成一个孤儿参数。用户搜“苹果&香蕉”，服务端却在搜“苹果”，反馈到页面上就是结果不对、排序诡异、甚至直接报错。

这个问题的根源不在于“&”有多特殊，而在于我们自己在拼接时把特殊字符当成了普通字符。所有出现在URL里的字符，只要不是字母、数字和几个预留安全符号（如-、_、.、~），都应该先做编码。编码之后，“&”会变成%26，URL变成：

/search?keyword=%E8%8B%B9%E6%9E%9C%26%E9%A6%99%E8%95%89

服务端拿到后先解码，再按“&”切分，这时候“%26”是值的一部分，不会再被当成分隔符。问题自然就消失了。

1.3 为什么有人一直没踩坑：浏览器和框架替你擦了屁股

这里有个很现实的问题：我都这么写了十年，怎么一直没出事？答案很可能是，你根本没亲手拼过URL。

大多数时候，我们用的是表单提交。HTML表单的GET提交会自动把表单字段编码成查询字符串，浏览器会替你把特殊字符处理掉。另一种情况是用现成的网络库，比如Python的requests库传params时，库内部也会自动做编码。在这些“托管”场景里，坑被框架挡在门外了，你自然感知不到。

但只要换成手写场景，问题立刻暴露：手动重定向拼接、前端JS拼URL、App端拼查询串、签名接口里拼待签名字符串……这些场景没有框架帮你兜底，一对“&”就原形毕露。所以，不是你没踩坑，是你还没到手动拼URL的那一步。

2. URL编码规则：为什么“&”必须变成“%26”

既然要编码，就得搞清楚编码规则。不然你会在另一个方向上翻车：该编码的不编码，或者编了两次，结果一样惨。

2.1 百分号编码（percent-encoding）到底做了什么

URL编码的官方名字叫百分号编码，规则简单粗暴：把字符转成UTF-8的字节序列，每个字节再写成%加两位十六进制。比如中文“苹”的UTF-8编码是E8 8B B9，URL编码后就变成%E8%8B%B9。而“&”字符本身在ASCII里是38，写成十六进制是26，所以URL编码结果就是%26。

但是要注意，百分号编码不是所有字符都要编。RFC 3986把字符分成了几类： unreserved字符（字母、数字以及-._~）永远不需要编码；而“&”、“=”、“?”、“#”这些属于保留字符，在特定语境下有特殊含义，出现在参数值里就一定要编码。

生活化一点：保留字符就像交通标志里的“禁止通行”，“&”在查询字符串里就是“参数分界点”。你想把“禁止通行”四个字当作目的地写进导航，那得先把它们包起来，告诉导航“这是地名，不是路标”，URL编码就是这个包装动作。包装完之后，服务端拆参时会先拆包装，再还原成原始文字。

2.2 encodeURI和encodeURIComponent：到底该用哪个

在前端JavaScript里，有两个长得几乎一模一样的函数：encodeURI和encodeURIComponent。我见过的错误中，有相当一部分是这两个选错了。

关键区别在于encodeURI的本意是“编码整个URL地址”，所以它不会动那些URL结构字符，比如“&”、“=”、“?”、“#”都保留原样。而encodeURIComponent的本意是“编码URL中某一段内容”，所以它会把几乎所有非字母数字字符都编码掉，包括“&”。

看个对比就清楚了：

encodeURI('苹果&香蕉'); // 结果：%E8%8B%B9%E6%9E%9C&%E9%A6%99%E8%95%89 // 注意：& 还留在里面 encodeURIComponent('苹果&香蕉'); // 结果：%E8%8B%B9%E6%9E%9C%26%E9%A6%99%E8%95%89 // 注意：& 变成了 %26

如果你用encodeURI去编码一个参数值，只要值里有“&”、“=”、“?”，拼接后照样会被解析成多个参数，等于白编。所以我的习惯非常固定：参数值一律用encodeURIComponent，永远不用encodeURI去处理单段值。

2.3 各语言编码函数的差异：空格到底是+还是%20

换到其他语言，坑又换了一副面孔。不同语言对空格的编码处理不一样，有的编成+，有的编成%20。别小看这点差异，前后端用的编码风格不一致，空格就可能变成乱码或者错值。

• PHP的urlencode把空格编码成+，而rawurlencode按RFC 3986把空格编码成%20。
• Python的urllib.parse.quote默认把空格编码成%20，urllib.parse.urlencode则是表单风格，空格变+。
• Java的URLEncoder.encode老版本把空格变+，而且它对非ASCII字符的处理在某些环境下有问题。
• Go的url.QueryEscape空格也是+。

理论上，服务端解析时两种形式都能识别，因为 query-string 的解码规则里“+”和“%20”通常都会被还原成空格。但坑在于签名场景。假如你是用原始字符串做MD5签名，前端用+编码，后端用%20编码，两边签名字符串不一致，签名就永远对不上。这个问题排查起来非常痛苦，因为看起来参数都对，就是验签失败。我见过一次线上故障，最后发现就是这边用Java标准库、那边用某人手写的编码器，空格风格不一致导致的。所以，团队里一定要统一编码函数，并且签名时尽量用固定顺序、固定编码规则拼原始串。

3. 一套完整可用的传值方案：从拼接到接收的正确姿势

搞清楚原理以后，实战就简单了。下面给出一套我这些年用下来最稳的方案，从前端拼接、后端接收到完整链路，每一步都能直接抄。

3.1 前端拼接参数：用URLSearchParams替代手拼字符串

现代浏览器和Node.js环境里，最省心的做法是用URLSearchParams。

const params = new URLSearchParams(); params.set('keyword', '苹果&香蕉'); params.set('page', '2'); const url = '/search?' + params.toString(); // 结果：/search?keyword=%E8%8B%B9%E6%9E%9C%26%E9%A6%99%E8%95%89&page=2

URLSearchParams会自动处理编码，你只管往里塞值，不需要自己记住哪些字符要转。这比我年轻时手写一串replace历史清爽太多了。

如果项目环境比较老，或者你想写个不依赖现代API的工具函数，也简单。核心逻辑就是遍历参数对象，对每个值先encodeURIComponent，再拼成key=value，用&连接。三步走：

function buildQuery(params) { return Object.keys(params) .map(key => encodeURIComponent(key) + '=' + encodeURIComponent(params[key])) .join('&'); }

这段代码有两点要注意：一是键也要编码。别觉得键是开发人员写的就没问题，如果键来自动态配置或者用户输入，照样可能带“&”或“=”。二是返回值可直接用于拼接，不需要额外再编码。编码发生在每个键值对内部，链接各键值对的“&”是分隔符本体，不能编码。

3.2 后端接收参数：框架自动解析，但别做多余动作

后端接收这边，主流的Web框架都会自动对查询字符串解码。换言之，你看到的值已经是“苹果&香蕉”，而不是过编码的乱码。

• PHP里$_GET['keyword']直接就是解码后的值。
• Java Servlet的request.getParameter("keyword")同理。
• Node.js里Express框架的req.query.keyword也是解码后的。
• Spring Boot的@RequestParam String keyword同样。

这意味着后端开发者的日常写代码时根本不需要手动再解一次码。真正需要关心解码的地方有两个：一是自定义解析器，如果你自己用split("&")去解析raw query，就必须记得在拆完之后对每段做decode；二是签名校验，你要用原始收到的query字符串参加验签，这时候不能拿框架解码后的值重新拼，因为编码形式很可能已经变了，得用request.getQueryString()这类接口拿原始字符串。

3.3 全链路模拟：一个搜索功能的完整实现

我拿一个模拟项目X来演示一遍完整链路，读者可以直接照着改。场景是前端一个搜索框，用户输入关键词，请求后端接口，后端返回匹配结果。

前端部分：

// 搜索框输入：苹果&香蕉 async function search(keyword, page) { const params = new URLSearchParams(); params.set('keyword', keyword); params.set('page', String(page)); const resp = await fetch('/api/search?' + params.toString()); const data = await resp.json(); return data; }

后端部分（Node.js Express示例）：

app.get('/api/search', (req, res) => { const keyword = req.query.keyword; const page = Number(req.query.page) || 1; // keyword 此时已经是 '苹果&香蕉' const results = searchFromDb(keyword, page); res.json({ keyword, results }); });

整个链路跑下来，前端把“&”编码成“%26”，后端框架解码还原成“&”，数据库查询用的是完整关键词，JSON回传时再自动转义，前端渲染也没问题。这就是一套标准的闭环。

但这里有个隐藏细节，想特别提醒：响应JSON里如果含有“&”字符，框架输出时会原样输出，浏览器端JSON.parse解析没问题。可如果你直接把JSON放在HTML里的script标签里，就得小心了，这属于HTML注入范畴，和URL编码不是一回事。别混在一起处理。

4. 踩坑实录：五起事故的现场还原与排雷

理论说了一堆，不如直接上事故现场。这些都是我或身边同事真实处理过的问题，我尽量把现象、排查过程和最终解法都写清楚。

4.1 事故一：搜索关键词带了“&”，结果只剩前半截

现象：线上用户反馈搜索结果不全，明明数据库里有匹配数据，搜索结果却只有一半。我们拉日志，发现后端拿到的keyword参数被截断了，比如用户搜“PHP&Java”，后端只拿到“PHP”。

排查：一开始怀疑是前端AJAX传参有问题，检查源码发现是手写的字符串拼接。代码里就直接用+拼了。定位到这里，原因已经明确了。

解法：把拼接改成URLSearchParams，或者至少对参数值做encodeURIComponent。改完后端就收到了完整的“PHP&Java”。这个事故本身不难，但它验证了一个规律：凡是字符串拼URL的地方，几乎必然藏着这类问题。

4.2 事故二：回调地址里嵌套参数，整条链接被截断

现象：某个平台对接第三方开放平台，需要拼接一个回调地址，回调地址本身又是一长串带参数的URL。结果对方回调时，后面的参数丢失了。

这其实是同一类问题的变种。错误写法类似这样：

const callbackUrl = 'https://myapp.example/callback?orderId=123&userId=456'; const redirect = 'https://thirdparty.example/auth?redirect_uri=' + callbackUrl;

拼出来的结果是：

https://thirdparty.example/auth?redirect_uri=https://myapp.example/callback?orderId=123&userId=456

第三方平台解析这个URL时，把“&”当成了自己的参数分隔符。userId直接从redirect_uri的值里漏了出去，变成第三方平台自己的顶层参数。轻则回调时字段缺失，重则校验失败。

解法也很简单：把整个callbackUrl当成一个普通参数值，先整体encodeURIComponent，然后再拼接。

redirect_uri=https%3A%2F%2Fmyapp.example%2Fcallback%3ForderId%3D123%26userId%3D456

注意“?”和“&”都被编码了，落到第三方平台上它就是一个干干净净的字符串。这个“整体编码”的思路，在OAuth跳转、支付回调、单点登录这种场景里尤其重要，建议所有对接外部系统的同学都把“对回调地址整体编码”刻进肌肉记忆里。

4.3 事故三：双重编码导致的值错乱

现象：有一个接口返回的keyword字段变成了一长串%2526这种，前端怎么解码都还原不对。

分析：%2526其实是“%26”被再次编码后的样子。也就是说，“&”先被编码成“%26”，这个“%26”又被整体编码了一次，里的“%”变成了“%25”，结果就变成“%2526”。这种事通常发生在两端都加了编码的场合。

典型场景：前端已经encodeURIComponent了，后端处理时又对整个URL重新做了一次URL编码，或者中间经过一层网关、代理时被重复编码。还有一种是后端框架自动解码之后，开发者心里不踏实，又手动调用URLDecoder.decode一次，结果把框架已经解码好的值又解了一遍。拆法就反了，出来的就是乱码。

解法：链路中每一层只编码/解码一次，层层分工明确。前端负责对参数值编码，后端框架负责解码一次，业务代码不要重复调用解码函数。如果你负责的中间层要对整个URL做处理，一定先确认上游是否已经编码，别画蛇添足。

这里提供一个快速判断方法：看到URL里出现%25，就说明“%”本身被编码过，多半是双重编码。排查时沿链路由后往前找，哪个环节对已编码内容又编了一次，就是元凶。

4.4 事故四：手写解析字符串导致误判

现象：有个老系统没用现成的HTTP解析库，而是自己写了个函数，按“&”和“=”解析查询串。某天线上出现一批奇怪的日志，参数的key都变成了带%的乱码。

分析：手写解析函数忘了对切出来的片段做decode。因为URL里的参数值经过编码，解析时应该先按“&”和“=”切出键值对，再对键和值分别URL解码。如果漏了最后一步，拿到的key还是“%E4%B8%AD%E6%96%87”这种形态，存进数据库自然全是乱码。更严重的是，如果值里有“%26”，这个值在解码前根本不会被识别成“&”，所以按“&”切分时倒不会切错，但解码步骤漏了，结果还是错的。

解法：手写解析器时，务必在切分完成后对每一段调用decodeURIComponent（或语言对应的解码函数）。同时，键和值都要解。我自己一般不会去手写解析器，除非是极简单的内部工具，能复用框架就用框架。手写解析器看似简单，实际要考虑的边界情况非常多：出现空值、多个等号、没有等号的键、编码后的“&”、中文、加号……每个都是坑。

4.5 事故五：HTML里的“&”与URL参数的纠缠

现象：某页面里有一段a标签的href，里面带了一个查询参数，参数值里有“&”。页面上渲染结果看起来是对的，链接也是对的，但点击后传到后端的参数却是错的。

这个问题的根源要从HTML层面说起。在HTML里，“&”本身是一个实体引用起始符，比如“&”代表“&”，“<”代表“<”。当你在HTML源码里写href时，如果URL里的“&”没有写成“&”，浏览器解析HTML时就会把它和后面的字符尝试匹配成实体，匹配不上时结果就可能异常。更隐蔽的是，如果你用模板引擎或前端框架来渲染链接，框架会自动把“&”转义成“&”，浏览器再把它还原成“&”，这个时候URL是正常的。但如果你手动拼接HTML字符串，就很容易漏掉这一步。

解法：在HTML里写URL时，所有“&”一律写成“&”。如果你是用框架渲染，尽量交给框架处理，不要手动拼HTML。而且这个“&”只存在于HTML源码层面，浏览器解析后实际URL里的字符仍然是“&”，服务端按URL解码规则正常处理即可。把HTML转义和URL编码这两层分开看待，就不会被绕晕。

5. 防御性编程与团队约定：别把雷留给下一个接手的人

单个人避开坑只是第一步。URL传值这类问题，最怕的是团队里每个人各写各的，今天你小心了，明天别人又踩回去。所以我后来在团队里推行了几条防御性约定，效果不错。

5.1 统一封装与使用规范：消灭手拼URL

第一件事，项目里统一封装一个buildQuery工具函数，内部实现我刚才写的那套逻辑。规定所有前端代码一律不能手写字符串拼接，必须调用这个工具函数。后端同样，写一个QueryParamUtil之类的工具类，凡是构造带参数的URL，一律走工具类。这样，编码逻辑全局只有一份，出问题只需修一处。

工具函数也不复杂，但要注意加注释说明用途：

/** * 构造带查询参数的URL，自动编码所有键和值 * 禁止直接用字符串拼接方式构造URL */ export function buildUrl(base: string, params: Record<string, string | number>) { const search = new URLSearchParams(); Object.entries(params).forEach(([key, value]) => { search.set(key, String(value)); }); const query = search.toString(); return query ? `${base}?${query}` : base; }

5.2 接口层面的约定：参数值尽量走编码，别用特殊字符取巧

有同学会想，那我在接口设计时约定关键词里不允许出现“&”不就行了，省得编码那么麻烦。这种“堵”的思路在内部接口或许可行，但对用户输入根本不可控。用户不会因为你不允许就不输入“&”，搜索“PHP&Java”是很正常的诉求。所以我的建议是：对外接口一律支持任意字符的参数值，内部统一编码解码；如果某些场景确实希望限制特殊字符，就在参数校验阶段返回友好提示，而不是让错误一路传到数据库再报错。

另外一个可以做的约定是，URL里的参数命名尽量简单，参数值本身也尽量用标准化编码。比如日期用时间戳，避免出现“2024-01-01 10:00:00”这种带空格的值，虽然编码能解决，但能少一个特殊字符是一份安心。

5.3 测试用例与自查清单：把常见坑固化成自动化回归

我强烈建议，在测试用例里专门加一组“特殊字符传参”的用例。每次发版前把这些用例跑一遍，就能挡住一大部分回归事故。用例至少覆盖这些输入：

• 带“&”的值，例如“AT&T”
• 带“=”的值，例如“a=b”
• 带中文和空格的值
• 带“%”的值，例如“100%完成”
• 带“#”的值，例如“C#基础”
• 值本身很长，超过几百字符

每一条用例都断言前端构造出的URL经过后端解析后，参数值能原样还原。如果你用自动化测试框架，把这些断言全写进去，以后不管多少人改代码，这些都像哨兵一样帮你守着。

再附一张自查清单，我每次排查URL问题时都会过一遍：

这张表看起来简单，但每次事故最后复盘，几乎都能在表里找到对应的一行。

最后说点个人感受。URL传值里的“&”符问题，本质上是字符在不同上下文里语义不同导致的冲突：在查询字符串语法里它是分隔符，在业务数据里它是普通内容。要解决它，靠的不是死记硬背几个函数，而是理解“编码-传输-解码”这条链路里每一环的职责。前端负责把内容和大环境隔离开，网络层原样传输，后端负责还原语义，中间任何一层越界都容易出事。

我见过太多同学在这个问题上浪费时间，包括当年的我自己。印象最深的一次，为了排查一个回调参数丢失问题，整个团队排查了一整个下午，最后发现只是拼接处少了一个encodeURIComponent。从那以后，我再也没手写过字符串URL拼接，也养成了在代码评审里专挑“URL拼接”看毛病。希望这篇总结能让你少走这些弯路，别让一个“&”毁掉一个周五晚上。