什么是蜜罐字段：人看不见的 Bot 陷阱

更新：2026-09-13 · 阅读约 3 分钟

Bot 填表时“不看”表单

人在 Web 表单里输入时，会看着画面，认出输入栏，输入合适的内容。但是，Bot 并不“看”表单。Bot 会解析 HTML 的源代码，机械地检测出 input 元素和 textarea 元素，再用程序填入值。

这种“不看”的特性，就是蜜罐字段的原理。设置一个人看不见、但在 HTML 里存在的假输入栏。人看不见这个输入栏，所以什么也不会填。但是，Bot 是解析 HTML 来检测输入栏的，所以也会往假输入栏里填入值。

在服务器端，把假输入栏里有值的发帖判定为 Bot 并拒绝。人的发帖中，假输入栏通常是空的，所以正当的发帖几乎不会被误拒。

让蜜罐字段处于“人看不见、但在 HTML 里存在”的状态，有几种方法。

最常见的是用 CSS 隐藏的方法。对包含输入栏的元素，应用放到画面外（position: absolute; left: -9999px）、把尺寸设为零（width: 0; height: 0; overflow: hidden）、在视觉上隐藏（opacity: 0）等样式。

字段名的设计也很重要。Bot 会检测“email”“name”“message”这类常见的字段名并自动填写。给蜜罐字段起这些名字，Bot 自动填写的概率就会提高。反过来，给真正的输入栏起 Bot 难以猜到的名字。

需要注意的是，如果使用 display: none，一部分高级的 Bot 带有“不往隐藏的元素里填写”的逻辑，所以有可能躲过检测。放到画面外或把尺寸设为零的方法，往往更不容易被 Bot 察觉。

也需要考虑无障碍。如果屏幕阅读器把蜜罐字段读出来，视障用户会感到困惑。设置 aria-hidden="true" 属性和 tabindex="-1"，把蜜罐字段同时从屏幕阅读器和键盘导航中排除。

蜜罐字段最大的长处，是对用户体验的影响为零。不需要像 CAPTCHA 那样让人选图片，也不需要像 Proof of Work 那样跑计算。用户甚至不会察觉到蜜罐字段的存在。

另一个长处是实现简单。只需要在 HTML 里加一个假输入栏，用 CSS 隐藏，再在服务器端检查假输入栏的值。不依赖复杂的算法或外部服务，运行轻量。

但是，它也有局限。高级的 Bot 能解析 CSS 的隐藏样式，识别出蜜罐字段，从而避开填写。使用无头浏览器（Puppeteer、Playwright 等）的 Bot，会像真正的浏览器一样渲染页面，所以能识别出隐藏的元素，跳过填写。

另外，蜜罐对人手动进行的骚扰没有效果。人是从视觉上认出表单再输入的，所以不会掉进蜜罐字段。

蜜罐字段单独使用，防不住高级的 Bot。但是，作为多层防御中的一层，和其他措施组合起来，就能发挥效果。

在提问箱这样的服务里，叠加蜜罐字段、Proof of Work 和速率限制的多层结构是常规做法。

蜜罐作为最轻量的防御层，最先筛掉简单的 Bot。机械解析 HTML、往所有字段里填值的那类 Bot，会在这一层被排除。网上的 Bot 很多都是这种程度的简单货色，仅靠蜜罐就能排除相当数量的 Bot。

突破了蜜罐的 Bot，会遇到下一层的 Proof of Work。每次发帖都需要解开计算谜题，大量发帖的成本会急剧上升。而且，即使突破了 Proof of Work，发帖频率本身也会受到速率限制的约束。

3 层各自按不同的原理运作，所以突破 1 层的技术不一定对其他层也管用。能避开蜜罐的 Bot 不一定也能避开 Proof of Work，能快速解开 Proof of Work 的 Bot 也不一定能避开速率限制。这种“不同原理的组合”，就是多层防御的本质。

“蜜罐（Honeypot）”这个名字，来自网络安全的术语。在安全领域，蜜罐指的是“故意引诱攻击者的诱饵系统”。设置一台伪装成真服务器的假服务器，攻击者一旦入侵，就能观察和记录攻击的手法和目的。这个名字比喻的是用蜂蜜引诱虫子的罐子。

表单的蜜罐字段也是同样的思路。设置一个引诱 Bot 的诱饵输入栏，Bot 一往里面填写就会被检测出来。让攻击者落入陷阱这一基本思路，和网络安全中的蜜罐是相通的。

蜜罐的概念，在 1990 年代末到 2000 年代初，由安全研究者兰斯·斯皮茨纳（Lance Spitzner）等人加以体系化。最初用于检测网络入侵，后来也被应用到 Web 表单的垃圾信息对策上。原理简单，却在 30 年以上的时间里一直被作为实用的防御手段使用，是一项生命力很长的技术。