解析与重建 URL Query，避免语义丢失
重复参数、空值和嵌套 URL 在不同解析器里行为不同——先拆分 query，再编码或排序。
日志和地址栏里常见一整条 query。OAuth 回调、webhook 校验、分析参数都依赖参数在往返中不变。
失败往往不是因为「解析器坏了」，而是把编码、排序、序列化当成一步 reversible 操作。
建议从 API 调试工作流总览 入手。OAuth 相关编码陷阱见 OAuth Redirect 里的 URL 编码问题。
URL 与 query 的边界
完整 URL 含 scheme、host、path、query，有时还有 fragment。常见错误是对 path 编码却想改单个 query 值——或在库已解码一次后又重建 query。
先用 URL 解析器 分开组件，并排查看键、重复键、空值和原始编码段。
重复参数与空值
/search?tag=go&tag=api 与合并重复键的 API 行为可能不同。state= 也不等于省略 state。在「清理」query 前，确认服务端比的是原始字符串还是解析后的 map。
OAuth 与嵌套 URL
redirect_uri、return_to、UTM 常在单个参数值里再包一层 URL。外层解析器不能把内层 ?、& 拆开。
内层 URL 作为一个值编码后再放入外层 query。调试时用 URL 编码 / 解码工具 一次只处理一个组件。
排序与重建
排序便于 diff 两个请求，但若上游按原始 query 字节序签名，排序会改语义。重建时注意 + 与 %20、是否保留重复键，并用 文本对比工具 对比前后字符串。
实用流程
- 在不乱改未检查编码段的前提下解析日志 URL。
- 一次只修一个参数边界。
- 只重编码需要改的那一层。
- 涉及签名时，按字节对比重建结果与失败请求。
Query 看起来简单，直到鉴权、缓存或统计依赖它——把 parse、encode、rebuild 分开，问题会清晰很多。
工作流总览见 本地浏览器 API 调试工作流。