介绍

今天，我们将讨论一个已经成为每个反检测浏览器用户工作流程中不可或缺的功能。

粘贴像人类打字（也称为类人输入，简称HLI）是对剪贴板文本输入的模拟，模仿真实用户的行为。

这是一个不可或缺的工具，节省大量时间并消除在多账户工作中的日常操作。其主要目标是在网站表单中输入文本时，最大限度地减少反欺诈系统的限制风险。

每个产品对这个功能的称呼不同：

• 人类打字模拟
• 粘贴像人类打字
• 人类打字仿真
• 智能粘贴

Linken Sphere 是第一个实现类人输入并将其推向市场的反检测浏览器，时间是在2017年底。那时，大多数竞争对手并不急于推出类似的功能，声称这在广泛的用户群体中并不受欢迎。然而，实践证明并非如此：几年内，这项技术几乎被所有主要产品采纳，成为行业标准。

输入方式对你成功的影响

在实际操作中，我们常常处理预先准备好的数据，例如：

• 注册账户时的姓名、登录名和电子邮件地址
• 创建广告账户时的支付信息
• 解封广告账户时的申诉文本
• SMM 活动中的评论和消息
• 等等

不是什么秘密，反欺诈系统早就开始跟踪和分析用户行为。文本输入到表单中也不例外。在绝大多数情况下，输入方式确实很重要。

如果你只是使用熟悉的Ctrl+V / Cmd+V组合粘贴文本，系统可能会觉得它比手动输入更可疑。结果，你的账户和操作可能会受到更多的审查。

另一方面，手动打字虽然看起来最自然，但在处理大量账户时几乎不现实。首先，它会让人感到精疲力尽。其次，你独特的打字模式可以用来将会话关联在一起。是的，通过打字风格关联账户并不是偏执——这是我们生活的现实。稍后我们会展示一种方法来直观测试这种检测。

因此，最佳的解决方案仍然是像人类打字那样粘贴，它旨在消除上述所有问题。HLI 是灵丹妙药吗？这取决于具体的技术实现。正因为如此，我们对市场上最流行的反检测浏览器进行了自己的研究。

在深入了解结果之前，让我们回顾一下几个关键的技术方面，帮助更好地理解浏览器中输入机制的工作原理。

有哪些类型的键盘事件？它们什么时候使用？

有三种主要的键盘事件：keydown、keypress和keyup。在现代浏览器（包括Chrome）中，keydown和keyup是相关的，而keypress被认为是过时的（尽管在输入过程中仍然会触发）。

• keydown - 当按下某个键时触发，并对任何按键（包括Alt、Shift等控制键）有效。它用于立即响应按键（例如，用于快捷键或游戏）。如果按键被按住（例如，t），它会触发自动重复：在初次按下时触发一次keydown事件，然后在按键被松开之前重复触发keydown事件（event.repeat = true）。
• keypress - （已废弃）当按下生成字符的键时触发。历史上用于检测可打印字符的输入（字母、数字等），而keydown/keyup用于跟踪物理按键。它不会为不生成字符的键（如Shift或箭头键）触发，现在被认为是过时的。改为使用keydown事件的event.key属性或使用专门的输入事件（见下文）。
• keyup - 当按下的键被释放时触发。用于在用户释放按键后处理操作，例如，一旦输入完成一个字符或检测到按键不再被按住时执行操作。

已废弃的键盘属性：什么是charCode、keyCode和which，为什么应该避免使用它们？

charCode、keyCode和which是旧版本DOM中键盘事件对象的属性（遗留）。它们表示按下的键或字符的代码，但现在已经过时，不推荐使用。现代标准使用event.key和event.code属性。

以下是每个遗留属性的简要描述及其为何被淘汰：

属性 描述（遗留） 状态及替代 \ event.keyCode\t数字键码（通常与字符的ASCII码匹配，不考虑修饰键）。用于keydown/keyup事件。\t已废弃 – 过时。在不同浏览器和键盘布局之间变化，特别是对于有Shift/Alt修饰符的可打印字符。应使用event.key或event.code替代。 \ event.charCode\t字符的数字Unicode码，仅在keypress事件中生成（对于生成文本的键）。\t已废弃 – 过时。曾用于在keypress中获取字符，现在已被event.key替代，直接获取输入的字符。 \ event.which\t统一的属性，返回根据事件类型返回键或字符的代码：本质上重复了keydown/keyup事件的keyCode和keypress事件的charCode，也用于鼠标按钮。\t已废弃 – 过时。没有标准化（不同浏览器可能返回不同值）。对于键盘输入，使用event.key和event.code替代（对于鼠标，使用event.button）。

修饰键（Shift、Ctrl、Alt、Meta）：getModifierState() 和相关属性是如何工作的？

键盘事件包括指示修饰键状态的属性，以及检查它们的一个方法。

• 属性 event.shiftKey、event.ctrlKey、event.altKey 和 event.metaKey 如果对应的修饰键在事件生成时被按下，则为 true。例如，使用 Ctrl+X 组合键时，"X" 键的 keydown 事件将有 ctrlKey = true。metaKey 属性对应 Meta 键（在 Windows 上是 ⊞ Windows 键，在 Mac 上是 ⌘ Command）。这些布尔属性允许你检测 Shift、Ctrl、Alt 或 Meta 是否与其他键一起按下。
• 方法 event.getModifierState(key) 返回 true 或 false，取决于事件发生时指定的修饰键是否处于活动状态。key 参数是一个字符串，表示修饰键的名称，例如 "Shift"、"Control"、"Alt"、"Meta"，或锁定键如 "CapsLock" 和 "NumLock"。如果修饰键当前被按下或启用（例如，如果 CapsLock 已开启），该方法将返回 true。这允许检查像 CapsLock 这样的键的状态，它们不会直接反映在独立的事件属性中。

UI 事件属性：key、code、location、repeat、isComposing、inputType 和 data 属性意味着什么？

现代的 KeyboardEvent 对象提供了多种关于按键的属性。此外，输入事件会在文本输入过程中生成，提供额外的属性。

以下是主要属性及其含义：

属性 值（表示的内容） key 一个字符串，表示基于布局和修饰符状态的按键值。对于可打印字符，它是实际输入的字符（例如，"a" 或 "A"，取决于 Shift）；对于特殊键，它是预定义的名称（例如，"Enter"、"Escape"）。 code 一个字符串，表示键盘上按键的物理代码。它不依赖于当前的布局；它反映了按下的具体键（根据其位置/扫描码）（例如，按下 "Q" 总是返回 "KeyQ"，无论布局如何）。 location 一个数字，表示键在键盘上的位置。值：0（标准），1（左侧），2（右侧），3（数字键盘）。 repeat 布尔值：如果按键在按下时触发重复事件（键重复），则为 true。初始 keydown 时为 false；随后的重复事件为 true。在 keyup 时，总是为 false。 isComposing 布尔值：如果事件发生在组合会话（IME）期间，例如，在 compositionstart 和 compositionend 之间，则为 true。 inputType （InputEvent 属性）一个字符串，表示对输入字段或可编辑内容所做的更改类型。示例："insertText"、"deleteContentBackward"、"insertFromPaste" 等。 data （InputEvent 属性）一个字符串，表示由于输入事件而插入的文本数据。如果字符被删除，则可能为空；如果与文本数据无关，则为 null。

键盘事件如何与输入字段交互？

当焦点位于输入字段内（如 input 或 textarea）时，按键会生成键盘事件和文本输入事件。

典型的事件顺序如下：

• keydown – 当按下任意键时发生。该事件在聚焦元素（输入字段本身）上触发。在此阶段，浏览器尚未将字符插入字段。你可以在此使用 event.preventDefault() 来取消默认行为，阻止字符的输入。
• beforeinput – 然后（对于生成字符的按键），字段会触发 beforeinput 事件，表示意图更改内容。紧接着，input 事件会触发，表示内容已更新（例如，添加了一个字母）。你可以在这些事件中检查 event.inputType 和 event.data 来确定到底发生了什么（字符输入、文本删除、粘贴等）。注意：在某些旧版情况下，可能会触发 keypress 事件而不是 beforeinput，但在现代 Chrome 浏览器中，使用 beforeinput/input。
• keyup – 最后，当按键被释放时，在同一元素上发生 keyup 事件。

keydown/keyup 键盘事件会从输入元素通过 DOM 树（通过 document 直到 window）冒泡，因此它们可以在输入元素本身、其父元素或全局范围内捕获。如果你需要特定响应文本输入字段中的更改（包括非键盘输入，如剪贴板粘贴或语音输入），最好使用 input 事件，该事件在字段值的任何更改时触发。KeyboardEvent 则适用于处理直接的按键交互——例如，拦截 Escape、箭头键、功能键、组合键等。对于字符输入，最好在你需要阻止或修改输入字符之前使用。

在哪里测试手动输入和像人类打印一样粘贴？

为了获得完整的图景，测试分为几个阶段进行。

Keyboard_Event_Viewer[https://w3c.github.io/uievents/tools/key-event-viewer.html]

此检查器提供关于输入事件的最大信息，包括遗留属性、修饰符和 UI 事件。

1. 手动输入测试

使用反检测浏览器，逐一手动输入测试集中的字符。然后将生成的事件与在同一台 PC 上的真实 Chrome 中手动输入的事件进行比较。

2. 像人类打印一样粘贴测试

使用反检测浏览器，使用像人类打印一样的粘贴功能插入相同的字符。将结果与在同一设备上的真实 Chrome 中的手动输入进行比较。

预期行为：在这两种情况下，输入事件应与在手动输入时真实 Chrome 中生成的事件紧密匹配。

TypingDNA[https://www.typingdna.com/demo-login.html]

此服务专注于通过分析按键间隔来识别打字模式，以检测独特的打字风格并识别用户。

1. 手动输入测试

使用反检测浏览器，通过手动输入唯一数据（电子邮件、密码）创建帐户。然后使用相同的数据多次重复登录过程——也是手动进行。

2. 像人类打印一样粘贴测试

通过使用像人类打印一样的粘贴功能创建帐户。然后多次登录，每次都使用 HLI 进行输入。

使用反检测浏览器，通过使用像人类打印一样的粘贴功能创建帐户。然后多次登录，每次都使用 HLI 进行输入。

预期行为：成功注册和登录，每次重复登录时，注册计数器增加。计数器的增加表示在会话之间检测到稳定且可重复的打字模式。

附加细节

• 测试字符集：tT@。
• 操作系统：Windows 11
• 在所有情况下，通过上下文菜单（右键单击）触发像人类打印一样的粘贴，以避免快捷键干扰

测试结果

Linken Sphere 2 v2.4.0 ⭐

Keyboard Event Viewer

手动输入时的行为完全与常规 Chrome 的行为匹配。

将像人类打印一样的粘贴与真实 Chrome 中的手动输入进行比较时，输入事件在测试字符集内完全匹配。这正是正确实现的 HLI 应该如何工作。

HLI 和 Chrome 中标准输入行为的详细比较如截图所示。

TypingDNA

手动输入正常工作。使用 HLI 时，注册和登录成功，注册计数器增加——表示系统检测到单个会话内稳定且可重复的打字模式。

Octo Browser v2.5.5

Keyboard Event Viewer

手动输入时的行为完全与标准 Chrome 匹配。

HLI 的实现优于大多数其他解决方案，但并非没有缺陷。

将 HLI 行为与真实 Chrome 中的手动输入进行比较时，观察到以下特征：

输入大写字符如 T 和某些特殊字符如 @ 时，使用了 Shift 键，但其状态未反映在修饰符（getModifierState，shift）中

HLI 和 Chrome 中常规输入行为的详细比较如截图所示。

TypingDNA

手动输入正常工作。使用 HLI 时，注册计数器要么不增加，要么出现注册/登录错误。这表明每次都会形成新的打字模式，可能被反欺诈系统负面看待。

Dolphin Anty v2025.152.125.0

Keyboard Event Viewer

手动输入：按下 Shift / Meta / Control 等键（例如输入大写 T 或需要 Shift 的字符如 @）时，注册了额外的 keypress 事件，charCode / keyCode / which 的值为零。

这可能成为反欺诈系统的触发器：即使在手动输入数据时，Dolphin Anty 的行为也偏离标准，这可能导致反检测浏览器被检测到。

Dolphin Anty 中的 HLI 是市场上最差的实现。

将 HLI 行为与真实 Chrome 中的手动输入进行比较时，发现以下问题：

它没有模拟真实打字，而是使用原始的逐字符粘贴。此时，inputType 值为 insertFromPaste，立即揭示它是剪贴板粘贴

即使是通过 HLI 执行的粘贴，也与通过上下文菜单（右键单击）进行的标准粘贴不同，因为没有 beforeinput 事件

是的，从视觉上看，可能一切都与其他产品一样。但详细分析揭示了明显的差异。

HLI 和 Chrome 中常规输入行为的详细比较如截图所示。

TypingDNA

手动输入正常工作。使用 HLI 时，网站根本没有检测到任何输入，这是预期的：它是一个粘贴操作，而不是一个真实的打字模拟。

Undetectable v2.32.1

Keyboard Event Viewer

手动输入时的行为完全与标准 Chrome 匹配。

将 HLI 行为与真实 Chrome 中的手动输入进行比较时，发现以下问题：

在 keydown 和 keyup 事件中，Legacy 的 keyCode 和 which 值总是为 0，这是不可接受的——正确的输入需要有效的键码。

UI Events 中的 code 属性未包含在 keydown、keyup 或 keypress 事件中。

输入大写字母 T 和特殊字符如 @ 时，Shift 键未触发——没有 keydown / keyup 事件，因此没有激活相应的修饰符。

HLI 和 Chrome 中常规输入行为的详细比较如截图所示。

TypingDNA

手动输入正常工作。使用 HLI 时，注册计数器要么不增加，要么出现注册/登录错误。这表明每次都会生成新的打字模式，可能会被反欺诈系统负面看待。

Adspower v6.12.6.0

Keyboard Event Viewer

手动输入时的行为完全与标准 Chrome 匹配。

将 HLI 行为与真实 Chrome 中的手动输入进行比较时，发现以下问题：

• 在 keydown、keyup 和 keypress 事件中，Legacy 属性 charCode、keyCode 和 which 总是为 0，而不是预期的值。
• 在相同的事件中，UI Events 属性 key 和 code 缺失。
• 修饰符（例如 Shift 和 Meta）的行为不自然——无论输入内容如何，都会记录相同的激活模式，尽管在大多数情况下它们不应该触发。
• 在输入 UI 事件中，data 属性始终为 'null'。
• 缺少 beforeinput 事件。相反，input 事件触发了两次，且只有第二次包含 inputType = insertText。
• 事件顺序被打乱：它与自然打字顺序不匹配，无论输入内容如何，始终是错误的。

HLI 和标准输入行为的详细比较如截图所示。

TypingDNA

手动输入正常工作。使用 HLI 时，数据未输入到表单中，且出现错误：'此输入字段不支持粘贴'。

0detect 浏览器（前 AQUM）v3.7.40

Keyboard Event Viewer

手动输入时的行为完全与标准 Chrome 匹配。

将 HLI 行为与真实 Chrome 中的手动输入进行比较时，发现以下问题：

• 在 keydown 和 keyup 事件中，Legacy 属性 charCode、keyCode 和 which 总是为 0，而不是预期的值。
• 在 keydown、keyup 和 keypress 事件中，UI Events 属性 key 和 code 缺失。
• 输入大写字母 T 和特殊字符如 @ 时，Shift 键未触发——keydown / keyup 事件缺失，且修饰符未激活。

HLI 和标准输入行为的详细比较如截图所示。

TypingDNA

手动输入正常工作。使用 HLI 时，数据未输入到某些输入字段中——根本没有反应。然而，在其他字段（例如 Google 搜索栏）中，输入正常工作。

GoLogin v3.3.83.79

Keyboard Event Viewer

手动输入时的行为完全与标准 Chrome 匹配。

将 HLI 行为与真实 Chrome 中的手动输入进行比较时，发现以下问题：

• 在 keydown 和 keyup 事件中，Legacy 属性 charCode、keyCode 和 which 总是为 0，而不是正确的值。
• 在 keydown、keyup 和 keypress 事件中，UI Events 属性 key 和 code 缺失。
• 输入大写字母 T 和特殊字符如 @ 时，Shift 键未触发——keydown / keyup 事件未生成，且修饰符未激活。

HLI 和标准输入行为的详细比较如截图所示。

TypingDNA

手动输入正常工作。使用 HLI 时，注册计数器要么不增加，要么登录/注册时发生错误。这表明每次都会生成新的打字模式，可能被反欺诈系统负面看待。

Vision v3.0.38

Keyboard Event Viewer

手动输入时的行为完全与标准 Chrome 匹配。

HLI 实现与 Dolphin Anty 的解决方案几乎相同，存在类似的缺陷。在目前的状态下，它是测试产品中最差的实现之一。

将 HLI 行为与真实 Chrome 中的手动输入进行比较时，发现以下问题：

• 而不是进行真实的打字模拟，使用了简单的逐字符粘贴。在这种情况下，inputType 值为 insertFromPaste，明确表示是剪贴板粘贴。
• 即使通过 HLI 执行粘贴，仍然与通过标准的右键单击粘贴有所不同，因为没有 beforeinput 事件。

HLI 和标准输入行为的详细比较如截图所示。

TypingDNA

手动输入正常工作。使用 HLI 时，网站根本没有检测到任何输入——这是预期的，因为它是一个粘贴操作，而不是一个真实的打字模拟。

奖金：通过用户独特的打字风格链接账户

我们在介绍中提到过这一点，现在我们将在实践中展示它。下面是一个简单的测试，证明：通过独特的手动打字行为链接账户不仅是可能的，而且被反欺诈系统广泛使用。

它无论在会话、配置文件甚至设备之间都能正常工作。在这种情况下，主要的标识符是你——以及你独特的打字模式。

测试程序

1. 在你的反检测浏览器中创建第一个会话/配置文件

2. 访问测试页面 TypingDNA[https://www.typingdna.com/demo-login.html]

3. 想出一个独特的登录名和密码，写下来（不需要邮箱确认）

4. 手动输入数据注册账户

5. 使用相同的凭证登录几次（建议登录4-5次），以增加注册计数器并提高行为模型的准确性

6. 创建一个新会话/配置文件（你甚至可以使用不同的设备）

7. 访问测试页面 TypingDNA[https://www.typingdna.com/demo-login.html]

8. 使用相同的登录名和密码再次登录——手动输入它们，但这次是在新会话或新设备上

手动输入测试结果

通过从新设备登录，注册计数器增加。这表明系统成功地识别了你独特的打字行为，并将两个完全不同的会话或设备链接在一起。

这是一个关键威胁，一个良好实现的像人类打印的粘贴功能应该消除这一威胁。

Linken Sphere中的HLI测试结果

在优化Linken Sphere中的HLI功能时，我们考虑了这一行为因素。Linken Sphere中的每个会话都会生成其独特的打字模式。

这就是为什么使用HLI在Linken Sphere中进行的类似测试会产生完全不同的结果。

第一次会话

注册和登录成功，注册计数器增加。

第二次（或任何其他）会话

可能有两种情况：

• 要么发生登录错误（新的打字模式与之前的模式不匹配）
• 要么登录成功，但系统没有增加注册计数器，提示重新输入凭证——以捕获新的打字模式。

这证明每个LS会话都会生成一个独特的行为指纹，就像在一个正确实现的“像人类打印”功能中应该有的那样。该方法有效地防止了在不同会话之间使用HLI时跨会话账户的链接。

你确定你在反检测浏览器中使用的HLI功能正常工作吗？还是这只是你需要考虑的另一个风险因素？

自己测试一下你的反检测浏览器——看看它是否真的提供了保护，还是实际上助长了去匿名化的风险。

总结一下

产品（版本）\t事件 – 手动\t事件 – HLI\tTypingDNA – 手动\tTypingDNA – HLI Linken Sphere 2 v2.4.0\t优秀\t优秀\t优秀\t优秀 Octo Browser v2.5.5\t优秀\t好\t优秀\t差 Dolphin Anty v2025.152.125.0\t差\t糟糕\t优秀\t糟糕 Undetectable v2.32.1\t优秀\t差\t优秀\t差 Adspower v6.12.6.0\t优秀\t糟糕\t优秀\t糟糕 Odeteсt 浏览器（前AQUM）v3.7.40\t优秀\t差\t优秀\t糟糕 GoLogin v3.3.83.79\t优秀\t差\t优秀\t差 Vision v3.0.38\t优秀\t糟糕\t优秀\t糟糕

根据比较测试结果，很明显，并不是每个“像人类打印”的实现都同样可靠或安全。

Linken Sphere是毫无争议的领导者。它是唯一在手动输入和使用“像人类打印”时都表现出正确行为的产品。

它的事件级别行为与Chrome中的真实手动输入完全匹配，TypingDNA结果确认了每个会话独立输入模式的良好实现。HLI不仅仅是“工作”——它是以正确的方式工作。

除了引入创新——其中许多是我们首次为行业带来的——我们还积极维护现有功能，并迅速回应反欺诈系统中出现的威胁。

最重要的是——不要盲目依赖一个产品，仅仅因为它曾经工作过。反欺诈技术不断发展，因此你用来上网的工具不仅要能工作——它必须保持领先一步。