URL编码不能直接用std::hex，因为它需按RFC 3986规则对非保留字符逐UTF-8字节编码为%XX，而std::hex仅格式化整数、不处理字符白名单、多字节序列及语义关键符号（如/、:），易导致乱码或协议错误。
URL编码为什么不能直接用 std::hex 手动拼接
因为URL编码（Percent-encoding）不是简单把字节转成十六进制字符串，它有明确的字符白名单和编码边界：只有字母、数字、-、_、.、~ 这些字符不编码，其余全部按UTF-8字节逐个处理。手动用 std::hex 容易漏掉多字节UTF-8序列（比如中文变成3个%xx），更危险的是会错误编码本该保留的斜杠/或冒号:——这些在路径或查询参数里语义关键，不能乱动。
实操建议：
- 先将输入字符串按UTF-8解码为Unicode码点（推荐用
std::string_view+ 手动解析，或轻量库如utf8cpp），再对每个码点判断是否属于RFC 3986 unreserved集合 - 对需要编码的码点，先UTF-8编码回字节序列，再对每个字节做
%XX格式化（大写十六进制） - 绝对不要对原始
std::string的每个char直接static_cast<unsigned char>后编码——这在Windows本地编码（如GBK）下会彻底错乱
curl_easy_escape 能不能直接用？
可以，但仅限于C接口场景且不介意引入libcurl依赖。它的行为符合RFC标准，会正确处理UTF-8，并跳过/、?、=等分隔符——这是比手写更省心的地方。但它不提供C++友好的接口，返回的是char*需手动curl_free，且无法控制大小写（固定大写%XX）。
常见错误现象：
立即学习“C++免费学习笔记（深入）”；
- 忘记调用
curl_free→ 内存泄漏 - 传入非UTF-8字符串（如Windows上用
GetACP()获取的ANSI字符串）→ 编码结果不可预测 - 在无libcurl环境（嵌入式、纯头文件项目）中编译失败
替代方案：用 std::ostringstream + std::setfill('0') << std::setw(2) << std::uppercase << std::hex 构建编码逻辑，完全可控。
URL解码时遇到 %AB 不全或大小写混用怎么办
合法URL解码必须容忍大小写（%ab 和 %AB 等价），且要拒绝不完整转义（如末尾单独一个%，或%G这种非法十六进制）。很多手写解码函数只检查%[0-9A-Fa-f]{2}却忽略边界，导致缓冲区越界或静默跳过错误。
实操建议：
- 遍历字符串时，遇到
%立即检查后续两个字符是否存在且为十六进制字符；否则原样保留%并继续 - 用
std::stoi(..., nullptr, 16)解析时捕获std::out_of_range和std::invalid_argument，失败则保留原始%XX片段 - 解码后的字节流必须按UTF-8重新验证：调用
utf8::is_valid（来自utf8cpp）或手动检查首字节范围（0xC0–0xF4）和后续字节（0x80–0xBF）
查询参数场景下，要不要对整个query string整体编码
不要。URL的query部分是键值对结构（key=value&key2=value2），= 和 & 是分隔符，必须明文存在。正确做法是分别对每个key和每个value单独编码，再拼接。
例如：search=hello world&lang=zh-CN 中：
-
hello world→ 编码为hello%20world -
zh-CN→ 不编码（-在unreserved列表中） - 最终拼出：
search=hello%20world&lang=zh-CN
如果对整个字符串编码，会把=和&也变成%3D和%26，后端根本无法解析。
最易被忽略的一点：空字符串、纯空白字符串、含U+0000的字符串，在编码/解码前后长度可能突变，务必在边界测试中覆盖这些case。尤其是解码后UTF-8校验失败时，不应抛异常，而应退化为原样返回——网络数据不可信，健壮性比严格性更重要。
