简介这是一份面向C#初学者的邮箱获取器完整源码通过正则表达式从网页或文本中批量提取邮箱地址适合想掌握文本匹配与自动化提取的开发者。资源包共28个文件压缩后仅172KB包含6个.cs源码文件、4个.exe可执行程序、2个.resx资源文件、2个.pdb调试文件另附CHM格式的正则表达式API手册、使用说明文本和示例图片目录结构十分精简。目前已有110人学习浏览。阅读源码可系统了解System.Text.RegularExpressions命名空间下Regex类的Matches、IsMatch等核心方法对正则模式的定义、数据源读取、匹配结果遍历和异常处理形成完整认识还能学习用StreamReader或WebClient读取HTML/文本数据。资源虽小却把“定义规则—提取数据—保存结果”的完整链路呈现得十分清晰适合边读边修改扩展对后续爬虫开发、数据分析中的文本清洗也有直接帮助。1. 邮箱获取器到底解决什么问题先想清楚抓什么再写代码刚转岗做海外市场那阵子每天最机械的活儿就是从客户官网、行业目录页里手动找邮箱。复制粘贴一上午能整理两百个就算快还总有重复和失效地址。后来我把这个活写成了小工具输入一批种子网址自动抓取页面、提取公开邮箱、验证有效性最后导出一张干净的 CSV。这就是你们看到的邮箱获取器 C# 源码的方向——它不是一个能自动爆破、遍历全网邮箱的黑匣子而是一个帮你把「公开页面上已存在的邮箱」自动化收集、去重、初筛的实用工具。这套源码的核心链路只有四段抓取网页、正则提取、有效性验证、导出结果。适合两类人一类是有批量收集公开商务联系邮箱需求的从业者另一类是正在学 C# 网络编程、想完整走一遍 HttpClient 正则 异步 IO 的新手。先说清楚边界它只采集公开网页上主动公示的联系邮箱不做猜测、不碰未授权数据这也是整篇文章所有实现的前提。2. 邮箱提取核心正则的边界条件与去重策略2.1 邮箱匹配的正则怎么写才不漏不滥邮箱正则看起来简单写起来全是细节。最基础的写法string pattern [a-zA-Z0-9._%-][a-zA-Z0-9.-]\.[a-zA-Z]{2,}; Regex emailRegex new Regex(pattern, RegexOptions.IgnoreCase | RegexOptions.Compiled);这个正则在纯文本页面上表现不错但扔到真实网页里会出现大量误报。图片占位符image2x.jpg、CSS 里的media片段、JS 里的userexample.com这种示例地址都会命中。所以我在实际项目里从不直接用这种裸正则而是把它拆成三段校验逻辑。第一段是正则初筛第二段是结构校验第三段是黑名单拦截。结构校验的逻辑是邮箱本地部分长度限制在 64 个字符以内域名部分不超过 255 个字符顶级域不少于 2 个字母且必须是字母。这能挡掉ab、ab.c这类明显不完整的地址。黑名单拦截则针对那些高频出现在代码注释、文档示例里的域名。public static bool LooksLikeRealEmail(string raw) { if (string.IsNullOrWhiteSpace(raw) || raw.Length 320) return false; // 去掉常见的 HTML 实体和首尾引号 raw raw.Trim().Trim(, \, , , (, )); raw raw.Replace(amp;, ).Replace(#64;, ); int atIndex raw.LastIndexOf(); if (atIndex 0 || atIndex ! raw.IndexOf()) return false; string local raw.Substring(0, atIndex); string domain raw.Substring(atIndex 1); if (local.Length 64 || domain.Length 255) return false; if (local.StartsWith(.) || local.EndsWith(.) || local.Contains(..)) return false; if (domain.StartsWith(.) || domain.EndsWith(.) || !domain.Contains(.)) return false; // 顶级域必须是 2 个以上字母且不含数字或连字符 string topLevel domain.Substring(domain.LastIndexOf(.) 1); if (topLevel.Length 2 || !topLevel.All(char.IsLetter)) return false; return true; }这里有个关键点不要用多个同时存在的地址真实邮箱只会有一个。LastIndexOf和IndexOf比较能快速拦掉这种情况。2.2 黑名单与场景过滤先杀掉示例域名和代码噪声正则过了不代表能用。userexample.com、namedomain.com、testtest.com这类地址格式完全合法但不是真实业务联系人。我一般维护一个静态黑名单集合把这些高频示例域名直接过滤掉private static readonly HashSetstring BlockedDomains new HashSetstring(StringComparer.OrdinalIgnoreCase) { example.com, example.org, example.net, test.com, test.org, test.net, domain.com, domain.net, sentry.io, localhost }; public static bool IsBlockedDomain(string domain) { string lower domain.ToLowerInvariant(); return BlockedDomains.Any(d lower d || lower.EndsWith(. d)); }除了域名黑名单还要看邮箱出现的上下文。网页的 footer、contact 区块里的邮箱可信度最高藏在>using var client new HttpClient(); string html await client.GetStringAsync(url);这段代码能跑但跑不了几次就会遇到连接被重置、请求超时、被服务器拒绝。原因在于HttpClient的默认配置太脆弱。我一般会包装一个独立的抓取类把几个关键参数全部显式设置public class WebFetcher { private readonly HttpClient _client; public WebFetcher() { var handler new HttpClientHandler { AllowAutoRedirect true, // 允许跟随 301/302 跳转 MaxAutomaticRedirections 5, // 最多跳转 5 次防止死循环 AutomaticDecompression DecompressionMethods.GZip | DecompressionMethods.Deflate }; _client new HttpClient(handler); _client.Timeout TimeSpan.FromSeconds(20); // 模拟常见浏览器的 User-Agent很多站点会拒绝空 UA _client.DefaultRequestHeaders.UserAgent.ParseAdd( Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0 Safari/537.36); _client.DefaultRequestHeaders.Add(Accept, text/html,application/xhtmlxml); _client.DefaultRequestHeaders.Add(Accept-Language, zh-CN,zh;q0.9,en;q0.8); } public async Taskstring? FetchAsync(string url, CancellationToken ct default) { try { using var resp await _client.GetAsync(url, HttpCompletionOption.ResponseHeadersRead, ct); if (!resp.IsSuccessStatusCode) return null; byte[] bytes await resp.Content.ReadAsByteArrayAsync(); return DecodeHtml(bytes, resp) ; } catch (HttpRequestException ex) { Console.WriteLine($[抓取失败] {url} - {ex.Message}); return null; } catch (TaskCanceledException) { Console.WriteLine($[超时] {url}); return null; } } }三个参数值得重点说明。Timeout设成 20 秒是个折中值。太短5 秒以内国内访问海外站、或对方服务器响应慢时频繁超时太长60 秒以上程序会卡死在某个慢网站上拖慢整体进度。AutomaticDecompression开启后请求头会自动带上Accept-Encoding: gzip, deflate响应体自动解压能省掉不少流量也避免拿到压缩后的乱码。AllowAutoRedirect一定要开着很多网站在迁移后只保留新域名旧域名返回 301不开跳转跟随就抓不到内容。DecodeHtml方法处理的是编码问题放到第 5 章详细说这里先用一个简单实现优先读取响应头里的charset读不到就用 UTF-8 解码。3.2 从 HTML 里抽文本不要用正则解析 HTML拿到 HTML 字符串后很多人会顺手用正则去抓邮箱。这个思路在简单页面能行遇到嵌套标签、注释、script 块就乱了。比如邮箱恰好出现在scriptvar contact ab.com;/script里正则照样能匹配到但这个邮箱是给前端 JS 用的可能是假地址也可能已经更新到了别处。更稳妥的做法是用 HTML 解析库把页面拆成文本节点再在文本节点上跑邮箱正则。using HtmlAgilityPack; public static Liststring ExtractEmailsFromHtml(string html) { var doc new HtmlDocument(); doc.LoadHtml(html); // 先移除 script 和 style 标签里的内容减少噪声 foreach (var node in doc.DocumentNode.SelectNodes(//script|//style|//noscript) ?? Enumerable.EmptyHtmlNode()) node.Remove(); var emails new HashSetstring(StringComparer.OrdinalIgnoreCase); // 从纯文本节点里提取 foreach (var node in doc.DocumentNode.SelectNodes(//text()) ?? Enumerable.EmptyHtmlNode()) { string text node.InnerText; foreach (Match match in Regex.Matches(text, EmailPattern)) { string candidate match.Value; if (LooksLikeRealEmail(candidate) !IsBlockedDomain(candidate.Split()[1])) emails.Add(candidate); } } // 再从 mailto: 链接里提取 foreach (var link in doc.DocumentNode.SelectNodes(//a[href]) ?? Enumerable.EmptyHtmlNode()) { string href link.GetAttributeValue(href, ); if (href.StartsWith(mailto:, StringComparison.OrdinalIgnoreCase)) { string addr href.Substring(7).Trim(); int qIndex addr.IndexOf(?); if (qIndex 0) addr addr.Substring(0, qIndex); if (LooksLikeRealEmail(addr)) emails.Add(addr); } } return emails.ToList(); }为什么先移除script和style因为前端代码里经常出现media、keyframes、字符串拼接邮箱等干扰项。去掉之后纯文本节点和mailto:链接里的邮箱基本是页面主动展示给访客看的。mailto:链接的优先级比纯文本更高——文本节点里可能是 OCR 错误或人为混淆的地址而mailto:是页面作者明确留的联系方式。用HashSet而不是List来收集结果在提取阶段就完成去重后面导出时不用再跑一遍。4. 邮箱有效性验证MX 记录与 SMTP 握手的配合使用4.1 为什么先查 MX 记录格式合法不等于邮箱存在很多源码到这里就结束了抓完、提取完、去重完直接导出 CSV。但这份数据拿出去用退信率可能超过三成。无效邮箱不只是浪费发送配额还会拉低域名信誉严重的会被邮件服务商拉黑。所以完整的获取器必须包含有效性验证环节。验证分两级。第一级是查 MX 记录——判断这个邮箱所在的域名是否配置了邮件交换服务器。如果一个域名没有 MX 记录说明这个域根本不收邮件邮箱必然无效。这一步成本低、速度快能用 DNS 查询完成不需要建立任何 TCP 连接。using DnsClient; public static async Taskbool HasMxRecordAsync(string domain) { var lookup new LookupClient(); try { var result await lookup.QueryAsync(domain, QueryType.MX); var records result.Answers.MxRecords().ToList(); // 有些域名只配置了 A 记录但没 MX这时不能直接判死 // 按 RFC 5321如果没有 MX 记录邮件会投递到域名的 A 记录地址。 if (records.Count 0) { var aResult await lookup.QueryAsync(domain, QueryType.A); return aResult.Answers.ARecords().Any(); } return records.Any(r !string.IsNullOrEmpty(r.Exchange)); } catch (DnsResponseException) { return false; } }判断逻辑里有两条边界要讲清楚。大多数域名会同时配置 MX 和 A 记录但少量小站点只设了 A 记录按邮件协议标准这种情况下邮件投递会回退到 A 记录指向的 IP。所以我不能只看 MX 为空就直接判无效还要补一个 A 记录检查。LookupClient没指定 DNS 服务器时会读取系统网络配置里的 DNS和你在命令行nslookup用的同一个。这在本地工具里够用了但如果部署到某些云主机上系统 DNS 可能不稳定建议显式指向公共 DNS 服务器var lookup new LookupClient(new IPEndPoint(IPAddress.Parse(8.8.8.8), 53));4.2 SMTP 握手验证不发信也能判断邮箱是否存在MX 记录只能证明域名收邮件不能证明具体邮箱存在。第二级验证是 SMTP 对话连接邮件服务器的 25 端口依次发送EHLO、MAIL FROM、RCPT TO三条指令。如果RCPT TO返回250邮箱大概率存在返回550或551邮箱不存在。using System.Net.Sockets; using System.Text; public static async Taskbool VerifyEmailSmtpAsync(string email, string fromAddress, int timeoutMs 10000) { string domain email.Split()[1]; // 先用前面的 MX 查询拿到交换服务器地址 var lookup new LookupClient(); var mxResult await lookup.QueryAsync(domain, QueryType.MX); string host mxResult.Answers.MxRecords() .OrderBy(r r.Preference) .FirstOrDefault()?.Exchange; if (string.IsNullOrEmpty(host)) return false; using var tcp new TcpClient(); using var cts new CancellationTokenSource(timeoutMs); try { await tcp.ConnectAsync(host, 25, cts.Token); using var stream tcp.GetStream(); using var reader new StreamReader(stream, Encoding.ASCII, false, 4096); using var writer new StreamWriter(stream, Encoding.ASCII) { NewLine \r\n }; // 1. 读服务器的初始 banner string banner await reader.ReadLineAsync(); if (banner null || !banner.StartsWith(220)) return false; // 2. 发送 EHLO有些服务器只支持 HELOEHLO 失败时退化为 HELO await writer.WriteLineAsync($EHLO local-checker); await writer.FlushAsync(); string ehloResp await reader.ReadLineAsync(); if (ehloResp null || !ehloResp.StartsWith(250)) return false; // 3. 用 fromAddress 作为发件人发起握手 await writer.WriteLineAsync($MAIL FROM:{fromAddress}); await writer.FlushAsync(); string mailResp await reader.ReadLineAsync(); if (mailResp null || !mailResp.StartsWith(250)) return false; // 4. 关键一步验证收件人是否存在 await writer.WriteLineAsync($RCPT TO:{email}); await writer.FlushAsync(); string rcptResp await reader.ReadLineAsync(); if (rcptResp null) return false; return rcptResp.StartsWith(250) || rcptResp.StartsWith(251); } catch (SocketException ex) { Console.WriteLine($[SMTP连接失败] {host} - {ex.Message}); return false; } catch (IOException ex) { Console.WriteLine($[SMTP读写出错] {host} - {ex.Message}); return false; } }这里有几个容易踩的细节。fromAddress必须是一个真实存在的发件地址很多服务器会校验发件人域名随便写的testtest.com会直接被拒导致后续所有验证都返回失败。我用的是一个专用的验证邮箱域名是自己的避免被反垃圾策略拦截。服务器的多行响应也要注意。EHLO通常会返回多行以250-PIPELINING等多行开头、最后一行250 HELP结束。上面代码只读了一行在大多数服务器上够用但遇到严格实现时会漏读后续行导致MAIL FROM的响应错位。改进方式是读到一个空行或一行没有-前缀的250为止。最后一个坑不要对验证结果做非黑即白的判断。部分服务器出于反垃圾考虑对所有RCPT TO都返回250不告诉你真实结果。所以我会把结果分成三档有效返回 250/251、无效返回 550/551/552、不确定连接失败、超时、被静默丢弃。导出时不确定单独一列不直接丢弃也不直接采用。5. 邮箱获取器常见问题与排查四类典型翻车现场5.1 抓下来的 HTML 全是乱码正则匹配不到任何邮箱现象打开程序日志发现大部分页面抓取成功但提取结果为空手动把 HTML 保存下来看中文全是乱码英文正常。原因服务器返回的 Content-Type 里没声明charsetHTML 的meta标签里可能是gb2312或gbk而代码默认用 UTF-8 解码字节序列被错误转换。解决不要盲信 HTTP 响应头也不要把命运押在默认 UTF-8 上。应先检查响应头的Content-Type再检查 HTML 里meta charset...或meta http-equivContent-Type contenttext/html; charset...最后才轮到默认编码。private static string DecodeHtml(byte[] bytes, HttpResponseMessage resp) { string charset ; if (resp.Content.Headers.ContentType?.CharSet ! null) { charset resp.Content.Headers.ContentType.CharSet; } if (string.IsNullOrEmpty(charset)) { string head Encoding.ASCII.GetString(bytes, 0, Math.Min(bytes.Length, 1024)); var metaMatch Regex.Match(head, charset\s*\s*[]?([a-zA-Z0-9-_]), RegexOptions.IgnoreCase); if (metaMatch.Success) charset metaMatch.Value; } try { Encoding encoding string.IsNullOrEmpty(charset) ? Encoding.UTF8 : Encoding.GetEncoding(charset); return encoding.GetString(bytes); } catch (ArgumentException) { return Encoding.UTF8.GetString(bytes); } }解码和 HTML 解析的时机也要注意必须先拿到正确解码后的字符串再交给 HtmlAgilityPack 解析如果在乱码字符串上解析标签名都会错乱。5.2 抓了二三十个页面后全部请求返回 403现象本地测试一切正常批量跑了几十个请求后某个站点突然开始全部拒绝访问其他站点正常。程序日志里出现403 Forbidden。原因目标站点的防火墙或反爬策略检测到同一 IP 在短时间内的高频请求触发了限流。解决两个层面的手段配合。代码层面给每次请求之间加随机延迟同时维护一个旋转的 User-Agent 列表。运营层面控制单站的抓取频率每秒钟最多 1 到 2 个请求且只抓公开的、允许访问的页面。private static readonly string[] UserAgents new[] { Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 Chrome/120.0 Safari/537.36, Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:120.0) Gecko/20100101 Firefox/120.0, Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/605.1.15 Version/17.0 Safari/605.1.15 }; public static string GetRandomUserAgent() { return UserAgents[Random.Shared.Next(UserAgents.Length)]; }加延迟的常见做法是await Task.Delay(Random.Shared.Next(1500, 4000))这个范围适用于中小规模采集。延迟过短形同虚设过长则整体效率太低。另外记得给 Http 请求统一加超时和重试机制重试时用指数退避第一次等 3 秒第二次等 9 秒第三次等 27 秒超过三次直接放弃。5.3 验证结果大量出现“无效”但邮箱手工发信能收到现象SMTP 验证模块返回大量550但拿这些邮箱去邮件客户端手工发信却能正常送达。原因最常见的一是发送的fromAddress域名信誉差被目标服务器直接拒收二是目标服务器做了反向 DNS 校验你的出口 IP 没有配置 PTR 记录三是部分服务器对来自陌生 IP 的连接直接执行策略性拒收即使邮箱存在。解决先换一个信誉好的发件地址确认fromAddress的域名确实存在且有 MX 记录。然后检查自己的出口 IP 是否有干净的邮件发送历史。如果你跑在普通宽带或云主机上25 端口的管理策略会差别很大这是玄学最多的地方。另外一个更务实的解决思路是不要把 SMTP 验证结果作为唯一标准。MX 记录存在且格式合法的邮箱标记为待确认SMTP 返回明确的250才标为有效返回550的标为待定而不是直接删掉。这样既减少误杀也能保证最终使用的列表里大部分邮箱是真实存在的。5.4 程序界面卡死点一下按钮等半天没响应现象WinForms 或 WPF 界面上点击“开始获取”按钮后窗口失去响应日志显示网络请求已经完成但界面就是刷不出来。原因在 UI 线程里同步执行了网络操作。HttpClient.GetAsync(...).Result或者.Wait()会阻塞 UI 线程的消息循环底层网络回调又尝试回到 UI 线程继续执行形成典型的异步死锁。解决整个调用链全部使用async/await按钮事件改成async void确保没有任何一处用.Result或.Wait()获取结果。private async void btnStart_Click(object sender, EventArgs e) { btnStart.Enabled false; try { var fetcher new WebFetcher(); string? html await fetcher.FetchAsync(txtUrl.Text.Trim()); // 后续处理也继续 await不要 .Result listBoxEmails.Items.Clear(); foreach (string email in ExtractEmailsFromHtml(html ?? )) listBoxEmails.Items.Add(email); } catch (Exception ex) { MessageBox.Show($发生错误: {ex.Message}); } finally { btnStart.Enabled true; } }如果是从控制台项目迁移过来的代码最容易带过来的坏习惯就是在Main方法里用.GetAwaiter().GetResult()。控制台没有 UI 同步上下文死锁不明显迁移到界面后就暴露出来了。排查时全局搜索.Result、.Wait()和.GetAwaiter().GetResult()一个都别留。6. 让获取器更耐用的三个进阶习惯抓取量从几十个页面涨到几百个之后单线程串行就不够用了。我一般用SemaphoreSlim控制并发数避免同时发出太多请求导致被限流。下面是一个简单的并发包装思路private static readonly SemaphoreSlim Gate new SemaphoreSlim(4); public static async Taskstring? FetchWithThrottleAsync(WebFetcher fetcher, string url) { await Gate.WaitAsync(); try { return await fetcher.FetchAsync(url); } finally { Gate.Release(); } }并发数设成 4 是血泪经验换来的。单线程太慢8 个并发会让大多数小站点的日志里出现大量 403。4 个并发配合 2 到 3 秒的延迟是相对安全的起步值。如果跑的是自己维护的站点可以放宽到 8。第二个习惯是结果落盘要带断点续跑。导出的 CSV 里加上采集时间、来源地址、验证状态三列程序重启后能跳过已经处理过的 URL避免重复抓取。简单做法是维护一个HashSetstring记录已处理的 URL每处理完一个就追加写入本地文件。第三个习惯是分类输出不要只给一个“全部邮箱”的 CSV。我最后导出的文件是四个verified.csv只放 SMTP 验证通过的地址pending.csv放格式合法但验证不确定的地址invalid.csv放明确无效的地址report.csv放每个 URL 的抓取状态和提取数量。四份文件配合使用才能既保证线索质量又保留回旋余地。这个方案值不值得自己做如果你只需要一次性处理几十个页面手动复制粘贴可能更快但只要是持续性的收集需求、或者数据量超过 500 个邮箱这套源码骨架能帮你省下至少一个完整工作日。把上面几个模块组装起来改改输出路径和并发数就是一套够用很久的工具。希望帮到你。本文还有配套的精品资源点击获取