htmlagilitypack 是 c# 中解析 html 并安全提取 a 标签 href 属性的首选方案，需用 selectnodes("//a[@href]") 和 getattributevalue 避免空引用，注意相对路径补全、编码处理、反爬策略及 cloudflare 等 js 渲染障碍。
用 HtmlAgilityPack 解析 HTML 并提取全部 a 标签的 href
直接用正则匹配 HTML 链接是危险且不可靠的——嵌套、注释、JS 字符串、属性顺序变化都会导致提取失败。必须用真正的 HTML 解析器。HtmlAgilityPack 是 C# 生态中最稳定、兼容性最好的选择，支持 malformed HTML（比如缺少闭合标签），且不依赖浏览器引擎。
安装后（NuGet 包管理器中安装 HtmlAgilityPack），核心逻辑只有几行：
var htmlDoc = new HtmlDocument();
htmlDoc.LoadHtml(htmlString); // 或用 Load() 加载远程 URL（需手动处理重定向和编码）
var links = htmlDoc.DocumentNode.SelectNodes("//a[@href]")
?.Select(a => a.GetAttributeValue("href", string.Empty))
.Where(href => !string.IsNullOrWhiteSpace(href))
.ToList();
-
SelectNodes("//a[@href]")确保只取带href属性的a标签，排除空链接或 JS 伪链接（如href="javascript:void(0)"） - 务必调用
GetAttributeValue("href", ...)而非直接读Attributes["href"].Value，避免NullReferenceException - 注意：返回的
href是原始值，可能是相对路径（如"./page.html"）、协议相对（"//cdn.example.com/style.css"）或完整 URL；后续需用Uri.TryCreate()+Uri.IsWellFormedUriString()判断并补全
处理重定向、编码与 HTTPS 证书问题
很多网页会 302 跳转，或声明了 charset=gb2312 却用 UTF-8 返回内容，或使用自签名/过期证书——这些都会让 WebClient 或默认 HttpClient 直接失败或乱码。
- 用
HttpClient替代已过时的WebClient，并显式设置HttpClientHandler.ServerCertificateCustomValidationCallback来跳过证书校验（仅开发调试用，生产环境必须验证） - 响应头中的
Content-Type可能含charset，但实际内容编码可能不一致；建议先用Encoding.Default或Encoding.UTF8尝试解码，再用HtmlDocument.DetectEncoding()辅助判断 - 对重定向，不要依赖
HttpClientHandler.AllowAutoRedirect = true——它会丢失中间跳转的 headers 和状态码；更稳妥的是手动发起请求，检查response.StatusCode == HttpStatusCode.Redirect并读取response.Headers.Location
避免被封：User-Agent、延迟与 Referer 不是可选项
目标网站只要加了基础反爬（比如 Nginx 的 limit_req 或 Python 的 scrapy-useragents 规则），裸发请求基本秒拒。HTTP 状态码 403 或空响应体（但状态码 200）是典型信号。
- 必须设置
User-Agent请求头，值要接近真实浏览器（如"Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36"），不能用默认的"dotnet" / "HttpClient" - 加
Referer头（尤其当目标链接来自某列表页时），否则部分站点会拦截（例如某些 CDN 会校验Referer防盗链） - 两次请求之间至少
Thread.Sleep(1000)，别迷信“并发快”——多数小站服务器扛不住 5 QPS，频繁触发限流反而进黑名单 - 如果目标站用 Cloudflare，
HtmlAgilityPack本身无法执行 JS，你拿到的 HTML 很可能是 challenge 页面；此时需换方案（如 PuppeteerSharp），但那已超出“简易爬虫”范畴
相对 URL 补全和去重的坑比想象中多
一个页面里常有几十个链接，其中大量是重复的分页参数（?page=1 vs ?page=1&sort=date）、带跟踪参数的（?utm_source=xxx）、或同一资源的不同写法（/about vs /about/ vs https://site.com/about）。
- 用
Uri.TryCreate(baseUri, relativeUrl, out Uri result)补全相对路径，baseUri应为原始请求 URL，不是 DOM 中的<base href="...">（该标签极少被设，且优先级易混淆） - 去重要基于规范化的绝对 URL：先统一 scheme（全转
https），再移除末尾斜杠、排序查询参数、去掉常见跟踪参数（utm_*,ref=等），最后再哈希或用HashSet<string></string> - 注意：有些链接看起来一样，但实际指向不同内容（如通过 Cookie 或 UA 动态生成），这种只能靠业务逻辑识别，库解决不了
真正难的从来不是“怎么取到 href”，而是怎么让每次取都稳定、不被拦、不漏页、不重复抓——这些细节堆起来，才构成一个能跑通一周以上的爬虫。
