URL参数解析最稳方案是先用Uri提取Query，再用HttpUtility.ParseQueryString（.NET Core需装NuGet包）或.NET 6+的QueryHelpers.ParseQuery；注意其返回只读集合，修改需重建字符串。
URL参数解析用 Uri + HttpUtility.ParseQueryString 最稳
直接拼字符串或正则拆 ?key=value&foo=bar 容易漏掉编码、空值、重复键等边界情况。C# 自带的 HttpUtility.ParseQueryString 就是干这个的，但它不接受裸 URL 字符串——必须先用 Uri 提取查询部分。
常见错误：传整个 URL 给 ParseQueryString，结果返回空或异常；或者忽略 System.Web 命名空间依赖（.NET Core/.NET 5+ 需额外安装 System.Web.HttpUtility NuGet 包）。
实操建议：
- 先用
new Uri(url)构造对象，再取.Query属性（带?），传给HttpUtility.ParseQueryString - 若 URL 可能不合法，加 try/catch 或用
Uri.TryCreate - .NET 6+ 推荐用
Microsoft.AspNetCore.WebUtilities.QueryHelpers.ParseQuery替代（无需引用 System.Web）
示例：
var url = "https://example.com/path?a=1&b=%E4%BD%A0&c=&d=2&d=3";<br>var uri = new Uri(url);<br>var query = HttpUtility.ParseQueryString(uri.Query); // 注意：uri.Query 是 "?a=1&b=..."<br>// query["a"] → "1"<br>// query["b"] → "你"（自动解码）<br>// query["c"] → ""（空值保留）<br>// query["d"] → "2"（只取第一个，多值需用 GetValues）
ParseQueryString 返回的是只读集合，改不了
很多人想直接 query["x"] = "new" 再拼回去，会报错：返回的 NameValueCollection 是只读的。这不是 bug，是设计使然——它只负责解析，不负责构造。
使用场景：你要做参数修改（比如删掉 utm_source、追加 ts=123），就得自己重建查询字符串。
实操建议：
- 用
query.GetValues("key")拿多值数组（比如同名参数出现多次） - 需要写操作时，转成
Dictionary<string string></string>或List再处理 - 拼新 query 字符串别手写
&和=，用string.Join("&", pairs.Select(p => $"{Uri.EscapeDataString(p.key)}={Uri.EscapeDataString(p.value)}"))
注意 Uri 对路径和查询的解析规则
Uri 构造时会自动标准化路径（比如合并 /a/../b → /b），但**不会**帮你解码查询参数里的百分号编码——那是 ParseQueryString 干的。容易踩的坑是：以为 uri.Query 是“原始字符串”，其实它已经把 URL 中非法字符做了容错处理，甚至可能悄悄修正了格式错误。
性能影响：频繁 new Uri 开销不大，但若在循环里反复解析同一类 URL，可缓存 Uri 实例或预提取 Query 字符串。
兼容性提醒：
- 含中文或特殊符号的 URL，如果没被正确编码（如直接写
?name=张三），Uri构造可能失败或截断 - 某些老旧服务返回的 query 含空格（未编码为
%20），Uri会把它当分隔符吃掉，导致解析出错
不要用 Split('?') 或正则硬切
看似简单：“url.Split('?')[1].Split('&')”，但实际线上 URL 经常有这些情况：https://a.b/c?x=1&y=2&z（z 没值）、?a=b=c（等号在值里）、?q=hello%20world（空格编码）、?token=abc&sig=xyz&token=def（重复键）。手撕逻辑很快失控。
更隐蔽的问题：不同浏览器对 URL 编码策略略有差异，服务端也可能返回非标准格式。靠字符串切片等于放弃所有容错能力。
实操底线：
- 只要 URL 来自外部（用户输入、日志、第三方 API），一律走
Uri+ 标准解析器 - 只有在确定 URL 绝对干净、且性能极端敏感（微秒级）的嵌入式场景，才考虑定制解析——但那已不是 C# 的常规需求
真正难的不是怎么取参数，而是判断哪些参数该信任、哪些要过滤、哪些要重编码再发出去。这部分没银弹，得结合业务定规则。
