beforeinput事件中deleteWordForward与deleteWordBackward操作的影响范围如何确定？

这确实是个挺头疼的细节问题——浏览器对单词级删除的处理一直没完全统一规范，我来结合实际经验和社区梳理的信息给你拆解清楚：

如何确定单词删除操作的影响范围 #

直接用selectionStart/selectionEnd确实拿不到浏览器判定的单词边界，因为这两个属性只反映当前光标位置。要获取实际影响范围，有两种可行思路：

• 临时模拟执行（不推荐长期依赖）：在beforeinput事件触发时，先备份当前输入框的内容和光标位置，然后调用document.execCommand('deleteWordForward')或deleteWordBackward，对比执行前后的内容差异反推删除范围。但要注意execCommand已经被标记为废弃，只是目前多数浏览器还在兼容，不适合生产环境长期使用。
• 手动实现判定逻辑：这是更可靠的方案，但需要对齐各浏览器的行为差异，后面会详细讲具体的逻辑方向。

浏览器对空格的特殊处理差异 #

你观察到的空格行为差异完全是真实存在的，不同浏览器（甚至同一浏览器的不同版本）对“单词”的定义都有细微差别：

• Chrome/Edge：通常把连续空格视为一个“非单词区块”，删除单词时会跳过单个前导/尾随空格，但如果是多个连续空格，会先把整个空格块当作一个单元处理。比如光标在单词后单个空格之后，按Ctrl+Backspace会删除空格+前面的单词；但如果是多个空格，会先删除所有空格，再删除前面的单词。
• Firefox：对空格的处理更“严格”，有时会把前导空格纳入单词范围，比如光标在单词前的空格之后，按Ctrl+Delete会删除空格+后面的单词。
• Safari：行为整体接近Chrome，但在特殊字符（比如连字符、下划线）和空格组合的场景下，会有不一样的判定。

该行为是否标准化？有没有通用正则？ #

遗憾的是，目前没有完全统一的官方标准。HTML标准里只定义了inputType的取值（比如deleteWordForward），但没有明确规定浏览器应该如何判定“单词”的边界。

不过，各浏览器的实现大多基于类似的核心逻辑：区分“单词字符”和“非单词字符”，然后按连续区块来判定删除范围。社区通过逆向工程和测试，总结出大致的正则逻辑（非官方公开，仅作参考）：

• 单词字符：字母、数字、下划线，以及中文、日文等Unicode表意文字（用\p{L}\p{N}_的Unicode正则匹配）。
• 非单词字符：空格、标点符号、特殊符号（用\s\p{P}匹配）。

举个简化的手动实现例子，模拟Chrome风格的向后删除单词边界判定：

function getDeleteWordBackwardRange(text, cursorPos) {
  let start = cursorPos;
  // 先跳过光标前的连续非单词字符（空格、标点）
  const nonWordRegex = /[\s\p{P}]/u;
  while (start > 0 && nonWordRegex.test(text[start - 1])) {
    start--;
  }
  // 再跳过光标前的连续单词字符（字母、数字、表意文字）
  const wordRegex = /[\p{L}\p{N}_]/u;
  while (start > 0 && wordRegex.test(text[start - 1])) {
    start--;
  }
  return { start, end: cursorPos };
}

有没有官方文档说明？ #

目前没有公开的官方文档详细描述各浏览器的单词判定正则。不过可以参考这些方向：

• HTML标准的Input Events章节，里面明确了beforeinput和inputType的定义，但没有细节规范。
• 各浏览器的开发者文档偶尔会提到相关行为，但不会公开具体的实现正则。
• W3C的Input Events工作组讨论记录里有关于单词删除行为的争论，但尚未形成统一标准。

总结建议 #

如果要在自己的项目中统一单词删除的行为，建议：

• 不要依赖浏览器的原生判定，手动实现一套符合产品需求的单词边界逻辑。
• 优先使用Unicode兼容的正则表达式，覆盖多语言场景。
• 针对主流浏览器做兼容性测试，确保你的实现符合大多数用户的操作预期。

内容的提问来源于stack exchange，提问作者micka190