被客户要求把网站源码藏起来别让人复制这类需求我接过不止一次。刚入行时我也觉得这很简单——禁右键、禁选中、禁复制三步走就完事。真在多个项目里完整跑过一遍才发现这事远没有想象中那么简单它涉及事件处理、浏览器安全模型、移动端兼容性、还有用户体验的取舍。这篇内容就围绕屏蔽网页源码显示及复制粘贴这个主题把我做过的完整方案按实战顺序拆开讲从右键菜单封锁、文本选择禁用、剪贴板劫持到快捷键屏蔽、反调试、源码混淆再到实测阶段遇到的各种意外情况和误伤。最后我会聊聊为什么前端层的防护本质上拦不住内行以及更理性的分层保护思路。正在做内容站、素材站或者被领导要求给网站加密的开发者这篇应该能帮你少走不少弯路。1. 需求场景拆解谁真的需要屏蔽源码与复制粘贴先别急着写代码把需求想清楚再动手后面能省一半的返工。我见过的屏蔽源码及复制需求看起来长得一样底层的诉求差别很大对应的技术方案也不一样。1.1 表象背后三类典型诉求第一类是内容站。做原创小说、付费报告、行业数据平台的运营方最怕的是用户把整篇文章复制走或者用右键把图片直接另存。这类站点核心诉求是减少顺手转载目标用户是绝大多数普通访客。第二类是素材站。图标库、模板站、前端代码示例站运营方不想让访客一键 Copy 代码再拿去改个名就变成自己的东西。这种需求里防复制只是表里子是不想让别人在几分钟内把我整个价值体系搬走。第三类是内测系统和管理后台。这类往往来自产品经理或安全团队内测数据不能外泄不想让人在控制台里乱调接口参数。这已经超出防复制的范畴直接奔着反调试去了。三类诉求有个共同特点都是针对操作路径的防护而不是数据本身的防护。这个区别不理解清楚后面怎么做都会觉得哪里不对。1.2 一个必须接受的底层事实浏览器必须把源码交给用户这里要先给很多新人泼一盆冷水。用户在浏览器里打开一个网页浏览器要渲染它就必然把 HTML、CSS、JavaScript 完整下载到本地。用户在地址栏输入view-source:网页地址就能直接看到这份源码文本。这不是什么漏洞这就是 HTTP 协议的基本工作方式。所以屏蔽源码显示能做的只是提高顺手查看的门槛而不是做到彻底不可能。稍微懂行一点的人用抓包工具、无头浏览器、或者写几行脚本资源照样落盘。我们在前端做的所有拦截本质上是把防护等级从裸奔抬到需要动手。我在跟客户对齐方案时第一句话永远是能防住的是九成普通用户和一半半懂不懂的爱好者剩下真想拿的前端拦不住。预期先摆平后面每一步才有意义。2. 地基防护右键菜单、拖拽与文本选择的封锁如果目标是让普通用户操作起来别那么顺手第一道防线就是右键菜单、文本选择和拖拽。这三样里最容易做、也最容易做错的是右键。2.1 contextmenu 事件右键封锁的两种写法右键菜单在浏览器里对应contextmenu事件而且这个菜单里本身就自带查看网页源代码和检查两个入口。禁掉右键等于顺手把两个最常用的偷看入口一起堵了。基础写法是全局拦截document.addEventListener(contextmenu, function(event) { event.preventDefault(); });注意我用了event.preventDefault()而不是return false。addEventListener的回调里返回 false 是无效的这个坑我见过不少人踩。如果你用的是 HTML 内联写法oncontextmenureturn false那return false确实有效因为内联事件属性的逻辑是返回非真值就阻止默认行为。两种写法混着用经常会出现一段代码生效另一段不生效的鬼现象。如果只想防正文区域保留页面其他地方的右键操作我更推荐限定范围而不是全局一刀切const article document.getElementById(article-body); article.addEventListener(contextmenu, function(event) { event.preventDefault(); });这样至少不会把评论区、表单输入框这些本来就依赖右键操作的地方一起禁掉不然用户连粘贴都不方便马上就会来投诉。2.2 user-select 与 selectstartCSS 与 JS 的双保险禁选中文本常规做法是 CSS 的user-select: none加上各内核前缀兼容* { -webkit-user-select: none; -moz-user-select: none; -ms-user-select: none; user-select: none; }有人会问有了 CSS 还要不要写 JS 的selectstart拦截要而且最好两个都上。原因有两个。第一不是所有浏览器对user-select的解析都一致老版本 Safari 和部分套壳浏览器会漏。补一段 JS 兜底更稳document.addEventListener(selectstart, function(event) { event.preventDefault(); });第二CSS 只影响视觉上的选择动作某些菜单路径仍然能触发选中逻辑selectstart拦截等于在最前面挡了一道。但这里有个非常重要的注意点只要全局禁了 selectstart用户在自己的输入框里选中文字、复制、剪切都会出问题甚至光标都会变得怪怪的。所以必须对表单元素放行document.addEventListener(selectstart, function(event) { const tag event.target.tagName; if (tag ! INPUT tag ! TEXTAREA) { event.preventDefault(); } });注意全程禁用 selectstart 会让输入框的复制、剪切功能失效。凡是做了全局拦截的几乎都见过我连自己的输入框都复制不了的反馈务必放行 input 和 textarea。2.3 拖拽、长按与图片保护容易漏掉的旁路右键和选中都拦了旁路还有很多。最经典的是图片。用户按住图片直接拖到电脑桌面文件就保存下来了全程没碰过右键菜单。这时候要给图片加draggablefalseimg srccover.jpg draggablefalse alt或者干脆用 CSS 把关键图片改成背景图并配合pointer-events: none禁止指针交互。不过背景图也有问题——打开开发者工具看网络请求图片照样能翻出来。图片保护防的是顺手不是有心。移动端的逻辑又不一样。Android 的 Chrome 上长按文本会弹系统菜单长按图片会弹保存菜单contextmenu事件在多数 Android 浏览器上能模拟触发但 iOS Safari 不一样必须配合-webkit-touch-callout: none才能禁掉长按链接、图片时弹出的那一堆原生菜单img, a { -webkit-touch-callout: none; }这些旁路因素单个拎出来都简单但漏掉任何一个前面的防护就出现一个明显的缺口。我第一次给客户做完整屏蔽方案时就漏了图片拖拽客户随手把产品截图拖走了场景非常尴尬。3. 事件层封锁复制粘贴劫持与快捷键屏蔽地基打完之后第二道防线在事件层把复制、剪切、粘贴这些剪贴板操作以及查看源码相关的快捷键拦下来。3.1 copy/cut/paste 事件劫持剪贴板而不只是 preventDefault禁复制最常见的代码是document.addEventListener(copy, function(event) { event.preventDefault(); });这段代码本身没问题但它的体验是复制没反应用户会很困惑。进阶的做法是劫持——允许复制动作发生但写进剪贴板的不是原文而是你想让他看到的内容。内容站可以这样处理document.addEventListener(copy, function(event) { const selection window.getSelection(); if (selection selection.toString().length 0) { event.clipboardData.setData( text/plain, 本文来自示例内容平台版权所有转载需联系授权。 ); event.preventDefault(); } });这样用户 CtrlC 之后粘贴出来的是版权声明而不是原文用户会觉得复制好用但是内容被处理过挫败感比完全没反应低一些。但这里有个大坑如果没有排除输入框用户在表单里复制自己刚打的字也会被替换成版权声明体验灾难。务必要判断事件来源document.addEventListener(copy, function(event) { const tag event.target.tagName; if (tag INPUT || tag TEXTAREA) { return; } event.clipboardData.setData(text/plain, 内容受保护请注明来源。); event.preventDefault(); });cut 和 paste 同理。有些站点图省事把 paste 也全局禁掉这个动作要非常谨慎。现在很多后台系统依赖粘贴上传图片、粘贴 Markdown 内容全局封 paste 会直接把整条业务链路弄断。我做这类需求时默认只处理 copy 和 cutpaste 除非客户明确要求否则不动。3.2 keydown 组合键封锁F12、CtrlU、CtrlS、CtrlC 的处理快捷键这块的核心是监听keydown目标包括快捷键浏览器默认行为处理建议F12打开开发者工具拦截CtrlShiftI / JDevTools 面板拦截CtrlU查看网页源代码拦截CtrlS保存网页拦截CtrlC复制拦截输入框放行CtrlP打印视需求决定实现上有两个细节要注意。一是用event.key而不是老掉牙的event.keyCode可读性强得多二是必须处理大小写和 Mac 的 Command 键。我常用的写法document.addEventListener(keydown, function(event) { const key event.key; const ctrl event.ctrlKey || event.metaKey; const shift event.shiftKey; if (key F12) { event.preventDefault(); return; } if (ctrl [u, U, s, S].includes(key)) { event.preventDefault(); return; } if (ctrl shift [i, I, j, J, c, C].includes(key)) { event.preventDefault(); return; } });macOS 的 Command 键对应metaKey我第一次做只写了ctrlKey结果所有 Mac 用户都能正常打开源码面板。客户反馈防护是不是没生效排查了半天才发现是系统差异。提示这个拦截只对焦点在页面里有效。用户在地址栏操作、从浏览器菜单栏点开开发者工具页面脚本是完全感知不到、也拦不住的。前端拦截的上限就在这。3.3 移动端差异iOS 长按菜单与 Android 的 WebView 行为移动端的复制粘贴逻辑和 PC 完全不同。iOS Safari 上长按选中文字后弹出的系统菜单是原生 UI监听 copy 事件在多数场景下能拦截但前提是页面处于激活状态、用户确实选中了可选的文本。Android 的 Chrome 行为类似但国内很多 App 内嵌的定制 WebView长按菜单的触发路径各不相同没法用一套代码覆盖全部。比较可靠的做法是在移动端叠加前面说的-webkit-touch-callout: none和 user-select再在 touchmove 上做一次图片兜底document.addEventListener(touchmove, function(event) { if (event.target.nodeName IMG) { event.preventDefault(); } }, { passive: false });这个写法主要防移动端长按图片弹出保存菜单。但{ passive: false }一定要写。我在 Safari 上排查过一个很折磨的问题preventDefault 怎么都不生效最后发现是现代浏览器把 touchmove 默认当成 passive 监听器为了滚动流畅直接忽略了 preventDefault必须显式声明passive: false才能抢回拦截权。4. 更高一层的玩法反调试与源码伪装到了这个层级一般是内测系统或高价值应用的需求。禁右键禁复制已经不够看了得往反调试方向走。4.1 检测开发者工具是否打开反调试里最经典的思路是检测开发者工具的状态常见的有两种。第一种是窗口尺寸检测。DevTools 如果是停靠模式打开window.outerWidth和window.innerWidth的差值会明显变大。定个阈值定期对比(function() { const threshold 200; setInterval(function() { const widthDiff window.outerWidth - window.innerWidth; if (widthDiff threshold) { console.log(检测到开发者工具处于停靠状态); // 这里可以弹提示或以其他方式响应 } }, 1000); })();这个方案准确率不算高窗口全屏或者 DevTools 被拆成独立窗口时尺寸差就没了。第二种更狠利用 debugger 语句的执行时间差。原理是当 DevTools 打开时debugger 语句会触发断点中断前后耗时会被明显拉长function checkDevTools() { const start performance.now(); debugger; const cost performance.now() - start; if (cost 100) { console.log(检测到调试状态); } } setInterval(checkDevTools, 2000);这个方法对开着 DevTools 调试的人有效但同样能被绕过——用户可以在设置里禁用 JavaScript 调试或者直接关掉断点耗时就不会被拉长。这类检测的本质是给想偷懒的人添麻烦不是让专业的人打不开。我在交付内测系统时会把两种检测合并用检测到后弹一个提示层引导用户关闭开发者工具再继续操作。4.2 代码压缩与混淆真正值得投入的部分相比一路的事件拦截真正让源码不好读的是构建阶段的压缩与混淆。现在的打包工具普遍自带压缩它只是去掉空格、缩短变量名而混淆会把可读的字符串、属性名、调用关系做变换生成一堆人眼难以辨认的代码。前端可用的混淆方案不少按需求等级大致这样选需求等级推荐思路实际效果防止小白看懂逻辑压缩 去注释能挡住只看源码的人中间层正规混淆工具变量名、字符串全部变形高价值核心逻辑下沉到服务端计算前端根本没有核心逻辑可看我的经验是混淆只挑核心模块做不要整个站点全量上。全量混淆会让线上报错的堆栈变成天书排错成本直接翻倍业务还没被抄袭先把开发效率搭进去了。4.3 查看网页源代码入口为什么永远堵不死总有人问view-source:能不能禁不能。这是浏览器内置功能网页脚本没有权限修改浏览器的行为。在任意浏览器地址栏输入view-source:网页地址HTML 源码都直接摆在那。更不提还有抓包代理、命令行工具请求发出去的那一刻响应体完整内容就落在对方手里了。所以我的结论很明确源码层面的屏蔽是个伪命题我们能优化的是人在浏览器里用鼠标键盘操作时的路径体验。这也是为什么预期管理那么重要——先把原理讲明白后面做的每层防护客户才清楚钱花在哪、为什么值。5. 实测与踩坑组合拳的真实效果和误伤策略写完了来说说实际跑项目的观测结果和踩坑记录。理论和代码之间隔着一个真实环境。5.1 不同浏览器内核下的行为差异同样一段封锁代码在不同浏览器里的表现差异很大。我整理过一张实测观测表浏览器右键拦截复制拦截快捷键拦截注意点Chrome 桌面版稳定稳定稳定DevTools 独立窗口可通过尺寸检测漏掉Firefox稳定稳定CtrlU 偶有漏拦菜单栏路径无法拦截Safaricontextmenu 触发有延迟长按复制可绕过菜单路径无法拦截必须配 touch-callout套壳双核浏览器兼容模式需单独测可能静默失效不稳定必须真机实测最让我意外的是 Safari。原本以为 iOS 上代码已经写全了一测发现长按弹出的拷贝查询菜单根本拦不住。后来针对 WebKit 内核把-webkit-user-select: none和-webkit-touch-callout: none都补上才算真正堵住。另一个坑是 iframe。页面里嵌了第三方 iframe地图、客服组件、广告外层 document 上绑定的所有事件在 iframe 内部统统不生效。iframe 是独立文档上下文外部 JS 默认操作不到内部。我一次交付时忘了这茬客户在嵌入的地图上右键另存图片保存得十分愉快。后来给 iframe 加上 sandbox 属性限制内部交互才把这条漏路堵上。5.2 最容易被绕过的路径地址栏、抓包与无头浏览器前面说的所有拦截前提都是人在浏览器界面里操作。如果对面不是人是脚本呢那就完全是另一个世界了。常见的绕过路径有三条。第一条抓包代理直接记录所有资源请求源码和图片原样落盘前端拦截不到这个层面第二条无头浏览器自动打开页面跑一遍脚本后把渲染完成的 DOM 导出页面以为是正常用户访问第三条命令行直接拉 HTML配合正则把关键内容提走简单粗暴。这三条路径前端方案全都拦不住因为它们绕过了浏览器 UI在协议层直接取数据。所以在跟客户对齐时我一定会讲前端能防的是人防不了机器。如果你的目标是防爬虫应该去做服务端限流、接口鉴权、行为风控而不是在这里抠前端事件。5.3 用户体验的代价一个真实的误伤案例防护做得越狠越容易误伤正常用户。讲个我实际跟进过的案例。某内容平台上线了禁复制 禁打印 禁开发者工具三件套结果运营同事自己先崩溃了日常需要复制稿件标题到内部沟通软件复制出去全部变成内容受保护市场部想保存网页截图存档CtrlS 被禁甚至有用户反馈页面上的滑块验证码拖不动排查半天发现是全局 touchmove preventDefault 把滚动组件一起给挡了。最终项目组做了让步复制拦截改成按登录状态区分登录用户放开游客只能看到前几段且不可复制打印事件直接放开快捷键只保留 F12 拦截。调整后一周用户投诉量从每天几十条降到零。这个案例给我最大的教训就是防护策略必须是分层的、可配置的而不是一个开关把所有权限全部拉满。6. 更理性的内容保护思路防君子与防小人的分层策略跑了几个项目之后我在这件事上的思路已经从怎么写拦截代码变成怎么设计方案。如果你现在问我有没有最佳实践我会说分层。6.1 内容可见但好溯源动态水印与用户标识现在不少内容平台选择的方案不是禁复制而是允许复制但可溯源。做法是给每个用户生成随机隐藏标识标记到 DOM 属性、图片 URL 参数、甚至复制出去的文本片段里。举个具体的复制时不是在剪贴板里塞版权声明而是在文本末尾追加一段用透明色、极小字号渲染的隐藏字符串内容包含当前用户的短 ID。一旦发现某篇文章被原样转载可以从转载内容里解码出转载源头是哪个账号。这个方案既没有破坏复制体验又给了平台追责能力比一禁了之高明一个段位。图片水印同理。服务端在生成图片时叠加半透明水印水印包含用户 ID 和时间戳用户截图保存水印也跟着走。缺点是增加计算和带宽成本但对高价值素材站来说性价比远超各种前端拦截。6.2 真正的核心逻辑放在服务端如果某项内容的价值高到需要保护那它最不该出现的位置就是前端。常见做法是把核心计算放到服务端前端只拿最终结果。举个例子一个比价类站点核心是价格计算规则。如果规则写在 JavaScript 里混淆得再深也迟早被扒清楚。合理的设计是前端传参、服务端返回最终价格前端只剩调用接口的交互逻辑。这样源码全部公开也没人能知道背后的计算模型和数据来源。再比如 Canvas 渲染文字。论坛产品为了防止正文被选中复制会把文本绘制到 canvas 上用户想复制只能走 OCR成本立刻上了一个台阶。代价是对无障碍阅读和 SEO 不友好需要额外提供隐藏的无障碍文本层并且保证两层内容同步更新。6.3 授权机制与规则兜底最后一层是很多技术人容易忽略的规则和协议。技术防护解决操作路径层面的问题解决不了为什么有人非要偷的问题。给内容加上清晰的版权声明、转载授权入口、付费授权模式再从平台层面设立举报和维权通道组合起来才是一个完整闭环。我现在的习惯是在方案里把防护目标拆成三层拦截随手操作前端事件、提高复制成本水印、混淆、Canvas 渲染、威慑恶意批量服务端风控加条款约束。每一层对应不同的投入和效果客户按自己的预算和内容价值选层搭配。前端这条线做到让九成用户觉得麻烦就够了没必要为了剩下一成而把另一半正常用户也挡在门外那样维护成本太高。从我个人的实操体会来说真正好用的方案永远是让正常用户无感让偷懒的人碍手让专业的人开始权衡成本。这比单纯堆几行拦截代码要难但值得。
被客户要求把网站源码藏起来别让人复制这类需求我接过不止一次。刚入行时我也觉得这很简单——禁右键、禁选中、禁复制三步走就完事。真在多个项目里完整跑过一遍才发现这事远没有想象中那么简单它涉及事件处理、浏览器安全模型、移动端兼容性、还有用户体验的取舍。这篇内容就围绕屏蔽网页源码显示及复制粘贴这个主题把我做过的完整方案按实战顺序拆开讲从右键菜单封锁、文本选择禁用、剪贴板劫持到快捷键屏蔽、反调试、源码混淆再到实测阶段遇到的各种意外情况和误伤。最后我会聊聊为什么前端层的防护本质上拦不住内行以及更理性的分层保护思路。正在做内容站、素材站或者被领导要求给网站加密的开发者这篇应该能帮你少走不少弯路。1. 需求场景拆解谁真的需要屏蔽源码与复制粘贴先别急着写代码把需求想清楚再动手后面能省一半的返工。我见过的屏蔽源码及复制需求看起来长得一样底层的诉求差别很大对应的技术方案也不一样。1.1 表象背后三类典型诉求第一类是内容站。做原创小说、付费报告、行业数据平台的运营方最怕的是用户把整篇文章复制走或者用右键把图片直接另存。这类站点核心诉求是减少顺手转载目标用户是绝大多数普通访客。第二类是素材站。图标库、模板站、前端代码示例站运营方不想让访客一键 Copy 代码再拿去改个名就变成自己的东西。这种需求里防复制只是表里子是不想让别人在几分钟内把我整个价值体系搬走。第三类是内测系统和管理后台。这类往往来自产品经理或安全团队内测数据不能外泄不想让人在控制台里乱调接口参数。这已经超出防复制的范畴直接奔着反调试去了。三类诉求有个共同特点都是针对操作路径的防护而不是数据本身的防护。这个区别不理解清楚后面怎么做都会觉得哪里不对。1.2 一个必须接受的底层事实浏览器必须把源码交给用户这里要先给很多新人泼一盆冷水。用户在浏览器里打开一个网页浏览器要渲染它就必然把 HTML、CSS、JavaScript 完整下载到本地。用户在地址栏输入view-source:网页地址就能直接看到这份源码文本。这不是什么漏洞这就是 HTTP 协议的基本工作方式。所以屏蔽源码显示能做的只是提高顺手查看的门槛而不是做到彻底不可能。稍微懂行一点的人用抓包工具、无头浏览器、或者写几行脚本资源照样落盘。我们在前端做的所有拦截本质上是把防护等级从裸奔抬到需要动手。我在跟客户对齐方案时第一句话永远是能防住的是九成普通用户和一半半懂不懂的爱好者剩下真想拿的前端拦不住。预期先摆平后面每一步才有意义。2. 地基防护右键菜单、拖拽与文本选择的封锁如果目标是让普通用户操作起来别那么顺手第一道防线就是右键菜单、文本选择和拖拽。这三样里最容易做、也最容易做错的是右键。2.1 contextmenu 事件右键封锁的两种写法右键菜单在浏览器里对应contextmenu事件而且这个菜单里本身就自带查看网页源代码和检查两个入口。禁掉右键等于顺手把两个最常用的偷看入口一起堵了。基础写法是全局拦截document.addEventListener(contextmenu, function(event) { event.preventDefault(); });注意我用了event.preventDefault()而不是return false。addEventListener的回调里返回 false 是无效的这个坑我见过不少人踩。如果你用的是 HTML 内联写法oncontextmenureturn false那return false确实有效因为内联事件属性的逻辑是返回非真值就阻止默认行为。两种写法混着用经常会出现一段代码生效另一段不生效的鬼现象。如果只想防正文区域保留页面其他地方的右键操作我更推荐限定范围而不是全局一刀切const article document.getElementById(article-body); article.addEventListener(contextmenu, function(event) { event.preventDefault(); });这样至少不会把评论区、表单输入框这些本来就依赖右键操作的地方一起禁掉不然用户连粘贴都不方便马上就会来投诉。2.2 user-select 与 selectstartCSS 与 JS 的双保险禁选中文本常规做法是 CSS 的user-select: none加上各内核前缀兼容* { -webkit-user-select: none; -moz-user-select: none; -ms-user-select: none; user-select: none; }有人会问有了 CSS 还要不要写 JS 的selectstart拦截要而且最好两个都上。原因有两个。第一不是所有浏览器对user-select的解析都一致老版本 Safari 和部分套壳浏览器会漏。补一段 JS 兜底更稳document.addEventListener(selectstart, function(event) { event.preventDefault(); });第二CSS 只影响视觉上的选择动作某些菜单路径仍然能触发选中逻辑selectstart拦截等于在最前面挡了一道。但这里有个非常重要的注意点只要全局禁了 selectstart用户在自己的输入框里选中文字、复制、剪切都会出问题甚至光标都会变得怪怪的。所以必须对表单元素放行document.addEventListener(selectstart, function(event) { const tag event.target.tagName; if (tag ! INPUT tag ! TEXTAREA) { event.preventDefault(); } });注意全程禁用 selectstart 会让输入框的复制、剪切功能失效。凡是做了全局拦截的几乎都见过我连自己的输入框都复制不了的反馈务必放行 input 和 textarea。2.3 拖拽、长按与图片保护容易漏掉的旁路右键和选中都拦了旁路还有很多。最经典的是图片。用户按住图片直接拖到电脑桌面文件就保存下来了全程没碰过右键菜单。这时候要给图片加draggablefalseimg srccover.jpg draggablefalse alt或者干脆用 CSS 把关键图片改成背景图并配合pointer-events: none禁止指针交互。不过背景图也有问题——打开开发者工具看网络请求图片照样能翻出来。图片保护防的是顺手不是有心。移动端的逻辑又不一样。Android 的 Chrome 上长按文本会弹系统菜单长按图片会弹保存菜单contextmenu事件在多数 Android 浏览器上能模拟触发但 iOS Safari 不一样必须配合-webkit-touch-callout: none才能禁掉长按链接、图片时弹出的那一堆原生菜单img, a { -webkit-touch-callout: none; }这些旁路因素单个拎出来都简单但漏掉任何一个前面的防护就出现一个明显的缺口。我第一次给客户做完整屏蔽方案时就漏了图片拖拽客户随手把产品截图拖走了场景非常尴尬。3. 事件层封锁复制粘贴劫持与快捷键屏蔽地基打完之后第二道防线在事件层把复制、剪切、粘贴这些剪贴板操作以及查看源码相关的快捷键拦下来。3.1 copy/cut/paste 事件劫持剪贴板而不只是 preventDefault禁复制最常见的代码是document.addEventListener(copy, function(event) { event.preventDefault(); });这段代码本身没问题但它的体验是复制没反应用户会很困惑。进阶的做法是劫持——允许复制动作发生但写进剪贴板的不是原文而是你想让他看到的内容。内容站可以这样处理document.addEventListener(copy, function(event) { const selection window.getSelection(); if (selection selection.toString().length 0) { event.clipboardData.setData( text/plain, 本文来自示例内容平台版权所有转载需联系授权。 ); event.preventDefault(); } });这样用户 CtrlC 之后粘贴出来的是版权声明而不是原文用户会觉得复制好用但是内容被处理过挫败感比完全没反应低一些。但这里有个大坑如果没有排除输入框用户在表单里复制自己刚打的字也会被替换成版权声明体验灾难。务必要判断事件来源document.addEventListener(copy, function(event) { const tag event.target.tagName; if (tag INPUT || tag TEXTAREA) { return; } event.clipboardData.setData(text/plain, 内容受保护请注明来源。); event.preventDefault(); });cut 和 paste 同理。有些站点图省事把 paste 也全局禁掉这个动作要非常谨慎。现在很多后台系统依赖粘贴上传图片、粘贴 Markdown 内容全局封 paste 会直接把整条业务链路弄断。我做这类需求时默认只处理 copy 和 cutpaste 除非客户明确要求否则不动。3.2 keydown 组合键封锁F12、CtrlU、CtrlS、CtrlC 的处理快捷键这块的核心是监听keydown目标包括快捷键浏览器默认行为处理建议F12打开开发者工具拦截CtrlShiftI / JDevTools 面板拦截CtrlU查看网页源代码拦截CtrlS保存网页拦截CtrlC复制拦截输入框放行CtrlP打印视需求决定实现上有两个细节要注意。一是用event.key而不是老掉牙的event.keyCode可读性强得多二是必须处理大小写和 Mac 的 Command 键。我常用的写法document.addEventListener(keydown, function(event) { const key event.key; const ctrl event.ctrlKey || event.metaKey; const shift event.shiftKey; if (key F12) { event.preventDefault(); return; } if (ctrl [u, U, s, S].includes(key)) { event.preventDefault(); return; } if (ctrl shift [i, I, j, J, c, C].includes(key)) { event.preventDefault(); return; } });macOS 的 Command 键对应metaKey我第一次做只写了ctrlKey结果所有 Mac 用户都能正常打开源码面板。客户反馈防护是不是没生效排查了半天才发现是系统差异。提示这个拦截只对焦点在页面里有效。用户在地址栏操作、从浏览器菜单栏点开开发者工具页面脚本是完全感知不到、也拦不住的。前端拦截的上限就在这。3.3 移动端差异iOS 长按菜单与 Android 的 WebView 行为移动端的复制粘贴逻辑和 PC 完全不同。iOS Safari 上长按选中文字后弹出的系统菜单是原生 UI监听 copy 事件在多数场景下能拦截但前提是页面处于激活状态、用户确实选中了可选的文本。Android 的 Chrome 行为类似但国内很多 App 内嵌的定制 WebView长按菜单的触发路径各不相同没法用一套代码覆盖全部。比较可靠的做法是在移动端叠加前面说的-webkit-touch-callout: none和 user-select再在 touchmove 上做一次图片兜底document.addEventListener(touchmove, function(event) { if (event.target.nodeName IMG) { event.preventDefault(); } }, { passive: false });这个写法主要防移动端长按图片弹出保存菜单。但{ passive: false }一定要写。我在 Safari 上排查过一个很折磨的问题preventDefault 怎么都不生效最后发现是现代浏览器把 touchmove 默认当成 passive 监听器为了滚动流畅直接忽略了 preventDefault必须显式声明passive: false才能抢回拦截权。4. 更高一层的玩法反调试与源码伪装到了这个层级一般是内测系统或高价值应用的需求。禁右键禁复制已经不够看了得往反调试方向走。4.1 检测开发者工具是否打开反调试里最经典的思路是检测开发者工具的状态常见的有两种。第一种是窗口尺寸检测。DevTools 如果是停靠模式打开window.outerWidth和window.innerWidth的差值会明显变大。定个阈值定期对比(function() { const threshold 200; setInterval(function() { const widthDiff window.outerWidth - window.innerWidth; if (widthDiff threshold) { console.log(检测到开发者工具处于停靠状态); // 这里可以弹提示或以其他方式响应 } }, 1000); })();这个方案准确率不算高窗口全屏或者 DevTools 被拆成独立窗口时尺寸差就没了。第二种更狠利用 debugger 语句的执行时间差。原理是当 DevTools 打开时debugger 语句会触发断点中断前后耗时会被明显拉长function checkDevTools() { const start performance.now(); debugger; const cost performance.now() - start; if (cost 100) { console.log(检测到调试状态); } } setInterval(checkDevTools, 2000);这个方法对开着 DevTools 调试的人有效但同样能被绕过——用户可以在设置里禁用 JavaScript 调试或者直接关掉断点耗时就不会被拉长。这类检测的本质是给想偷懒的人添麻烦不是让专业的人打不开。我在交付内测系统时会把两种检测合并用检测到后弹一个提示层引导用户关闭开发者工具再继续操作。4.2 代码压缩与混淆真正值得投入的部分相比一路的事件拦截真正让源码不好读的是构建阶段的压缩与混淆。现在的打包工具普遍自带压缩它只是去掉空格、缩短变量名而混淆会把可读的字符串、属性名、调用关系做变换生成一堆人眼难以辨认的代码。前端可用的混淆方案不少按需求等级大致这样选需求等级推荐思路实际效果防止小白看懂逻辑压缩 去注释能挡住只看源码的人中间层正规混淆工具变量名、字符串全部变形高价值核心逻辑下沉到服务端计算前端根本没有核心逻辑可看我的经验是混淆只挑核心模块做不要整个站点全量上。全量混淆会让线上报错的堆栈变成天书排错成本直接翻倍业务还没被抄袭先把开发效率搭进去了。4.3 查看网页源代码入口为什么永远堵不死总有人问view-source:能不能禁不能。这是浏览器内置功能网页脚本没有权限修改浏览器的行为。在任意浏览器地址栏输入view-source:网页地址HTML 源码都直接摆在那。更不提还有抓包代理、命令行工具请求发出去的那一刻响应体完整内容就落在对方手里了。所以我的结论很明确源码层面的屏蔽是个伪命题我们能优化的是人在浏览器里用鼠标键盘操作时的路径体验。这也是为什么预期管理那么重要——先把原理讲明白后面做的每层防护客户才清楚钱花在哪、为什么值。5. 实测与踩坑组合拳的真实效果和误伤策略写完了来说说实际跑项目的观测结果和踩坑记录。理论和代码之间隔着一个真实环境。5.1 不同浏览器内核下的行为差异同样一段封锁代码在不同浏览器里的表现差异很大。我整理过一张实测观测表浏览器右键拦截复制拦截快捷键拦截注意点Chrome 桌面版稳定稳定稳定DevTools 独立窗口可通过尺寸检测漏掉Firefox稳定稳定CtrlU 偶有漏拦菜单栏路径无法拦截Safaricontextmenu 触发有延迟长按复制可绕过菜单路径无法拦截必须配 touch-callout套壳双核浏览器兼容模式需单独测可能静默失效不稳定必须真机实测最让我意外的是 Safari。原本以为 iOS 上代码已经写全了一测发现长按弹出的拷贝查询菜单根本拦不住。后来针对 WebKit 内核把-webkit-user-select: none和-webkit-touch-callout: none都补上才算真正堵住。另一个坑是 iframe。页面里嵌了第三方 iframe地图、客服组件、广告外层 document 上绑定的所有事件在 iframe 内部统统不生效。iframe 是独立文档上下文外部 JS 默认操作不到内部。我一次交付时忘了这茬客户在嵌入的地图上右键另存图片保存得十分愉快。后来给 iframe 加上 sandbox 属性限制内部交互才把这条漏路堵上。5.2 最容易被绕过的路径地址栏、抓包与无头浏览器前面说的所有拦截前提都是人在浏览器界面里操作。如果对面不是人是脚本呢那就完全是另一个世界了。常见的绕过路径有三条。第一条抓包代理直接记录所有资源请求源码和图片原样落盘前端拦截不到这个层面第二条无头浏览器自动打开页面跑一遍脚本后把渲染完成的 DOM 导出页面以为是正常用户访问第三条命令行直接拉 HTML配合正则把关键内容提走简单粗暴。这三条路径前端方案全都拦不住因为它们绕过了浏览器 UI在协议层直接取数据。所以在跟客户对齐时我一定会讲前端能防的是人防不了机器。如果你的目标是防爬虫应该去做服务端限流、接口鉴权、行为风控而不是在这里抠前端事件。5.3 用户体验的代价一个真实的误伤案例防护做得越狠越容易误伤正常用户。讲个我实际跟进过的案例。某内容平台上线了禁复制 禁打印 禁开发者工具三件套结果运营同事自己先崩溃了日常需要复制稿件标题到内部沟通软件复制出去全部变成内容受保护市场部想保存网页截图存档CtrlS 被禁甚至有用户反馈页面上的滑块验证码拖不动排查半天发现是全局 touchmove preventDefault 把滚动组件一起给挡了。最终项目组做了让步复制拦截改成按登录状态区分登录用户放开游客只能看到前几段且不可复制打印事件直接放开快捷键只保留 F12 拦截。调整后一周用户投诉量从每天几十条降到零。这个案例给我最大的教训就是防护策略必须是分层的、可配置的而不是一个开关把所有权限全部拉满。6. 更理性的内容保护思路防君子与防小人的分层策略跑了几个项目之后我在这件事上的思路已经从怎么写拦截代码变成怎么设计方案。如果你现在问我有没有最佳实践我会说分层。6.1 内容可见但好溯源动态水印与用户标识现在不少内容平台选择的方案不是禁复制而是允许复制但可溯源。做法是给每个用户生成随机隐藏标识标记到 DOM 属性、图片 URL 参数、甚至复制出去的文本片段里。举个具体的复制时不是在剪贴板里塞版权声明而是在文本末尾追加一段用透明色、极小字号渲染的隐藏字符串内容包含当前用户的短 ID。一旦发现某篇文章被原样转载可以从转载内容里解码出转载源头是哪个账号。这个方案既没有破坏复制体验又给了平台追责能力比一禁了之高明一个段位。图片水印同理。服务端在生成图片时叠加半透明水印水印包含用户 ID 和时间戳用户截图保存水印也跟着走。缺点是增加计算和带宽成本但对高价值素材站来说性价比远超各种前端拦截。6.2 真正的核心逻辑放在服务端如果某项内容的价值高到需要保护那它最不该出现的位置就是前端。常见做法是把核心计算放到服务端前端只拿最终结果。举个例子一个比价类站点核心是价格计算规则。如果规则写在 JavaScript 里混淆得再深也迟早被扒清楚。合理的设计是前端传参、服务端返回最终价格前端只剩调用接口的交互逻辑。这样源码全部公开也没人能知道背后的计算模型和数据来源。再比如 Canvas 渲染文字。论坛产品为了防止正文被选中复制会把文本绘制到 canvas 上用户想复制只能走 OCR成本立刻上了一个台阶。代价是对无障碍阅读和 SEO 不友好需要额外提供隐藏的无障碍文本层并且保证两层内容同步更新。6.3 授权机制与规则兜底最后一层是很多技术人容易忽略的规则和协议。技术防护解决操作路径层面的问题解决不了为什么有人非要偷的问题。给内容加上清晰的版权声明、转载授权入口、付费授权模式再从平台层面设立举报和维权通道组合起来才是一个完整闭环。我现在的习惯是在方案里把防护目标拆成三层拦截随手操作前端事件、提高复制成本水印、混淆、Canvas 渲染、威慑恶意批量服务端风控加条款约束。每一层对应不同的投入和效果客户按自己的预算和内容价值选层搭配。前端这条线做到让九成用户觉得麻烦就够了没必要为了剩下一成而把另一半正常用户也挡在门外那样维护成本太高。从我个人的实操体会来说真正好用的方案永远是让正常用户无感让偷懒的人碍手让专业的人开始权衡成本。这比单纯堆几行拦截代码要难但值得。
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
