经验分享URL编码Base64JSONUser-Agent
接口联调里的“编码血泪史”：我后来固定的三步检查
这段经历应该很多人都遇到过：URL 里带着 JSON，又在 JSON 里带着 Base64 文本，最后再加上浏览器与服务端对于字符集的默认不一致，输出就变成“看起来差不多、但哪里都对不上”。我在一次对接里被折磨得够呛，于是给自己总结了一套“三步检查”。
现象：参数丢失、字段错位、内容乱码
当时的接口需要我把一个对象序列化后放在 URL 参数里，另外还有一段小文件的内容要以 Base64 形式提交。第一版联调的现象包括：中文被截断、某个 key-value 被对方解析成了两段、再就是 Base64 到底有没有被二次编码说不清楚。
第一步：统一编码假设
我现在做这类对接，会先把双方“默认假设”说清楚：
- URL 参数统一使用
encodeURIComponent； - 字符集明确为 UTF-8；
- Base64 仅做承载，不做任何“再加工”；
- JSON 作为纯文本在参数里出现时，必须整体编码后再拼接，不能把内部的
&、=留在明文。
我会在联调文档里写一行“示例 URL”，同时把“未编码前的原始参数”和“编码后的实际串”都列出来。
第二步：字段校验与样例复现
我会把拟提交的 JSON 放进格式化工具先美化看看有没有遗漏逗号之类的问题，再用 URL 编码工具确认参数是否只被编码了一次；对于 Base64，我会反向解码一次，确认里头的内容是我期望的原始文本。最后，把这些样例（原文、编码后、对方解析结果）放在一个文档里，确保“复现路径”一致。
第三步：环境差异与UA
一次很偶然的排查，让我发现用户的浏览器版本对某个 API 的行为差异较大。从那以后，我会让遇到问题的同学把 UA 粘过来，或者直接用 UA 解析工具拆分出“浏览器/内核/系统/设备”，避免陷入“只有我这边复现”的尴尬。
小结：后来我就不再怕这类问题了
说穿了，这些问题不是“高深技巧”，而是“把假设对齐、把样例跑通”。我现在习惯在第一次联调前，就把上面三步过一遍，再也没有“明明一样却总出差”的情况了。