应使用 std::unordered_map 存储 url 查询参数键值对，但需先对每个 key 和 value 单独进行 rfc 3986 兼容的 url 编码（保留 a-z、a-z、0-9 及 -_.~，其余转小写 %xx），再拼接为无前导 ? 或 & 的纯查询字符串；若需保序或多值，则改用 std::vector。
如何用 std::unordered_map 构建 URL 查询参数映射
直接用 std::unordered_map<:string std::string></:string> 存键值对最自然，但要注意：空值、重复键、特殊字符（如 &、=、?）必须编码，否则拼接后会破坏 URL 结构。别用 std::map——它按字典序排序，而 URL 参数顺序通常无关紧要，且哈希查找更快。
常见错误是把原始字符串直接塞进去，比如 "name=张三" 这种带中文的值不编码，发出去后服务端收不到或解码失败。正确做法是先对每个 value（以及可选的 key）调用 URL 编码函数，再插入 map。
- 只对
key和value单独编码，不要对整个"key=value"串编码 - 编码函数需处理字母、数字、
-_.~保留字符（不编码），其余转%XX格式 - 空字符串
""是合法 value，不能跳过或替换成"null"
URL 编码函数怎么写才不踩坑
标准库没提供现成的 URL encode，自己写要避开两个典型问题：一是用 std::hex 输出大写字母（应小写，如 %e5 而非 %E5），二是漏掉对 + 的处理（空格应编码为 %20，不是 +）。
一个轻量级实现核心逻辑是遍历字符串每个字符，判断是否在允许未编码集合里（ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789-_.~），否则用 std::sprintf 或 std::format（C++20）转两位十六进制。
- 别用
std::stringstream拼接十六进制——性能差，且默认大写 - 输入含 null 字节（
\0）时，std::string构造函数可能截断，确保传入的是明确长度的视图或已知无嵌入 null - 如果项目已用 Boost，可用
boost::beast::http::url_encode，但注意它编码 key 和 value 时行为一致，无需额外适配
拼接查询字符串时怎么避免多余的 & 或 ?
拼接本身很简单：遍历 map，对每对 key 和 value 分别编码后，用 "&" 连接。但容易错在开头加 "?"——这不该由拼接函数负责，因为 URL 可能已有路径（如 "https://api.com/search"），加 "?" 是上层构造完整 URL 时的事。
- 拼接函数返回纯查询字符串（如
"q=%E5%BC%A0%E4%B8%89&page=2"），不含? - 用
std::ostringstream比字符串+=更高效，尤其参数多时；但首次拼接不加&，后续每项前加 - 空 map 应返回空字符串，不是
"?"或"&"
要不要考虑参数顺序和重复键
HTTP 规范不保证参数顺序，但某些旧后端（尤其是 PHP $_GET）依赖顺序，或同一 key 多次出现（如 id=1&id=2）。std::unordered_map 不支持重复 key，且遍历顺序不确定。
如果业务明确需要保序或允许多值，就别用 map，改用 std::vector<:pair std::string>></:pair>。这样既能控制顺序，也能 push 相同 key 多次。拼接时直接遍历 vector，对每个 pair 编码后拼上 &。
- 用 vector 时，记得手动对每个
first（key）和second（value）分别编码 - 如果后端接受数组式语法（如
ids[]=1&ids[]=2），那 key 名本身也要编码，不能只编码 value - 性能差异微乎其微（几十个参数内），优先按接口契约选结构，而不是预设“unordered_map 一定更快”
真正麻烦的不是拼接逻辑，而是编码边界——比如 value 里含 % 本身，是该原样保留还是双重编码？绝大多数 API 要求客户端做一次编码，服务端做一次解码，中间不干预。别想太多，按 RFC 3986 实现单层编码就行。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
