html本身不提供验证码能力，真正起作用的是后端生成逻辑+客户端行为采集+风控模型判断；前端仅需配合提供data-form-id、预留容器、绑定js提交。
HTML 本身不提供验证码能力，所谓“HTML 验证码”只是前端渲染载体；真正起作用的是后端生成的验证逻辑 + 客户端行为采集 + 风控模型判断。直接在 HTML 里写 <input type="text" name="captcha"> 没有意义，机器照样填、照样发。
为什么单纯靠 HTML 表单字段防不住机器人
机器人解析 HTML 的能力远超预期：它们能识别 name="captcha"、id="verify-code"、甚至带 “code” “check” “vali” 字样的任意字段。只要字段可提交，就会被自动填充。蜜罐字段（如 <input name="honey" style="display:none">）对基础爬虫有效，但对带 DOM 解析能力的工具（如 Puppeteer、Playwright 脚本）基本失效——它们会跳过 display: none，却仍能读取 name 并忽略该字段，或干脆绕过整个表单，直接 POST 构造请求。
常见错误现象：
- 用户没看到验证码，但后端日志显示大量
captcha=1234的无效提交 - 加了
required属性，但机器人 POST 时根本不传该字段，后端未校验就放行 - 前端用 JS 动态插入验证码图片，但机器人用
fetch()直接请求图片 URL + OCR 接口识别后回填
人机识别真正依赖的三个技术层
一个可用的验证码流程，必须同时覆盖以下三层，缺一不可：
-
服务端生成与校验：验证码 token（如
captcha_id）和对应答案必须由后端生成并存储（如 Redis），且仅一次有效；前端只传递 token，不暴露明文答案 - 客户端行为采集：不是只看“有没有填”，而是采集鼠标轨迹、点击时间、滑动速度、焦点切换顺序等——例如滑块验证码中，人类拖动有加速度变化，机器直线匀速拖动会被打低分
-
设备与环境指纹：包括
navigator.plugins、screen.availHeight、WebGL 渲染特征、Canvas 指纹、TLS 指纹等；单一维度可伪造，但多维组合后，模拟成本指数级上升
Google Invisible reCAPTCHA v3 就是典型：它不展示任何 UI，只返回一个 score（0.1–0.9），这个 score 是后端调用 https://www.google.com/recaptcha/api/siteverify 时，由 Google 后台融合上述三类数据计算得出。
你在 HTML 里唯一该做的三件事
别试图用 HTML 标签“实现”验证，只做最小必要配合：
- 给表单添加唯一
data-form-id属性，便于前端 SDK 关联行为数据（如<form data-form-id="login"></form>） - 预留容器供 JS 注入验证组件，比如
<div id="captcha-container"></div>，而不是硬编码<img src="/captcha?r=123"> - 提交按钮绑定
onclick="return verifyBeforeSubmit()"，并在该函数里阻断原生提交，改用 fetch + token + 行为数据打包发送
示例关键片段：
注意：type="button" 防止回车默认提交；submitWithCaptcha() 内部应调用 SDK 的 execute() 方法获取 token，再拼到 payload 中发往后端。
最容易被忽略的一点：验证码 token 的有效期必须严格控制（建议 ≤ 2 分钟），且每次刷新页面/重试都应废弃旧 token。否则攻击者截获一次 token，就能无限重放——这比没有验证码还危险。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
