URL Query字符串形如?key1=value1&key2=value2，含URL编码（如%20、+、%3D）和重复key；不能直接用std::stringstream按&和=拆分，因未解码会导致误切（如foo%3Dbar错拆）、空格/等号解析错误及丢失重复键，须先url_decode再结构化解析。
URL Query字符串长什么样，为什么不能直接用std::stringstream拆
Query部分就是?key1=value1&key2=value2&key3=这种形式，中间用&分隔，键值对用=连接。看起来像键值对集合，但实际要小心：value可能含%20、+（空格编码）、%3D（等号编码），甚至多个同名key（如?tag=a&tag=b）。直接按=和&切分会漏掉解码逻辑，还会把foo%3Dbar错拆成foo和bar。
常见错误现象：url_decode("a%20b")返回"a b"，但没处理+；或忽略重复key，只保留最后一个。
- 必须先做URL decode，再解析结构
- 重复key应保留为vector或允许多次插入（比如
std::multimap） - 空value（如
key=或key）需明确支持
手写解析函数：用std::string_view + std::unordered_multimap
不需要第三方库时，推荐用std::string_view避免拷贝，配合std::unordered_multimap存重复key。核心步骤是：定位?起始位置 → 按&切分每个pair → 对每个pair找第一个= → 左右分别decode。
示例关键逻辑：
立即学习“C++免费学习笔记（深入）”；
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
std::string url_decode(std::string_view s) {
std::string out;
out.reserve(s.size());
for (size_t i = 0; i < s.size(); ++i) {
if (s[i] == '%' && i + 2 < s.size()) {
int v;
if (sscanf(s.data() + i + 1, "%2x", &v) == 1) {
out += static_cast<char>(v);
i += 2;
} else {
out += s[i];
}
} else if (s[i] == '+') {
out += ' ';
} else {
out += s[i];
}
}
return out;
}
-
sscanf比手写十六进制转换更可靠，但要注意%2x匹配失败时跳过 - 不要用
std::stoi或std::stoul处理hex，它们不支持0x前缀且异常开销大 - 如果value里有
=（如data=a%3Db），只取第一个=左边为key，右边全当value
用boost::beast::http::param_list快速解析（C++17+）
如果你项目已用Boost.Beast，boost::beast::http::param_list能直接解析Query字符串，自动处理decode和重复key，且零拷贝（内部用string_view）。但它只接受std::string或string_view输入，且要求Query部分不含?前缀。
使用方式：
std::string query = "name=John%20Doe&city=NYC&tag=%23cpp";
auto params = boost::beast::http::param_list{query};
for (auto const& p : params) {
std::cout << url_decode(p.key) << "=" << url_decode(p.value) << "\n";
}
- 注意：
param_list不保证key顺序，也不聚合同名key —— 它是迭代器范围，重复key会连续出现 - 它不处理
+作空格，所以仍需手动decode key/value（如上例中调用url_decode） - 若Query含无效hex（如
%xz），param_list会截断后续内容，不如手写可控
性能与边界场景：空值、无=、嵌套%
真实URL里常有?debug&format=json这种无value的参数，或?q=%25test（%本身被编码为%25）。这些容易被忽略，导致crash或解析错位。
- 遇到
&key或&key&，应视为key=""（空字符串），不是丢弃 -
%2525要解两次才能得%，但标准做法只解一层 —— 浏览器和服务端通常也只解一层 - 超长Query（>1MB）建议流式解析，避免
std::string一次性分配过大内存 - 多线程下，若复用同一个
url_decode函数，确保它不依赖静态缓冲区
最麻烦的其实是“谁负责解码”——前端JS用encodeURIComponent，后端C++却要对应实现兼容的decode，稍有差异（比如/是否编码）就会出错。别假设两边编码规则完全一致。
