Uri.TryCreate 是验证 URL 合法性的首选方式，它严格遵循 RFC 3986 规范，校验 scheme、host、port 等完整结构，比正则更准确可靠，且天然支持 IPv6、IDN、localhost 等边缘情况。
用 Uri.TryCreate 判断 URL 合法性最可靠
别急着写正则——C# 自带的 Uri.TryCreate 是验证字符串是否为有效 URL 的首选方式，它遵循 RFC 3986 规范，能处理 scheme、host、port、path、query 等全部结构校验，比手写正则更准、更省心。
常见错误现象：用正则匹配 https?://\S+ 就完事，结果 "http://"、"https:// "（末尾空格）、"http://.." 都被误判为合法；或者漏掉 IPv6、国际化域名（IDN）、带用户信息（user:pass@host）等边缘情况。
-
Uri.TryCreate要求传入UriKind.Absolute，否则相对路径（如/api/user）也会返回true - 必须检查返回的
Uri实例是否非 null，且uri.Scheme在预期范围内（比如只接受"http"和"https"） - 注意：它不校验 host 是否可解析或服务是否可达，只做语法和结构合法性判断
bool IsValidUrl(string url)
{
if (string.IsNullOrWhiteSpace(url)) return false;
return Uri.TryCreate(url, UriKind.Absolute, out var uri) &&
(uri.Scheme == "http" || uri.Scheme == "https");
}正则仅适合粗筛或特定格式约束
正则不是不能用，而是不该作为唯一手段。它适合在 UI 层快速拦截明显非法输入（比如无协议头、含控制字符），或强制要求某类格式（如必须带 www、禁止端口、限定 TLD）。
使用场景：表单前端 JS 预检、日志中提取疑似 URL 字符串、配置项格式提示。
- 简单粗筛可用：
^https?://[^\s/$.?#].[^\s]*$（注意\s要覆盖全角空格、换行等） - 如果要求 host 必须含点（排除
http://localhost），正则反而会误杀；而Uri.TryCreate天然支持localhost、127.0.0.1、[::1] - .NET 的
Regex默认不开启RegexOptions.Compiled，高频调用时注意缓存Regex实例，否则性能损耗明显
注意 Uri.IsWellFormedUriString 的陷阱
这个方法看起来更直接，但容易踩坑：它只检查字符串是否“格式良好”，不验证 scheme 是否注册、host 是否合法，甚至对 "http:///" 这种明显残缺的 URL 也返回 true。
错误现象：Uri.IsWellFormedUriString("http:///", UriKind.Absolute) 返回 true，但后续调用 new Uri(...) 会抛 UriFormatException。
- 它不等价于
Uri.TryCreate，也不做完整解析 - 文档明确建议：需要真正验证 URL 可用性时，优先用
TryCreate - 仅适合极轻量级预过滤，比如从文本中批量提取候选字符串前先过一遍
国际化域名（IDN）和大小写要额外留意
用户可能输入带中文域名（如 https://例子.测试）或大写 scheme（HTTP://EXAMPLE.COM），Uri.TryCreate 默认支持，但部分旧系统或中间件可能不兼容。
-
Uri构造后，uri.Host是 Punycode 编码后的形式（如"xn--fsq.xn--0zwm56d"），若需展示原始 host，得用IdnMapping反解 - scheme 和 host 默认不区分大小写，但 path 和 query 区分；验证逻辑里别用
url.ToLower().StartsWith("https://")这种方式判断协议 - 如果业务要求严格限制 ASCII 域名，需额外检查
uri.Host是否全为 ASCII 字符（uri.Host.All(char.IsAscii)）
实际项目里，URL 验证往往卡在“看似合法却无法访问”——比如 DNS 解析失败、证书过期、被防火墙拦截。这些没法靠 Uri.TryCreate 或正则发现，得靠后续 HTTP HEAD 请求或真实请求兜底。但第一步，先把语法关守住，别让脏数据进下游。
