URL参数解析的核心难点在于std::unordered_map键值对构建时易忽略编码规范与边界情况，如空key/value、%XX解码、+号处理等，需手动安全拆分并严格遵循RFC 3986。
URL参数解析的核心难点在哪
不是解码本身难，而是std::unordered_map键值对的构建容易忽略编码规范和边界情况。比如key=后面为空、key=&next=中间有空值、%20要转成空格、+在query里等价于空格——这些不处理，std::unordered_map里存的就不是真实语义值。
手动拆分query string并解码的可靠写法
别依赖第三方库，用标准C++就能搞定。关键步骤是：先按&切出键值对，再对每段按第一个=分割，最后分别解码key和value。
-
std::string::find_first_of('=')比std::string::find('=')更安全，避免把value里的=误当分隔符 - 解码函数必须处理
%XX十六进制序列，且只对合法的%20、%3A等转换，%GZ这种非法格式应原样保留 -
+只在value中替换为空格（URL编码规范），key里出现+不应替换 - 空key（如
&=val）或空value（如key=）都应保留，对应map[""]或map["key"] = ""
示例片段：
std::string url_decode(const std::string& s) {
std::string out;
out.reserve(s.size());
for (size_t i = 0; i < s.size(); ++i) {
if (s[i] == '%' && i + 2 < s.size() &&
std::isxdigit(s[i+1]) && std::isxdigit(s[i+2])) {
out += static_cast<char>(std::stoi(s.substr(i+1, 2), nullptr, 16));
i += 2;
} else if (s[i] == '+') {
out += ' ';
} else {
out += s[i];
}
}
return out;
}
填入std::unordered_map<std::string, std::string>时的陷阱
直接map[key] = value看似简单，但会触发两次哈希计算（一次查找，一次插入），而且无法区分“key不存在”和“key存在但value为空”。实际中更稳妥的做法是用map.emplace()配合std::make_pair。
立即学习“C++免费学习笔记（深入）”；
- 如果URL含重复key（如
a=1&a=2），按RFC 3986应取最后一个，所以顺序遍历+覆盖赋值是正确行为 - 不要用
map.insert({key, value})，它遇到已存在key会静默失败，导致丢数据 - 若需保留所有重复key（如
tags=foo&tags=bar），就得改用std::unordered_multimap，但这是少数场景 - 注意
std::unordered_map的key比较是大小写敏感的，Key和key算两个键——这和多数HTTP服务端行为一致，无需额外转小写
从完整URL提取query部分的边界处理
用户传进来的可能是完整URL（如https://example.com/path?k=v&x=y#frag），也可能是纯query（k=v&x=y）。不能硬切?，得先找?再找#，取二者之间那段。
- 用
url.find('?')定位起始，再用url.find('#', pos)找锚点，避免#在path里被误截断 - 没
?就返回空map；只有?没有=（如?abc），应视作key="abc"、value="" - query开头或结尾的
&（如&k=v&）要跳过，避免生成空key-value对 - UTF-8编码的中文参数（如
name=%E4%BD%A0%E5%A5%BD）解码后仍是合法std::string，std::unordered_map完全支持，不用额外转宽字符
真正麻烦的是嵌套结构（如filter={"a":1}），那已经超出URL参数范畴，属于application/x-www-form-urlencoded的payload解析，得交给JSON库——这不是std::unordered_map该干的事。
