把邮箱藏起来，垃圾邮件就找不到你了吗？2026 年最实用的反爬虫实验
公开一个邮箱，为什么到 2026 年还是件危险的事
如果你做过个人网站、独立博客，或者给公司官网写过“联系我们”，大概率都经历过同一种挫败：邮箱刚挂上去没多久，垃圾邮件、营销轰炸、钓鱼信息就像闻到血腥味的鲨鱼一样游过来了。这个问题并不新鲜，甚至可以说是 Web 时代的“祖传烦恼”。
最近，开发者 Spencer Mortensen 做了一项很有意思、也很“接地气”的实验：他系统测试了多种邮箱混淆方案，看看到了 2026 年，哪些方法还能挡住垃圾邮件爬虫，哪些已经形同虚设。结果有点反直觉——并不是越复杂、越“密码学”、越像黑科技的方法就越有价值。很多效果最好的手段，恰恰是那些简单、朴素、但专门卡在爬虫短板上的设计。
这件事之所以重要，是因为它提醒了我们一个常被忽略的现实：互联网上最凶猛的攻击，不一定来自最先进的 AI，也可能只是几十万只粗糙但高效的小爬虫。对付它们，未必要上火箭，很多时候一把合适的扳手就够了。
真正有效的，不一定是最“高级”的
Mortensen 把邮箱保护分成两类：一种是直接展示纯文本邮箱，比如 name@example.com；另一种是隐藏在可点击的 mailto: 链接里。测试结果里最醒目的结论是：完全不做保护，拦截率自然是 0%；但只要稍微动一点手脚，效果就会突然拉开。
比如很多前端开发者已经不太看得上的 HTML 实体编码，居然还能挡住大多数爬虫。纯文本邮箱用 HTML entities 处理后，拦截率达到 95%；把邮箱拆进 HTML 注释里，甚至能达到 98%。这说明一个朴素事实：今天互联网上仍然有大量“低配”采集器，它们甚至连完整解析页面都做不到，只会傻乎乎地扫源代码里的模式字符串。
更有意思的是，一些被作者评为“顶级方案”的方法，并不靠晦涩，而是靠让爬虫“懒得做”。例如把真实邮箱夹在可见文本与 display:none 的诱饵文本之间，测试里拦截率是 100%。原因也很直白：大量爬虫不会真正应用 CSS 规则，自然分不清哪些字该读、哪些字不该读。再比如使用 JavaScript 在浏览器端把乱码转换成邮箱，或者通过用户交互后才揭示邮箱，这些方法都拿到了 100% 的拦截率。
这让我想到安全行业里那句老话：安全不是把门做成迷宫，而是让闯进来的人觉得不划算。邮箱混淆也一样。你不需要让对手“永远破解不了”，只要让大多数批量化爬虫觉得麻烦，它们就会转头去抓那些毫无遮挡的网站。
最尴尬的失败，不是被破解，而是把用户也一起拦在门外
这篇测试最有价值的地方，不只在于统计“拦住了多少爬虫”，还不断强调另一件更容易被忽略的事：有些方案虽然能挡垃圾邮件，但也会顺手把正常用户体验毁掉。
最典型的是那些互联网上流传多年的“土办法”。把邮箱写成“name AT example DOT com”，理论上能防一些傻爬虫，但用户得自己手动替换，复制也不方便；再极端一点，把邮箱做成图片，爬虫未必能认出来，但用户也没法点、没法复制，使用读屏器的人更是直接被拒之门外。还有 CSS 伪元素、反向文字方向这种技巧，表面上看着聪明，实际上要么能被轻松还原，要么会让用户复制出来一串错误地址。这样的“防护”很像把家门焊死来防小偷——小偷进不去，主人也别想正常出门。
在今天的网页开发环境里，可访问性已经不是锦上添花，而是基本素养。一个邮箱地址如果让视障用户无法读取，或者让普通用户必须手打一遍才能联系你，那它的商业价值、沟通价值都会大打折扣。Mortensen 明确推荐了少数既有效又不伤害可访问性的方案，比如基于 object 加载 SVG、利用 display:none 隐藏诱饵文本、或者用浏览器端 JavaScript 做真实转换。这些方案的共同点是：人类用户看到的是自然的，机器看到的是混乱的。
这也是我很认同的一点。很多反机器人设计，本质上都在考验“人类能不能忍”。验证码就是前车之鉴：它确实拦住了一些机器，却也让无数用户在红绿灯、斑马线和消防栓里怀疑人生。邮箱混淆若走到那一步，就算技术上赢了，产品上也输了。
为什么这些“老办法”今天依然有用
乍一看，这组结果似乎有些不合时宜。都 2026 年了，连生成式 AI 都能写代码、看网页、做自动化操作，为什么邮箱爬虫还会被 HTML 注释、实体编码这种“上古技巧”拦住？
答案其实很现实：垃圾邮件产业是算账的，不是做技术理想主义的。对大规模采集者来说，最重要的指标是成本和吞吐量，而不是对每个页面都像 Chromium 浏览器那样完整渲染、执行 JavaScript、应用 CSS、模拟用户点击。真那么做，服务器成本和采集速度都会显著上升。于是，大量爬虫仍然停留在“抓源码、跑正则、批量扫站”的阶段。它们不是不会升级，而是暂时没必要。
这也是为什么文中有些结果看起来很“魔幻”。比如 JavaScript 字符串拼接被测出 100% 拦截率，但作者自己也提醒，这并不意味着它绝对安全，因为完整邮箱其实还出现在 HTML 源码里，只是被拆成了多个片段。如果有人愿意稍微写得聪明一点，照样能拼回来。换句话说，测试结果反映的是当下垃圾邮件生态的平均水平，而不是技术上不可破解的上限。
从行业视角看，这和反爬虫、反机器人、反欺诈是同一种博弈。电商平台防黄牛、社交平台防批量注册、媒体网站防内容采集，大家面对的都不是“最强攻击者”，而是“最划算的攻击者”。谁能把对方的边际成本抬高一点，谁就能暂时赢一回合。
给开发者的启发：别迷信加密，也别低估组合拳
Mortensen 还提到一个很实用的建议：不要把整个邮箱押注在单一手段上，而是把邮箱拆成几个片段，用不同方法分别保护。这其实是非常工程化的思路。比如用户名部分用 JavaScript 转换，域名部分掺入 display:none 的诱饵，再把整体展示交给 SVG 或可点击链接。这样做的意义在于，即便某种方法被破解，也不至于“一锅端”。
文中还测试了 AES 加密方案，理论上当然更“硬核”。它用浏览器内置的 SubtleCrypto 来解密邮箱，离开安全上下文、离开 HTTPS、离开支持完整 Web API 的环境就很难工作。从安全想象上说，这很迷人，甚至有点像给邮箱上了保险柜。但问题也随之而来：维护成本更高、部署要求更苛刻、调试更复杂，而且对一个联系邮箱来说，未必值得把系统搞到这么重。
这正是这篇文章最值得玩味的地方：它反复告诉我们，技术方案不能只看“能不能做”，还要看“值不值得做”。在大多数网站场景里，一个简单的 CSS 隐藏诱饵、一个浏览器端转换函数，可能就已经足够实用。真要上 AES，更多是展示技术雄心，而不是最优产品决策。
我自己的判断是，未来邮箱混淆会越来越像一套“轻量级风控”：不追求绝对防御，而追求低摩擦、高容错、可渐进升级。尤其在 AI 自动化能力不断提升之后，单一技巧的寿命会缩短，但多层组合、兼顾可访问性的策略反而会更稳。
说到底，公开邮箱这件事不会消失。独立开发者需要联系渠道，记者需要爆料入口，创业公司需要商务线索，教授和研究者也需要开放通信。问题不是“要不要公开”，而是“如何公开得不那么脆弱”。在这个意义上，邮箱混淆不是一个老掉牙的小技巧，而是开放互联网如何自我保护的一块微型样本。
如果说还有什么更大的问题值得追问，那就是：当 AI 代理越来越擅长像人一样浏览网页、点击按钮、理解上下文时，今天这些 100% 有效的方法还能撑多久？也许答案不会太乐观。但至少在 2026 年，现实世界仍然给了普通网站管理员一个好消息——你不必打赢未来，只要先挡住眼前那群最吵的机器，就已经很有意义了。