httputility.parsequerystring 返回只读 namevaluecollection，直接赋值报 notsupportedexception；需拷贝 new namevaluecollection(qs) 或改用 queryhelpers.parsequery，注意编码、大小写及 ? 前缀处理。
HttpUtility.ParseQueryString 返回的是只读集合，直接赋值会报错
很多人调用 HttpUtility.ParseQueryString 后想直接改某个参数值，比如：qs["id"] = "123"，结果运行时报 System.NotSupportedException: Collection is read-only。这是因为返回的 NameValueCollection 默认是只读的——它设计初衷就是解析后“看”，不是“改”。
实操建议：
- 如果只需读取参数，直接用
qs["key"]或qs.Get("key")即可 - 如果要修改或构建新查询串，得先转成可写的集合：用
new NameValueCollection(qs)拷贝一份 - 或者更现代的做法：用
Microsoft.AspNetCore.WebUtilities.QueryHelpers.ParseQuery（ASP.NET Core 环境下），返回的是IReadOnlyDictionary<string stringvalues></string>，配合ToString()可安全重建
中文、空格、+ 号会被错误解码，需注意原始编码上下文
HttpUtility.ParseQueryString 内部调用 UrlDecode，而它的默认行为把 + 当作空格处理（符合 application/x-www-form-urlencoded 规范），但如果你传入的是 raw query string（比如从日志里截出来的、没经过表单提交的 URL），里面可能混着未编码的空格或本意就是加号，这时就会误判。
常见错误现象：
- 原始 URL 中的
q=C%2B%2B→ 正确解为"C++"；但若写成q=C++（未编码）→ 被解成"C " - 含中文的 URL 若用 UTF-8 编码后未被正确识别（比如服务器用 GB2312 编码但 .NET 按 UTF-8 解），会导致乱码
实操建议：
- 确保输入字符串是标准 URL 编码格式（即空格为
%20，非+）；若来源不可控，先用Uri.UnescapeDataString手动预处理再传入 - 避免直接解析整个
Uri.Query，因为Uri.Query开头带?，而ParseQueryString不接受这个前缀，必须切掉：HttpUtility.ParseQueryString(uri.Query.Substring(1))
在 .NET Core / .NET 5+ 中，HttpUtility 已不推荐，优先用 QueryHelpers
HttpUtility 在 .NET Core 早期是通过 System.Net.Http 包引入的兼容类型，但它是 System.Web 的遗留产物，没有跨平台语义保证。.NET 5+ 官方明确建议迁移到 Microsoft.AspNetCore.WebUtilities.QueryHelpers（即使不在 ASP.NET 项目中，也可单独引用 Microsoft.AspNetCore.WebUtilities NuGet 包）。
关键差异：
-
QueryHelpers.ParseQuery返回不可变字典，线程安全，且对重复 key 自动合并为StringValues（相当于 string[]） - 重建查询串时，用
QueryHelpers.AddQueryString(originalUri, dict)或手动拼接更可控 - 不会静默吞掉异常 —— 如果传入非法编码（如
%xx不完整），会直接抛FormatException，比HttpUtility更早暴露问题
示例（安全重建）：
var dict = QueryHelpers.ParseQuery(queryString);
var newDict = new Dictionary<string string>(dict) { ["t"] = DateTimeOffset.UtcNow.ToUnixTimeSeconds().ToString() };
var newUrl = QueryHelpers.AddQueryString("https://api.example.com/search", newDict);</string>
别忘了 URL 参数名大小写不敏感，但 ParseQueryString 默认区分
HttpUtility.ParseQueryString 返回的 NameValueCollection 默认是大小写敏感的（内部用 CaseSensitive = true 的哈希表）。而 HTTP 规范中，查询参数名是 case-insensitive 的（ID 和 id 应视为同一参数）。这在对接第三方 API 或做兼容解析时容易出 bug。
实操建议：
- 不要依赖
qs["Id"]和qs["id"]返回相同值；应统一转小写再查：qs[parameterName.ToLower()] - 若需长期复用，封装一个扩展方法：
public static string GetIgnoreCase(this NameValueCollection nvc, string key) => nvc.AllKeys.FirstOrDefault(k => k?.Equals(key, StringComparison.OrdinalIgnoreCase)) switch { null => null, var k => nvc[k] }; - 用
QueryHelpers.ParseQuery则天然规避该问题 —— 它返回的 key 是原始大小写，但你查的时候得自己处理逻辑，框架不替你做 case folding
ParseQueryString 的只读性、编码假设和大小写行为。尤其在混合老代码和新 SDK 时，这些隐性契约最容易引发偶发性解析失败。
