不能直接用 std::ostringstream 拼接 url 参数，因其默认格式化、缓存和 locale 处理导致频繁内存重分配与字符转换，且不支持 url 编码，易生成非法 url；应采用预分配 std::string + 手写 url 编码 + 指针写入的零拷贝方案。
为什么不能直接用 std::ostringstream 拼接 URL 参数
因为 std::ostringstream 默认做格式化、缓存管理、locale 处理，对每个 key=value 都触发内存重分配和字符转换，实测在千级参数场景下比手写快 3–5 倍。更关键的是它不处理 URL 编码，拼出来的是非法 URL。
真正要解决的不是“怎么连字符串”，而是“怎么零拷贝编码 + 避免临时对象 + 控制内存增长”。
- 所有 value 必须做
url_encode（空格→%20，斜杠→%2F等） - key 和 value 中的
&、=、?等必须转义，否则破坏结构 - 首个参数前不加
&，后续才加；但整个串开头是否加?取决于使用场景（如拼到已有 URL 后就用&）
std::string 预分配 + 迭代器写入是最稳的方案
不用 +=，不用 append()，直接用 reserve() 算好总长，再用 data() + 指针写入。实测比反复 += 快 40%+，且避免多次 realloc。
预估长度公式：sum(key.size() + value_encoded_size + 2) + (map.size() > 0 ? map.size() - 1 : 0)（+2 是 = 和分隔符，分隔符数 = 参数数 − 1）
- 先遍历一遍 map，调用轻量
url_encode_len(const char*, size_t)算出每个 value 编码后长度（不真编码，只数 %XX 占位） - 用
str.reserve(total)一次性分配 - 用
char* p = str.data()，每次写完更新p，避免重复计算偏移
URL 编码必须自己写，别信 curl_easy_escape 或第三方库
curl_easy_escape 分配堆内存、带锁、不可重入；Boost 的 network::uri 依赖重，且默认编码策略和浏览器不一致（比如不编码 ~）。C++17 没标准 URL 编码函数。
一个够用的内联编码函数长这样（只处理 ASCII，UTF-8 字节流可直接传入）：
inline size_t url_encode_len(const char* s, size_t n) {
size_t encoded = 0;
for (size_t i = 0; i = 'a' && c = 'A' && c = '0' && c
- 编码逻辑必须和主流浏览器一致：保留
A-Z a-z 0-9 - _ . ~，其余全转%XX - 不要用查表法（空间换时间不值得），分支预测在现代 CPU 上足够快
- 注意
' '（空格）必须转成%20，不是+（那是 application/x-www-form-urlencoded 的旧规，URL path/query 里不用）
Map 类型选 std::unordered_map 还是 std::map？
如果参数顺序不重要（绝大多数 HTTP GET 场景），用 std::unordered_map；如果要求 key 字典序（如签名验签场景），必须用 std::map 或先 collect keys 排序。
-
std::unordered_map迭代顺序未定义，不同标准库实现、不同编译器、甚至同版本不同运行都可能变——签名会失败 - 若需稳定顺序，建议：
std::vector<:pair std::string>> params</:pair>，插入时保持有序，或插入后sort(params.begin(), params.end()) - 别用
std::map存原始键值再转 vector——红黑树节点分配开销大，不如一开始就用 vector + reserve
实际最难的不是拼接本身，是搞清你到底要不要排序、要不要兼容 IE 的怪异编码、以及 value 里有没有嵌套 JSON（得先 JSON.stringify 再 encode）。这些边界没对齐，性能再高也白搭。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
