企业官网建设流程全解析

• 网络安全
• 应用安全
• 后端

导读：本文以 Cap（免费、开源、自托管的 reCAPTCHA 替代品）为对象，系统拆解移动端表单场景下的 CAPTCHA 设计问题——为什么图片谜题在手机上伤害最大、移动端友好防护需要满足哪些硬性要求，以及 Cap 如何用"复选框 + Proof-of-Work + Instrumentation"这套确定性机制实现单次点击完成验证。读完你可以直接照搬表单嵌入、事件监听、难度调节与原生 App API 保护的完整落地路径。

为什么 CAPTCHA 在移动端伤害最大

移动端是 CAPTCHA 造成转化损失最严重的场景，原因有五点，官方指南将其归结为：

• 图片网格在小屏上不可用。"选出所有红绿灯"在 6 英寸屏幕上意味着眯眼、缩放和误触，桌面端只是烦人的重试循环，在移动端直接激怒用户。
• 打断键盘与自动填充。Challenge 在表单中途弹出会收起键盘、中断 Autofill 流程，用户丢失输入位置。
• "隐形"系统的信号更弱。指纹与行为分析依赖鼠标移动和稳定的网络身份，移动端没有鼠标、存在大量运营商级 NAT（同一 IP 背后可能上千用户），且 Safari 的跟踪防护激进。信号少意味着误判多，误判最终变成谜题或封禁。
• Webview 流量占比巨大。Instagram、TikTok、Gmail 等应用内浏览器承载大量移动流量，它们对指纹系统而言"看起来可疑"。
• 带宽与电量的真实成本。超过 500 KB 的 CAPTCHA 脚本在蜂窝网络下的中端手机上，是用户尚未输入任何内容就要付出的代价。

这五点构成了移动端防护设计的起点：任何依赖"分类器打分"或"图片交互"的方案，在移动端都有结构性缺陷。

移动端友好防护的 5 项硬性要求

要在移动端成立，机器人防护必须同时满足：

1. 任何回退条件下都不出现视觉谜题。只要系统"有能力"下发图片网格，移动用户迟早会遇上一次——所以必须从机制上杜绝。
2. 人类通行是确定性的。不依赖会因 NAT 运营商 IP 或 Webview 而降分的风险评分。
3. 体积小。防护的成本不应超过表单本身。
4. 触控优先的 UX。最多一次点击、清晰的进度反馈、不打断键盘。
5. 成本可调。解算时长应是运维方手中的旋钮，而不是让低端设备干等。

Cap 的移动端模型：机制设计优于分类器判断

Cap 的答案是把"低摩擦"内建进机制本身：一个复选框，一次点击，背后是浏览器中静默运行的工作量证明（Proof-of-Work）。它不是靠分类器的裁定来放行人类，因此不存在"移动端信号弱导致误判"这一失败模式。

一次点击，然后是进度百分比

用户点击复选框后，Proof-of-Work 在浏览器后台运行，一个进度百分比随之填充。没有图片、没有打字、没有键盘收起。在 浮动模式 或 程序化模式 下，提交之前界面完全不可见。

进度反馈在 widget 源码 中有明确的实现路径：解算过程通过dispatchEvent("progress", { progress })派发进度事件，前端以约 150 ms 的间隔刷新可视百分比（见 cap.js 第 1065 行）；解算由WorkerPool调度，worker 数量默认取navigator.hardwareConcurrency || 8，并可通过data-cap-worker-count属性覆盖（上限 16，见 cap.js 第 495 行 与 cap.js 第 1587 行）。进度条的存在不只是视觉反馈，它把"等待算力"转化为可感知的确定性，避免用户误以为页面卡死。

一个容易被忽略的移动端优化是"预解"：widget 在用户首次交互（mousemove/touchstart/keydown）后约 2.5 秒即开始预取并后台解算 Challenge（SPECULATIVE_DELAY_MS = 2500，见 cap.js 第 326 行），用户真正点击复选框时往往直接命中已完成的 token。这解释了为什么在移动端反复刷新表单时，第二次验证的等待几乎为零。

约 20 KB 的单一 Web Component，无框架依赖

Cap 的 widget 是一个独立的 Web Component，不依赖任何前端框架，体积约 20 KB，在蜂窝网络下加载成本极低。官方 benchmark 页面 给出了各档设备上的实测解算耗时（difficulty 4、50 个挑战、WASM 0.0.7）：

注意：这些数据使用占位服务器测得，实际耗时会随部署与网络延迟变化，但量级关系说明移动端的解算差异主要由设备算力而非网络决定。

无指纹惩罚

Cap 不关心访客是否位于运营商 NAT 之后、是否身处 Instagram Webview、是否开启了 iOS Safari 的跟踪防护——Proof-of-Work 对所有人是同一道计算题。这与 reCAPTCHA v3、Turnstile 这类指纹驱动方案形成根本区别：后者在移动端信号稀薄的环境中更容易误判，且误判后用户没有任何申诉渠道。

难度属于你：按站点密钥调节

解算成本是运维方可控的旋钮。在 Standalone 服务器 上，每个站点密钥都可以独立配置HashWX difficulty（客户端需计算的目标哈希数）：默认1_000_000，拆分为 4 个子挑战，合法范围50_000–5_000_000（见 options.md）。文档给出的参照是：8 核桌面 Chrome 上默认难度中位耗时 578 ms，手机上约 1.1–5.9 s。因此建议消费者结账流量用低难度，易被滥用的注册端点用高难度——这是"成本可调"要求在部署层的直接落地。

HashWX 文档 还给出了真实手机上的完整测量（BrowserStack 实测，每次均从全新加载的页面开始，含两轮到测试服务器的往返，往返中位 80–190 ms/设备）：

预算级 Android（Vivo Y21）比 M3 桌面慢约 10 倍。如果主要流量来自移动端，就应调低难度——解算时间与难度线性相关，500_000大致可以把上表所有解算部分减半。另一个实测结论是：页面已运行 HashWX 一分钟后，Pixel 6 单次解算耗时降低 24%、Vivo 降低 29%，所以"预热后跑分"会好看得多；生产环境应保持冷启动视角。

触觉反馈与无障碍细节

移动端体验的完成度体现在细节上：widget 支持成功后震动反馈（navigator.vibrate([10, 50, 20, 30, 40])），但会尊重prefers-reduced-motion: reduce并可通过CAP_DISABLE_HAPTICS或data-cap-disable-haptics关闭（见 cap.js 第 3 行与第 841 行）。触发按钮带role="button"、tabindex与aria-live属性，支持键盘回车与空格触发。这些设计让"一次点击"不仅对普通用户成立，对依赖无障碍辅助的用户也可用。

Instrumentation 依旧生效

Proof-of-Work 证明的是"付出过算力"，不证明"来自真实浏览器"。因此 Instrumentation Challenges 作为第二层叠加存在：服务器每次下发一段唯一的 JavaScript，在沙箱 iframe 中执行真实 DOM 操作与计算链，服务端并行跟踪预期结果并核对，从而捕获纯 PoW 挡不住的无头自动化——同时不涉及对人类用户的画像。在 cap.js 源码 中可以看到其客户端执行路径：对压缩的 instr 字节做 base64 解码与 inflate，注入 1px 大小的沙箱 iframe，通过postMessage回收结果。

一个诚实的权衡必须说明：PoW 消耗 CPU 时间，低端手机解算慢于桌面。Cap 的缓解手段正是上文的可配置难度 + 可见进度反馈，且工作量按"每表单一次"计，而非"每页浏览一次"。

移动端方案横向对比

结论是：移动端场景下，确定性机制（PoW）相比分类器机制（评分/指纹/行为）少了一个"信号不足导致误判"的失败维度。

实施要点：从 HTML 表单到原生 App API

表单内自动注入cap-token

把<cap-widget>放进<form>内，Cap 会自动注入隐藏的cap-token字段并随表单提交，无需任何 JavaScript。该行为在源码中可见：cap.js 第 969 行 于组件挂载时写入<input type="hidden" name="cap-token">，字段名可通过data-cap-hidden-field-name自定义（默认cap-token，见 cap.js 第 804 行）。完整接入流程（服务器启动、密钥创建、token 校验）见 快速开始。

<form action="/submit" method="POST"> <!-- 你的表单字段 --> <cap-widget>const widget = document.querySelector("cap-widget"); widget.addEventListener("solve", (e) => { const token = e.detail.token; // 发送 token 到你的服务器、启用提交按钮等 });

需要完全掌控流程时用 程序化模式：new Cap({ apiEndpoint })创建实例并调用cap.solve()获取{ token }，还可监听progress事件展示自定义进度条。

在真实中端 Android + 蜂窝网络上测试

官方指南明确建议：用真实的中端 Android 在蜂窝网络下测试，而不是旗舰机连 Wi-Fi；根据目标受众把难度调到"感觉上是即时的"。对照上文手机测量表，默认1_000_000难度在低端设备上约 2–6 s，若你的受众大量使用这类设备，应下调难度。

保护原生 App 的 API

如果你保护的是原生 App 的 API 而非 Web 表单：Cap 的 Standalone 服务器 可以对任何能在 Webview 中执行 Challenge 的客户端验证 token——App 内嵌 Webview 运行 Challenge，拿到 token 后随 API 请求提交，服务端调用/siteverify校验。验证接口与 reCAPTCHA 的 siteverify API 兼容，迁移时只需改一个 URL。

常见问题

移动端表单最适合用哪种 CAPTCHA？一种永远不会显示谜题、永远不会误分类的方案。Cap 的"复选框 + PoW"模型是确定性的、约 20 KB、且为触控而设计。

如何阻止移动端表单的垃圾提交？用成本而非提问。PoW 让每一次提交对规模化 bot 而言都算力昂贵，对人类仍只是一次点击。

移动端隐形 CAPTCHA 更好吗？只有当它的误判率站得住时才是——而移动端恰恰是指纹与行为信号最弱的场景。确定性机制不存在这种失败模式。

Cap 在移动端能用吗？可以：移动 Safari、Chrome、Firefox 与应用内 Webview 均支持；难度可调，让慢设备上的解算时间保持短暂。注意 iOS 上需 iOS 15 或更新，且无 WebAssembly 的客户端无法解 HashWX（此类客户端应切换到带纯 JS 回退的 SHA-256 PoW）。

哪种 CAPTCHA 的用户摩擦最小？无谜题选项包括 Cap、Turnstile、FriendlyCaptcha、ALTCHA、SilentShield。Cap 是其中开源、自托管的一个，其低摩擦来自机制设计而非分类器裁定。

延伸阅读

• CAPTCHA 与转化率：桌面与移动端的漏斗计算
• 2026 年最佳 CAPTCHA 替代方案：全景对比
• 有效性分析：为什么"成本"优于"分类"
• HashWX 工作量证明：GPU 抗性协议的完整原理与测量
• Standalone 配置选项：难度、CORS、限流、健康检查
• 实时演示：在手机上亲自体验

• 网络安全
• 应用安全
• 后端