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></textarea> 等需要右键粘贴的元素，结果用户无法粘贴
• 多个监听器共存，只在一个里写了 preventDefault()，其他分支漏掉
• 用了 oncontextmenu="return false" 这种内联写法，后续动态控制困难，且无法阻止冒泡传播

菜单 DOM 应挂载到 document.body 而非目标元素内部

把菜单 <div class="custom-menu"> 插入被右键点击的元素内部，看似方便定位，实则极不稳定：React/Vue 组件重渲染、<code>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" 下连监听都注册不上。

html-deploy

使用 htmlcode.fun 将 HTML 内容或文件部署到网页，适用于用户要求“部署到网页”“托管此 HTML”“生成此前端...的实时链接”等场景。

下载

必须分场景处理：

• 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 屏幕、移动端长按这些边界条件下，既不闪、不漏、不卡，也不偷偷吃掉用户的焦点和操作意图。