textarea 的 select 事件会在用户选中文本后触发，但若页面中存在其他可聚焦元素（如按钮、链接），其点击行为可能导致焦点转移并意外触发该事件；需通过检查 document.activeelement 确保事件真正源自 textarea。

textarea 的 select 事件会在用户选中文本后触发，但若页面中存在其他可聚焦元素（如按钮、链接），其点击行为可能导致焦点转移并意外触发该事件；需通过检查 document.activeelement 确保事件真正源自 textarea。

在 Web 开发中，select 事件常用于监听用户在 或 中的文本选择行为。然而，一个常见却容易被忽视的问题是：<strong>即使用户并未主动在 textarea 中执行选择操作，只要页面中任意可聚焦元素（例如 <button> 或 <a>）被点击，该 textarea 的 select 事件也可能被意外触发</a></button></strong>。

这是因为：当用户点击按钮或链接时，浏览器会将焦点移至该元素（使其成为 document.activeElement），而部分浏览器（尤其是 Chromium 内核）在焦点切换过程中，会对先前聚焦的 进行一次“隐式重选”判定——若此前已有选区，便再次派发 select 事件。这并非 bug，而是规范中未明确定义的实现差异，但实际开发中极易导致逻辑误判。

✅ 正确做法：在事件监听器中验证事件源是否为当前活跃的 textarea：

Oiiyao

Oiiyao是一款AI文本写作工具，AI视频本地化平台。

下载

const summary = document.getElementById("summary");
summary?.addEventListener("select", (e) => {
  // 关键校验：确保当前获得焦点的元素就是该 textarea
  if (document.activeElement === summary) {
    console.log("✅ 文本真实被选中，且 textarea 仍处于聚焦状态");
    // 在此处执行高亮、复制、统计等业务逻辑
  } else {
    console.log("⚠️ 忽略：select 事件由焦点切换间接触发，非用户主动选择");
  }
});

? 注意事项：

• 不要依赖 e.target 或 e.currentTarget 判定来源——它们始终指向 textarea，无法区分真实选择与伪触发；
• 推荐使用 document.activeElement === summary 进行严格引用比对（而非仅比对 id），避免 ID 冲突或动态 ID 变更风险；
• 若 textarea 设置了 disabled 或 readonly，它无法获得焦点，select 事件也不会触发（符合预期）；
• 在单页应用（SPA）中，路由跳转或组件重渲染可能导致焦点丢失，建议结合 blur 事件清理临时状态。

? 扩展建议：如需精确获取选中文本内容，可在校验通过后安全调用：

const selectedText = summary.value.substring(summary.selectionStart, summary.selectionEnd);

通过这一校验机制，即可彻底消除因 DOM 交互引发的 select 事件误触发，保障文本选择逻辑的准确性与可靠性。