HttpUtility.ParseQueryString 是解析 URL 查询字符串最直接的方法，专为处理 URL 编码、空值、重复键等设计，返回 NameValueCollection，需注意 null 输入抛异常、不区分大小写、须提取 query 部分传入，.NET Core/5+ 需安装 System.Web.HttpUtility 包。
用 HttpUtility.ParseQueryString 解析 URL 查询字符串最直接
这个函数专为这事设计，能自动处理 URL 编码、空值、重复键等常见情况，比手动 Split 安全得多。它返回的是 NameValueCollection，不是字典，但可以轻松转成 Dictionary<string string></string> 或更实用的 Dictionary<string string></string>（因为同一个参数名可能出现多次）。
常见错误现象：HttpUtility.ParseQueryString 对空查询串（如 "" 或 "?"）返回空集合，但若传入 null 会抛 ArgumentNullException；另外，它不区分大小写，默认把键转成小写（Windows 平台行为，.NET Core/.6+ 跨平台一致）。
- 使用前先检查 URL 是否含
"?"，提取query部分再传入，别直接丢整个 URL 字符串进去 - 如果需要保留原始大小写或支持重复键合并逻辑，别直接转
Dictionary<string string></string>，改用.AllKeys.ToDictionary(k => k, k => query.GetValues(k)) - .NET 5+ 可考虑
Microsoft.AspNetCore.WebUtilities.QueryHelpers.ParseQuery，它返回IDictionary<string stringvalues></string>，语义更清晰，且天然支持多值
手动解析时别用 string.Split('&') 简单切分
URL 参数里可能有未编码的 & 或 =（比如在值里），也可能有空格、中文、加号等，纯字符串切分极易出错。真实场景中，用户提交的链接可能来自微信、邮件、旧系统，编码混乱很常见。
性能影响不大，但正确性差太多：一次 Split + Split 就漏掉编码还原、+ 号转空格、%xx 解码这些步骤，结果字典里全是乱码或截断值。
- 必须用
Uri.UnescapeDataString或WebUtility.UrlDecode处理每个键和值，不能跳过 -
value中的+要单独替换成空格（UrlDecode会处理，但自己写解析时容易忘） - 遇到无值参数（如
?a&b=1），a的值应为空字符串，不是null；手动解析时容易忽略这点
注意 HttpUtility.ParseQueryString 在 .NET Core / .NET 5+ 中需引用 System.Web
这在控制台或类库项目里常被忽略——编译报错 The name 'HttpUtility' does not exist，不是你写错了，是缺 NuGet 包。
兼容性影响明显：.NET Framework 自带，但 .NET Core 从 3.0 开始移除 System.Web，现在得显式安装 System.Web.HttpUtility（注意包名不是 System.Web）。
- 推荐命令行安装：
dotnet add package System.Web.HttpUtility - 如果项目已用 ASP.NET Core，优先改用
QueryHelpers.ParseQuery，它在Microsoft.AspNetCore.WebUtilities包里，无需额外引入 Web 相关依赖 - Unity 或某些精简运行时环境不支持
HttpUtility，此时只能手写解析，务必加上 try/catch 和边界校验
重复参数名（如 ?tag=csharp&tag=webapi）怎么存才合理
很多 API 和前端表单会发多个同名参数，NameValueCollection 的 GetValues 能拿到全部值，但默认 ToString() 或 this[key] 只返回第一个。直接转 Dictionary<string string></string> 会静默丢数据。
这不是 bug，是设计选择：你要的是“最后出现的值”还是“所有值”？不同业务场景要求不同。
- 日志分析、调试查看时，用
query.AllKeys.ToDictionary(k => k, k => query.GetValues(k))得到Dictionary<string string></string> - 调用下游 HTTP 接口时，多数 SDK 只认单值，这时可用
query[k]?.FirstOrDefault()显式取第一个 - 如果想合并成逗号分隔字符串（如
tag=csharp,webapi），别在解析阶段做，留到业务层按需处理，避免污染原始结构
真正容易被忽略的是：URL 解析不是纯技术活，它紧贴业务语义。同一个 id 出现两次，可能是前端误发，也可能是合法的批量操作。解析器只负责还原原始输入，别替业务做判断。
