原生contextmenu事件不能直接接管右键菜单，因不调用e.preventDefault()会导致自定义菜单被原生菜单覆盖；调用后需自行处理定位（用getBoundingClientRect换算相对坐标）、ESC关闭、键盘导航、iframe跨域监听及编辑器状态同步等完整逻辑。
为什么原生 contextmenu 事件不能直接用
浏览器默认右键菜单会拦截 contextmenu 事件，但仅阻止它不等于能干净接管——如果没同步调用 e.preventDefault()，自定义菜单弹出瞬间就会被原生菜单盖掉；而调用后又得自己处理所有交互逻辑，包括定位、焦点、ESC 关闭、键盘导航等。更麻烦的是，contenteditable 区域或 iframe 内部的右键行为常不触发父页面监听，容易漏事件。
如何让右键菜单精准出现在鼠标位置且不偏移
关键不是用 clientX/clientY，而是换算成相对于目标容器的坐标，尤其当编辑器有滚动或缩放时：
- 先用
getBoundingClientRect()获取编辑器容器的视口位置 - 再用
e.clientX - rect.left和e.clientY - rect.top得到相对坐标 - 给菜单元素设
position: fixed，再用style.left/top赋值，避免因父级transform导致偏移 - 加个边界检测：如果靠近窗口右/下边缘，自动向左或向上反向展开
怎样安全地插入业务操作项而不破坏编辑器状态
多数 HTML 编辑器（如 quill、tiptap、draft-js）内部维护选区和格式栈，直接在 DOM 上插按钮会丢失上下文。正确做法是：
- 右键触发时，先调用编辑器实例的
getSelection()或state.selection拿当前选区信息 - 菜单项点击后，用编辑器提供的 API 执行操作，比如
editor.formatText(...)或editor.chain().focus().toggleBold().run() - 禁用原生菜单后，必须手动监听
keydown捕获Escape键关闭菜单，否则用户无法退出 - 菜单元素要设
tabindex="-1"并在显示后.focus()，否则键盘操作不可达
iframe 编辑器里右键菜单失效怎么办
像 document.execCommand 时代的老编辑器或某些富文本组件，内容渲染在 iframe 中，主页面的 contextmenu 监听完全收不到事件。必须把监听逻辑注入 iframe 内部：
立即学习“前端免费学习笔记（深入）”；
- 等 iframe
load后，用iframe.contentDocument拿到其 document 对象 - 在其上绑定
addEventListener('contextmenu', handler) - handler 里通过
window.parent或自定义事件（postMessage）把坐标和上下文传回主页面生成菜单 - 注意跨域 iframe 无法访问 contentDocument，此时只能依赖编辑器自身是否暴露右键钩子（如
quill.on('editor-menu')类似机制）
实际中最容易被忽略的是菜单与编辑器状态的耦合时机——菜单项是否可用，不能只看光标位置，还得查当前 block 类型、嵌套层级、是否在代码块内等。这些判断逻辑一旦写死在菜单渲染阶段，后续编辑器状态变更（如用户按 Ctrl+Z 回退）就不同步了。
