oncontextmenu="return false"仅对绑定元素生效且易被绕过，现代浏览器（如Brave）已弱化支持；可靠方案是document.addEventListener("contextmenu", e => e.preventDefault())，需同步调用、避免重复绑定并注意移动端长按无标准拦截API。
现代浏览器中，oncontextmenu="return false" 或 event.preventDefault() 只能拦截默认右键菜单，无法真正“禁止”右键——用户仍可通过 Shift+F10、开发者工具、禁用 JS、长按（移动端）等方式绕过。前端拦截仅对普通用户构成轻微门槛，敏感内容必须靠服务端控制。
为什么 oncontextmenu="return false" 有时失效
这个写法看似简单，但实际行为受绑定位置、执行时机和浏览器策略影响很大：
- 只对绑定的 DOM 元素及其子元素生效；
<body oncontextmenu="return false">不会拦截<iframe>内部的右键事件，需单独对其contentDocument设置 - 内联写法会覆盖通过
addEventListener添加的同类型监听器，若页面其他脚本也监听contextmenu，可能因执行顺序导致拦截被跳过 - 在 Shadow DOM、严格模式或某些 WebView（如旧版 Android）中，
return false不保证阻止默认行为，必须显式调用e.preventDefault() - Brave 等现代浏览器已弱化对该属性的支持，仅靠它无法保证跨浏览器一致性
addEventListener('contextmenu', ...) 怎么写才可靠
这是目前兼容性最好、可控性最强的方式，但要注意几个关键点：
- 必须在事件回调中同步调用
e.preventDefault()，不能放在setTimeout、Promise.then或条件分支外层遗漏调用 - 若只想禁某区域（如图片区），绑定到具体元素比绑定
document更安全：document.getElementById('image-area').addEventListener('contextmenu', e => e.preventDefault()) - 避免误拦表单控件：若绑定在
document上，建议加判断：if (!e.target.matches('input, textarea, select')) e.preventDefault() - 不要重复添加监听器，尤其在 React/Vue 组件中，卸载时需调用
removeEventListener，否则可能内存泄漏或触发多次拦截
移动端长按怎么处理
iOS Safari 和 Android Chrome 中，“长按”常触发系统级菜单（复制/搜索/保存图片），contextmenu 事件根本不会触发，或触发不稳定：
Article To Html
下载
文章转信息图。将文章/笔记转化为手机可读的 HTML 信息图，自动匹配视觉风格。触发场景：文章转图、笔记转图、信息图、转小红书图、做张图、可视化这篇文章、文生图。
立即学习“前端免费学习笔记（深入）”；
-
<img draggable="false">可降低长按时“保存图片”选项出现概率 - CSS 必须加：
-webkit-touch-callout: none（iOS Safari 专用），配合user-select: none和-webkit-user-drag: none - 监听
touchstart并preventDefault()可能破坏滚动，不推荐全局使用；仅对特定元素（如画布）谨慎尝试 - 没有标准 API 能禁用长按菜单——这是浏览器厂商刻意保留的安全机制，不是代码缺陷
禁用右键后还要防什么
只拦右键远远不够，用户仍可通过多种方式获取内容：
- 禁用 JS 后，所有基于
contextmenu的拦截完全失效 -
onselectstart和user-select: none防文字选中，但不影响<input>和<textarea> -
ondragstart="return false"+-webkit-user-drag: none防拖拽图片，但后者仅 Blink/WebKit 有效 - 真正需要保护的资源（高清图、文档、代码片段）应走服务端鉴权、动态水印、分片加载或 DRM，而非依赖前端拦截
最常被忽略的一点：很多人花大量时间调试 contextmenu，却没意识到，只要用户打开开发者工具，删掉监听器或直接 document.oncontextmenu = null，一切防护就形同虚设——这层限制是设计使然，不是 bug，也不该试图“修复”。
