httputility.parsequerystring 是解析 querystring 的最直接方法，自动 url 解码但仅保留重复键的最后一个值；需用 uri.getcomponents 安全提取 query 字符串，asp.net core 中应优先使用 httprequest.query。
用 HttpUtility.ParseQueryString 解析 QueryString 最直接
在 .NET Framework 和 .NET Core / .NET 5+（需引用 System.Web 兼容包）中，HttpUtility.ParseQueryString 是最常用的内置方法。它把查询字符串（如 "name=alice&age=30&tags=c%23,web"）转成可读写的 NameValueCollection。
注意：这个方法会自动 URL 解码值（比如 %20 → 空格），但不会处理重复键的合并逻辑——相同键多次出现时，只保留最后一个值。
- 若原始 URL 是
https://example.com/?q=test%2Bvalue&sort=desc，先用new Uri(url).Query提取?...后的部分，去掉开头的?再传入 - 不要直接传完整 URL，否则解析结果为空或出错
- .NET Core 6+ 默认不带
System.Web，需安装 NuGet 包System.Web.HttpUtility（仅限兼容场景）
用 Uri.GetComponents + Query 安全提取原始 Query 字符串
很多初学者直接对 Uri.Query 调用 Substring(1) 去掉问号，但当 URL 不含查询参数时，Uri.Query 返回空字符串，Substring(1) 会抛 ArgumentOutOfRangeException。
更健壮的做法是用 uri.GetComponents(UriComponents.Query, UriFormat.Unescaped)，它天然忽略无 Query 的情况，且返回值不含开头的 ?。
Uri uri = new("https://a.com/path?x=1&y=2");string query = uri.GetComponents(UriComponents.Query, UriFormat.Unescaped); // "x=1&y=2"- 之后再喂给
HttpUtility.ParseQueryString或手动解析 - 避免用
Split('?')或正则硬切 —— URL 中的 fragment（#）或 path 里也可能含?
手动解析时别忽略 + 和编码边界
如果不用 HttpUtility（比如在无 Web 环境、或需自定义逻辑），手动解析必须还原两个关键点：+ 要转为空格，且所有 %xx 要解码。但不能简单用 Replace("+", " ") 后再 UrlDecode，因为 UrlDecode 本身已处理 +，重复操作会导致错误。
- 正确顺序：先
WebUtility.UrlDecode(queryPart)（.NET Core 推荐）或HttpUtility.UrlDecode(queryPart) - 错误写法：
query.Replace('+', ' ').Replace("%20", " ").Replace("%3D", "=")...—— 漏解、重叠、易崩 - 键值分割用第一个
=，值部分可能含=（如data=a%3Db%3Dc→data="a=b=c"），所以不能用Split('=') - 多个同名参数（
a=1&a=2）需自己存为List<string></string>，NameValueCollection不支持
ASP.NET Core 中优先用 HttpRequest.Query
如果你在 ASP.NET Core 的 Controller 或 Middleware 里获取参数，根本不用碰原始字符串 —— HttpContext.Request.Query 已是 IQueryCollection，支持索引、枚举、多值访问，且自动解码、线程安全、兼容空值。
var name = context.Request.Query["name"]; // Microsoft.Extensions.Primitives.StringValuesif (name.Count > 0) { string actual = name[0]; }var allTags = context.Request.Query["tags"].ToArray(); // 处理逗号分隔的值时再拆- 不要在非 HTTP 上下文（如控制台、类库）里硬引用
HttpContext，会引入不必要的依赖
真正容易被忽略的是：QueryString 的大小和编码合法性没人帮你校验。超长参数、非法 UTF-8 字节序列、嵌套 URL 编码（如 %2520）都可能导致解码失败或静默截断 —— 如果业务敏感，得加 try/catch 并记录原始 query 值用于排查。
