contextmenu事件中必须在回调第一行同步调用e.preventDefault()，否则原生菜单会闪现；自定义菜单应挂载到document.body，用clientX/Y定位并设position:fixed；iframe和Shadow DOM需分别在其contentDocument或shadowRoot上监听；菜单关闭后须remove()并恢复焦点。
contextmenu 事件必须同步调用 preventDefault()
不拦住原生菜单，自定义菜单就等于白做——原生菜单和你的 DOM 会同时弹出，视觉混乱，交互冲突。
关键不是“有没有写”，而是“什么时候写”：必须在 contextmenu 回调函数第一行立刻执行 e.preventDefault()。任何延迟（比如包在 setTimeout、Promise.then 或条件判断之后）都会导致原生菜单闪现一次。
常见踩坑点：
- 监听绑在
document上，但没排除<input>、<textarea>等需要右键粘贴的元素，结果用户无法粘贴 - 多个监听器共存，只在一个里写了
preventDefault()，其他分支漏掉 - 用了
oncontextmenu="return false"这种内联写法，后续动态控制困难，且无法阻止冒泡传播
菜单 DOM 应挂载到 document.body 而非目标元素内部
把菜单 <div class="custom-menu"> 插入被右键点击的元素内部，看似方便定位，实则极不稳定：React/Vue 组件重渲染、innerHTML = ... 覆盖、甚至父容器 display: none 切换，都会让菜单瞬间消失或错位。
立即学习“前端免费学习笔记（深入）”；
稳妥做法是统一挂到 document.body：
- 创建菜单后立即执行
document.body.appendChild(menu) - 用
e.clientX和e.clientY计算位置（不是pageX/Y），并加px单位 - 菜单样式必须含
position: fixed或position: absolute+top/left动态赋值 - 避免用
getBoundingClientRect()直接定位——它依赖目标元素坐标，滚动/缩放时极易偏移
iframe 和 Shadow DOM 中 contextmenu 不会自动穿透
右键目标在 iframe 里？主页面监听 contextmenu 完全无效。同理，Shadow DOM 默认隔离事件，mode: "closed" 下连监听都注册不上。
必须分场景处理：
-
iframe场景：获取其contentDocument，在其上单独绑定addEventListener('contextmenu', handler) - Shadow DOM 场景：确保使用
mode: "open"，并在shadowRoot上监听，不能只绑在宿主元素上 - 嵌套多层 iframe？每层都要独立监听，不存在“父级代理”机制
- 移动端 Safari 对
contextmenu支持仍不可靠（iOS 15+ 才稳定），真要兼容得降级为touchstart+ 定时器模拟长按
菜单关闭后必须显式移除 DOM 并恢复焦点
只设 display: none 不够——残留的菜单节点可能拦截后续点击、键盘事件，甚至影响屏幕阅读器行为。
更隐蔽的问题是焦点丢失：用户右键前聚焦在输入框，菜单关闭后光标没了，Tab 键失效，快捷键失灵。
- 触发
contextmenu时，先缓存document.activeElement（过滤掉body、html等无效节点） - 菜单关闭后，对缓存元素调用
el.focus({ preventScroll: true })，preventScroll防止意外滚动 - 菜单项点击后，除了隐藏菜单，还要立即
menu.remove()或至少menu.style.display = 'none'并清空事件监听 - 监听
click关闭菜单时，用e.target.closest('.custom-menu') === null判断是否点在菜单外部，避免点菜单项时误关
最麻烦的从来不是画出菜单，而是让它在滚动、缩放、iframe 嵌套、Shadow DOM、高 DPI 屏幕、移动端长按这些边界条件下，既不闪、不漏、不卡，也不偷偷吃掉用户的焦点和操作意图。
