绝大多数场景下应使用 Uri.EscapeDataString，它符合 RFC 3986，正确编码中文、emoji 等 Unicode 字符及空格、/、? 等不安全字符；Uri.EscapeUriString 仅适合可信静态路径拼接，不推荐用于参数编码。
URL编码该用 Uri.EscapeDataString 还是 Uri.EscapeUriString
绝大多数场景下，应该用 Uri.EscapeDataString。它对除字母、数字和少数安全字符（如 -_.~）外的所有字符做百分号编码，且会正确处理 Unicode 字符（如中文、emoji），符合 RFC 3986 对“URI 通用数据”的编码要求。
Uri.EscapeUriString 只编码 URI 中的“不安全字符”，但会放过很多需要转义的字符（比如空格、/、?、=），容易导致生成的 URL 被解析出错。它只适合拼接整个 URI 的某一段（如已知是路径片段且不含用户输入），不推荐用于参数值编码。
- 传参、表单提交、API 请求参数 → 必须用
Uri.EscapeDataString - 手动拼接完整 URL（如
https://api.com/+ path）→ 若 path 是可信静态路径，可考虑Uri.EscapeUriString，但更稳妥仍是EscapeDataString - 对已有 URL 再次编码 → 不要嵌套调用，先解码再重编码，否则出现
%2520这类双重编码
为什么 HttpUtility.UrlEncode 在 .NET Core/.NET 5+ 里不能直接用
HttpUtility 属于 System.Web 命名空间，原为 ASP.NET Web Forms 设计，在 .NET Core 及之后版本中默认不可用。若项目是控制台、类库或现代 ASP.NET Core Web API，直接引用会报错：The type or namespace name 'HttpUtility' does not exist。
解决方案有两个：
- 安装 NuGet 包
System.Net.Http（.NET Core 3.1+ 已内置，无需额外装）→ 实际仍应优先用Uri.EscapeDataString，它更轻量、无依赖、语义更清晰 - 若必须兼容老代码或需保持与 ASP.NET Framework 行为一致（如空格编码为
+而非%20），可引入Microsoft.AspNetCore.WebUtilities，使用WebEncoders.Base64UrlEncode或WebEncoders.UrlEncode（注意：它空格编码为%20，不是+）
中文、emoji、特殊符号编码后是否可逆
只要全程使用同一标准（推荐 Uri.EscapeDataString 编码 + Uri.UnescapeDataString 解码），就能完全还原，包括中文、繁体字、日文假名、emoji（如 ?）、数学符号（∑、≠）等。
常见翻车点：
- 用
Uri.EscapeUriString编码中文 → 部分字符不被编码，URL 传到服务端后因未标准化被截断或 400 错误 - 前端 JS 用
encodeURIComponent，后端 C# 用Uri.EscapeUriString解码 → 不匹配，解码失败或乱码 - 字符串含换行符
\n或制表符\t→ 它们会被编码为%0A、%09，但某些旧系统可能不支持，需提前清理或约定过滤
性能差异大吗？要不要缓存编码结果
单次 Uri.EscapeDataString 调用耗时在纳秒级（实测平均约 50–200 ns），远低于网络 I/O 或磁盘操作。除非你在 tight loop 里每秒调用百万次以上，否则无需缓存。
但要注意：编码是纯函数操作，输入相同则输出一定相同。如果某个字符串被高频复用（如固定 token 模板、静态资源路径），且确定永不变更，可缓存其编码结果以省去重复计算 —— 但这属于微优化，优先级很低。
真正该关注的是编码位置：避免在循环内反复拼接再编码（如 for { s += x; encoded = Escape(s); }），应先拼好完整字符串，再整体编码一次。
