document.activeElement 返回当前文档中获得焦点的 DOM 元素，可能是 contenteditable 容器、表单控件或其父节点，但不保证是可编辑区域本身；需结合层级遍历与 contenteditable 属性验证。
Document.activeElement 返回的是什么元素
document.activeElement 返回当前文档中获得焦点的 DOM 元素，但要注意：它不保证是「可编辑内容区域」本身，而可能是其父容器（比如 div[contenteditable="true"]），也可能是 input、textarea 等原生表单控件。
常见误区是认为只要 document.activeElement 不为 body 或 html 就说明编辑器有焦点——实际可能只是焦点落在了编辑器外的按钮上，而编辑器内部并未激活。
- 若编辑器是
contenteditable元素，document.activeElement通常是它自己（或它的某个子节点，取决于浏览器） - 若编辑器基于
iframe（如旧版 TinyMCE 或自建 iframe 编辑器），document.activeElement永远不会返回 iframe 内部元素，因为它属于另一个 document 上下文 - 在 Shadow DOM 场景下，如果编辑器封装在 shadow root 中，
document.activeElement只能返回 shadow host，无法穿透
判断焦点是否落在 contenteditable 区域内
不能只靠 document.activeElement 的 tagName 或属性做简单判断，得结合层级和可编辑性验证：
- 先检查
document.activeElement是否为contenteditable元素：activeEl?.hasAttribute("contenteditable") && activeEl.contentEditable !== "false" - 如果不是，向上遍历父节点（用
activeEl.parentElement），直到找到最近的contenteditable祖先，或到达document.body - 注意
document.activeElement可能是文本节点（Node.TEXT_NODE），此时需用parentNode回溯
简写判断逻辑示例：
立即学习“前端免费学习笔记（深入）”；
function isFocusInEditor(editorRoot) {
const active = document.activeElement;
if (!active) return false;
if (active === editorRoot || editorRoot.contains(active)) {
// 检查是否真能编辑（排除 disabled / readonly / contenteditable="false"）
let el = active;
while (el && el !== editorRoot && !el.hasAttribute("contenteditable")) {
el = el.parentElement;
}
return el && el.hasAttribute("contenteditable") && el.contentEditable !== "false";
}
return false;
}
iframe 编辑器必须切换到子 document
对基于 iframe 的编辑器（例如设置 designMode = "on" 或使用 document.execCommand 的老方案），document.activeElement 在父页面始终是 iframe 元素本身，永远读不到 iframe 内的实际焦点元素。
- 必须通过
iframe.contentDocument获取子 document，再调用它的activeElement - 注意跨域限制：若 iframe src 是不同源地址，访问
contentDocument会抛出SecurityError - 安全做法是加 try/catch，并确认 iframe 已加载完成（监听
load事件）
示例：
const iframe = document.getElementById("editor-iframe");
if (iframe.contentDocument) {
try {
const innerActive = iframe.contentDocument.activeElement;
// 此时 innerActive 才是 iframe 内真正的焦点元素
} catch (e) {
// 跨域或未加载完成
}
}
focusin/focusout 事件比轮询 activeElement 更可靠
单纯定时轮询 document.activeElement 效率低、易漏事件；更稳妥的方式是监听 focusin 和 focusout，并记录编辑器区域的状态变化。
- 给编辑器根节点绑定
focusin，表示焦点进入（包括从子元素冒泡上来） - 给
document绑定focusout，配合relatedTarget判断焦点是否移出了整个编辑器区域 - 避免用
blur，它不冒泡，且无法区分焦点去向
关键点：焦点可能从编辑器内一个 input 移到另一个 input，这时 focusout 会触发但焦点仍在编辑器中——所以必须结合 relatedTarget 做 containment 检查。
容易被忽略的是异步渲染场景：React/Vue 的编辑器组件可能在焦点事件触发后才完成挂载，导致 contains() 判断失败。建议在事件回调里加一层微任务延迟（queueMicrotask）再检查。
