不能直接用+连接URL参数，因为会引发多次内存分配拷贝且忽略URL编码导致请求失败；应使用std::ostringstream配合手动URL编码函数，确保key和value均正确编码并支持UTF-8。
拼接URL参数时，为什么不能直接用 + 连接？
因为 + 拼接字符串在 C++ 中（尤其是频繁操作）会触发多次内存分配和拷贝，std::string 的 operator+ 在每次调用时可能生成临时对象，性能损耗明显。更关键的是：URL 参数必须做编码（比如空格变 %20），直接拼接会漏掉这步，导致请求 400 或后端解析失败。
推荐方案：用 std::ostringstream + 手动编码函数
不用第三方库时，最可控、无依赖、且能兼顾性能与正确性的做法是组合 std::ostringstream 和轻量 URL 编码逻辑。它避免了反复构造 std::string，也比 reserve() + append() 更易读。
- 先写一个简短的编码函数：
std::string url_encode(const std::string& s) { std::string out; for (char c : s) { if ((c >= 'A' && c <= 'Z') || (c >= 'a' && c <= 'z') || (c >= '0' && c <= '9') || c == '-' || c == '_' || c == '.' || c == '~') { out += c; } else { out += '%'; out += "0123456789ABCDEF"[((unsigned char)c) >> 4]; out += "0123456789ABCDEF"[((unsigned char)c) & 15]; } } return out; } - 拼接时统一用
std::ostringstream，避免中间std::string构造：std::ostringstream oss; oss << "https://api.example.com?"; // base oss << "q=" << url_encode("hello world"); oss << "&lang=" << url_encode("zh-CN"); oss << "&limit=" << 10; std::string url = oss.str(); - 注意：如果参数名或值本身含
&、=、?，也必须编码，否则破坏 URL 结构；不要只对 value 编码而忽略 key
用 std::string::append() 预分配内存是否更快？
在已知参数总数和大致长度时，确实快——但前提是预估准确。误估会导致两次分配（一次 reserve 不足，再 realloc），反而更慢。实际项目中，除非 URL 模板固定、参数长度波动极小（如 ID 总是 8 位数字），否则不建议硬算 reserve()。
- 若坚持用
append()，至少对每个 key/value 分别编码后再拼：std::string url; url.reserve(256); // 保守估计总长 url.append("https://api.example.com?"); url.append("q="); url.append(url_encode("hello world")); url.append("&lang="); url.append(url_encode("zh-CN")); -
reserve()只影响 capacity，不影响 length；调用append()后仍需检查是否超出预留空间 - 多个
append()调用之间没有自动加&，极易漏掉分隔符，调试时难定位
遇到中文或 emoji 时，编码函数必须支持 UTF-8 字节流
C++ std::string 本质是字节容器，传入的 std::string 若已是 UTF-8 编码（如来自文件、网络或 u8"你好" 字面量），则上面的 url_encode 函数可直接按字节处理——这是正确的。但若传入的是宽字符（std::wstring）或 GBK 编码字符串，必须先转 UTF-8，否则每个字节单独编码会出错。
立即学习“C++免费学习笔记（深入）”；
- 确认输入是 UTF-8：Linux/macOS 终端、UTF-8 文件读取、现代 JSON 库输出通常都是
- Windows 控制台默认 GBK，
std::cin读入的中文需先用MultiByteToWideChar+WideCharToMultiByte转 UTF-8，或改用std::filesystem::u8path等工具 - emoji 是多字节 UTF-8 序列（如 ? 占 4 字节），编码函数里循环遍历
char是安全的，无需额外处理
