禁用右键菜单仅能隐藏上下文菜单，无法真正禁止查看源码；需在 DOM 加载后执行 contextmenu 事件监听并阻止默认行为，但应避免影响富文本编辑器等依赖该事件的组件，且移动端无需处理；前端防护效果有限，关键应加强后端鉴权、数据脱敏与接口权限控制。
禁用右键菜单的常见做法是监听 contextmenu 事件
浏览器原生不提供“禁止查看源码”的能力，但可以通过阻止右键默认行为，隐藏上下文菜单。这仅是表层防护，用户仍可通过快捷键（如 Ctrl+U、F12）或地址栏直接访问 view-source:https://... 查看源码。
在 index.html 的 <script> 中添加：
document.addEventListener('contextmenu', function(e) {
e.preventDefault();
});
注意：该代码需在 DOM 加载完成后执行，否则可能失效。推荐放在 </body> 前，或包裹在 DOMContentLoaded 事件中。
全局禁用右键时，要小心影响正常交互
很多 UI 组件（如富文本编辑器、图表库、自定义右键菜单）依赖 contextmenu 事件。无差别拦截会导致功能异常。
Article To Html
下载
文章转信息图。将文章/笔记转化为手机可读的 HTML 信息图，自动匹配视觉风格。触发场景：文章转图、笔记转图、信息图、转小红书图、做张图、可视化这篇文章、文生图。
立即学习“前端免费学习笔记（深入）”；
- 只对特定区域禁用：给目标容器加 class，例如
no-right-click，再用document.querySelector('.no-right-click').addEventListener('contextmenu', ...) - 排除表单控件：在事件处理中判断
e.target.tagName，跳过INPUT、TEXTAREA、SELECT等元素 - 移动端无需处理：iOS/Android 的长按触发逻辑不同，
contextmenu在多数移动浏览器中本就不触发
混淆和服务器端防护比前端禁右键更有效
前端禁右键几乎不增加安全水位，反而可能干扰用户体验。真正需要保护的是敏感逻辑或数据：
- 业务关键逻辑应移至后端，前端只做展示和校验
- API 接口必须鉴权，不能依赖“前端藏得好”来防调用
- 若需混淆 HTML/JS，可用构建工具（如
webpack+javascript-obfuscator），但仅防轻度窥探，非加密 - 服务端可配置
Content-Security-Policy头限制脚本执行来源，但无法阻止查看源码
别忘了用户总有办法绕过，包括禁用 JS
只要网页能运行，源码就必然被加载到用户设备上。禁用 JavaScript 后，contextmenu 监听完全失效；用户还可通过网络面板（Network → index.html）直接看到原始 HTML。
所以，把精力放在接口权限设计、敏感数据脱敏、合法授权机制上，远比花时间堵右键更有实际意义。
