L1ngg's Home

CSS user-select: none：最常见也最脆弱的一层#

最简单的防复制，一行 CSS：

1
body {
2
  -webkit-user-select: none;
3
  -moz-user-select: none;
4
  -ms-user-select: none;
5
  user-select: none;
6
}

效果是鼠标拖拽选不中任何文字。大量博客站和文档站用的就是这一招。

绕过方法：

方法一，DevTools 直接覆写。打开开发者工具 → Elements 面板 → 选中 body（或对应元素），在 Styles 面板里添加 user-select: auto !important。

方法二，注入样式。方法三，浏览器阅读模式（Firefox / Safari 会重新渲染页面内容，user-select 不生效）。

1
const s = document.createElement('style');
2
s.textContent = '* { user-select: auto !important; }';
3
document.head.appendChild(s);

1
Firefox：地址栏左侧点「切换到阅读视图」
2
Safari：菜单栏 → 显示 → 显示阅读器
3
Chrome：安装阅读模式扩展（原生不内置）

防御强度：极低。 只能挡住不会打开 DevTools 的用户。但胜在零成本、零副作用，作为第一层防线没有坏处。

JS 事件拦截：禁右键、禁选择、禁快捷键#

比 CSS 稍重的一层，用 JavaScript 拦截所有和复制相关的事件：

1
// 禁止右键菜单
2
document.addEventListener('contextmenu', e => e.preventDefault());
3

4
// 禁止选择
5
document.addEventListener('selectstart', e => e.preventDefault());
6

7
// 禁止复制
8
document.addEventListener('copy', e => e.preventDefault());
9

10
// 禁止 Ctrl+C / Ctrl+A 等快捷键
11
document.addEventListener('keydown', e => {
12
  if (e.ctrlKey && ['c', 'a', 'u', 's'].includes(e.key.toLowerCase())) {
13
    e.preventDefault();
14
  }
15
});

四件套一起上，右键、选择、Ctrl+C、Ctrl+A、Ctrl+U（查看源码）、Ctrl+S（保存页面）全部失效。

绕过方法：

方法一，禁用 JavaScript。浏览器设置里关掉当前站的 JS，所有事件监听都不存在了。Chrome 可以在 DevTools → Sources 面板底部点齿轮图标 → 勾选 “Disable JavaScript”。

方法二，用 DevTools 查看和移除事件监听器：

1
// Chrome DevTools 专属 API，查看 document 上所有监听器
2
getEventListeners(document);
3
// 输出：{contextmenu: Array(1), selectstart: Array(1), copy: Array(1), ...}

1
// 暴力方案：克隆节点替换，所有事件监听一次性清除
2
// cloneNode(true) 深拷贝 DOM 但不拷贝事件监听器
3
document.body.parentNode.replaceChild(
4
  document.body.cloneNode(true),
5
  document.body
6
);

替换后页面样式不变，但所有通过 addEventListener 绑定的事件全部消失。

方法三，用浏览器扩展。“Allow Copy” 类扩展的原理也是上面这些：注入脚本覆写 user-select，移除事件拦截。

防御强度：低。 JS 跑在客户端，用户有最终控制权。但对普通用户来说，这一层配合 CSS 已经够用了。

剪贴板劫持：复制到的不是你选的内容#

这一层不阻止你复制，而是在你复制的时候偷换内容：

1
document.addEventListener('copy', e => {
2
  e.preventDefault();
3
  const selection = window.getSelection().toString();
4
  // 在复制的内容后面追加版权信息
5
  const modified = selection + '\n\n——来源：example.com，转载请注明出处';
6
  e.clipboardData.setData('text/plain', modified);
7
});

1
// 现代 Clipboard API，需要用户授权
2
document.addEventListener('copy', async () => {
3
  await navigator.clipboard.writeText('你复制了个寂寞');
4
});

更过分的做法是直接替换成广告、乱码，甚至把你选中的文字改成完全不同的内容。知乎早期就用追加来源的方式。

绕过方法：

跳过剪贴板，直接从 DOM 取文本，不经过 copy 事件：

1
// 先在页面上选中文字，再在控制台执行
2
window.getSelection().toString();

1
document.querySelector('.article-content').textContent;

防御强度：低。 本质上只是在 copy 事件里做文章，绕过 copy 事件就完全失效。

透明遮罩层：看得见选不中#

在内容区上面盖一个全透明的 div，占满整个内容区域：

1
<div style="position: relative;">
2
  <div class="content">
3
    这里是要保护的内容...
4
  </div>
5
  <!-- 透明遮罩：拦截所有鼠标事件 -->
6
  <div style="
7
    position: absolute;
8
    top: 0; left: 0; width: 100%; height: 100%;
9
    z-index: 9999;
10
    background: transparent;
11
  "></div>
12
</div>

鼠标点击和拖拽事件都被遮罩层吃掉了，底下的文字选不中。部分在线阅读器和文档预览系统用的就是这个思路。

绕过方法：

1
/* DevTools Elements 面板找到遮罩 div，加一条 */
2
pointer-events: none;

1
// 控制台批量处理：所有绝对定位的高层元素设为不拦截事件
2
document.querySelectorAll('*').forEach(el => {
3
  const s = getComputedStyle(el);
4
  if (s.position === 'absolute' && s.zIndex > 100 && s.opacity !== '0') {
5
    el.style.pointerEvents = 'none';
6
  }
7
});

也可以直接从 DOM 取 textContent，和上一节一样。

防御强度：低。 遮罩层在 DOM 里清晰可见，删掉就没了。但对不看 DevTools 的用户来说是有效的视觉欺骗。

文字转图片 / Canvas 渲染：DOM 里根本没有文本#

前面四种方法有一个共同弱点：文字始终以文本形式存在于 DOM 中，用 textContent 就能取到。把文字渲染成图片可以从根本上消除这个入口。

服务端渲染成图片： 后端把文章内容渲染成一张张图片，前端用 <img> 展示。部分在线文档预览（Google Docs 的只读分享页、某些 PDF 在线查看器）就是这个思路。

前端 Canvas 绘制： 把文字画到 <canvas> 上，用户看到的是像素而不是文本节点：

1
const canvas = document.createElement('canvas');
2
canvas.width = 800;
3
canvas.height = 400;
4
const ctx = canvas.getContext('2d');
5
ctx.font = '16px sans-serif';
6
ctx.fillStyle = '#333';
7

8
const text = '这段文字无法通过 DOM 获取';
9
ctx.fillText(text, 20, 40);
10

11
document.body.appendChild(canvas);

Canvas 里的内容在 DOM 中只是一个 <canvas> 元素，textContent 返回空字符串。

绕过方法：

OCR（光学字符识别）。浏览器环境下可以直接用 Tesseract.js：

1
// npm install tesseract.js
2
import { createWorker } from 'tesseract.js';
3

4
async function ocrFromCanvas(canvas) {
5
  const worker = await createWorker('chi_sim'); // 中文简体
6
  const { data: { text } } = await worker.recognize(canvas);
7
  await worker.terminate();
8
  return text;
9
}
10

11
// 也可以先把 canvas 转成图片 URL
12
const dataUrl = canvas.toDataURL('image/png');

对于服务端渲染的图片，直接对 <img> 元素做 OCR，或者截图后用系统 OCR（macOS 的实况文本、Windows 的 PowerToys Text Extractor）。

防御强度：中。 第一次出现了不在 DOM 里直接可取的情况。但 OCR 技术成熟，中文识别准确率已经很高（Tesseract 对规范字体的识别率 > 95%）。代价是：图片体积远大于文本、不可被搜索引擎索引、无法被屏幕阅读器读取、不支持响应式排版。

无障碍问题

文字转图片会让使用屏幕阅读器的用户完全无法获取内容。如果你的站点需要满足 WCAG 标准，这个方案不可接受。即便加了 alt 文本，长篇内容的阅读体验也远不如真实文本。

DOM 碎片化 + CSS 视觉重排：复制出来是乱序#

这一招比较巧妙：文字以文本形式存在于 DOM 中，但 DOM 顺序和视觉顺序不一致。

假设要展示「前端安全」四个字，DOM 结构可能是：

1
<div class="protected">
2
  <span style="order: 3">安</span>
3
  <span style="order: 1">前</span>
4
  <span style="order: 4">全</span>
5
  <span style="order: 2">端</span>
6
</div>
7

8
<style>
9
.protected { display: flex; }
10
</style>

视觉上看到的是「前端安全」（flex order 控制排列顺序），但 textContent 取到的是 DOM 顺序：「安前全端」。

更激进的做法是用绝对定位把每个字符放到精确的像素坐标上，DOM 顺序完全随机打乱。有的实现甚至会插入不可见的干扰字符（font-size: 0 或 color: transparent），复制出来夹杂一堆乱码。

绕过方法：

核心思路：按视觉坐标还原真实顺序。

1
function extractByVisualOrder(container) {
2
  const spans = [...container.querySelectorAll('span')];
3
  // 按视觉位置排序：先按 top（行），再按 left（列）
4
  spans.sort((a, b) => {
5
    const ra = a.getBoundingClientRect();
6
    const rb = b.getBoundingClientRect();
7
    if (Math.abs(ra.top - rb.top) > 5) return ra.top - rb.top; // 不同行
8
    return ra.left - rb.left; // 同一行
9
  });
10
  return spans.map(s => s.textContent).join('');
11
}
12

13
const result = extractByVisualOrder(document.querySelector('.protected'));
14
console.log(result); // "前端安全"

getBoundingClientRect() 返回的是元素在屏幕上的实际渲染位置，和 DOM 顺序、CSS 排列方式无关。按坐标排序就能还原视觉顺序。

对于插入的不可见干扰字符，额外过滤一下：

1
spans.filter(s => {
2
  const style = getComputedStyle(s);
3
  return style.fontSize !== '0px'
4
    && style.display !== 'none'
5
    && style.visibility !== 'hidden'
6
    && style.opacity !== '0';
7
});

防御强度：中高。 需要写针对性的脚本才能提取，简单的 textContent 拿到的是乱序内容。但只要文字还在 DOM 里，就一定能通过坐标还原。

字体混淆：看到的字和底层编码不同#

这是目前防御强度最高的前端防复制手段。

原理：制作一个自定义字体文件（@font-face），把 Unicode 码位重新映射。比如字体里把 U+5B89（安）的位置画成「前」的字形，把 U+524D（前）的位置画成「端」的字形……HTML 里写的是一串看起来无意义的字符，但加载自定义字体后渲染出来是正确的文章。

1
@font-face {
2
  font-family: 'Obfuscated';
3
  src: url('/fonts/obfuscated.woff2') format('woff2');
4
}
5
.protected {
6
  font-family: 'Obfuscated', sans-serif;
7
}

1
<p class="protected">安前全端</p>
2
<!-- 视觉上显示的是完全不同的内容 -->
3
<!-- 复制粘贴到其他地方，因为没有这个字体，显示的是乱码 -->

起点中文网、某些付费文档平台用的就是这种方案（或其变体）。每次请求生成不同的映射表 + 不同的字体文件，连缓存都没法复用。

怎么确认一个站用了字体混淆

选中文字复制粘贴到记事本里。如果粘贴出来的内容和你看到的完全不同（乱码或不同字符），基本可以确认是字体混淆。另一个信号：查看 DevTools → Network 面板，如果有自定义字体文件（.woff2 / .woff）在加载，而且字体名不是常见的系统字体，嫌疑很大。

绕过方法：

需要逆向字体文件的映射关系。用 opentype.js 解析字体：

1
// npm install opentype.js
2
import opentype from 'opentype.js';
3

4
async function reverseFontMapping(fontUrl) {
5
  const response = await fetch(fontUrl);
6
  const buffer = await response.arrayBuffer();
7
  const font = opentype.parse(buffer);
8

9
  const mapping = {};
10
  // 遍历字体的 cmap 表，建立码位 → 字形的反向映射
11
  const glyphs = font.glyphs;
12
  for (let i = 0; i < glyphs.length; i++) {
13
    const glyph = glyphs.get(i);
14
    if (glyph.unicode) {
15
      // glyph.path 可以和标准字体做轮廓比对
16
      // 实际场景需要更复杂的字形匹配算法
17
      mapping[glyph.unicode] = glyph;
18
    }
19
  }
20
  return mapping;
21
}

实际操作比这复杂得多：需要把混淆字体里每个字形和标准字体做视觉比对（字形轮廓相似度），才能还原出真实映射。自动化工具存在，但不是开箱即用。

另一条路是截图 + OCR，和上一节一样。字体混淆再怎么混淆，屏幕上显示的像素是正确的。

防御强度：高。 DOM 里的文本和真实内容完全脱钩，复制出来是乱码，连 textContent 取到的都是错的。逆向字体需要专业知识，OCR 虽然通用但处理大量文本的成本不低。缺点是字体文件体积大（中文字体动辄几 MB）、每次请求生成新字体对服务端也有压力。

七种手段的防御纵深#

每一层都拦不住有耐心的攻击者，但每多一层就筛掉一批不愿意付出对应成本的人。

网页是怎么加载的：扩展工作在哪一层#

前面七种手段看起来是七个孤立的技巧，但把它们放回网页加载的完整流程里，每个手段卡住的位置不同，扩展能赢前三层的原因也很清晰。

一个实际实现：Enable Copy 浏览器扩展#

前面七节的绕过方法大多要开 DevTools 手动操作，每次遇到防复制页面都来一遍显然不现实。我把前三层的绕过逻辑打包成了一个浏览器扩展：

它对应处理文章里的前三层：

有个实现细节值得说一下：为什么用捕获阶段的 stopImmediatePropagation() 而不是简单地 removeEventListener？因为扩展拿不到页面脚本注册监听器时的函数引用，没法精确移除。但事件传播有顺序——捕获阶段先于冒泡阶段，window 又处于捕获链的最顶端。在 window 上注册捕获监听器，调 stopImmediatePropagation() 阻止事件继续传播，页面的监听器就收不到事件了。不需要知道页面绑了什么，直接在传播路径上截断。

document_start 的时机选择也关键：内容脚本在页面任何脚本执行之前注入，保证扩展的监听器先于页面注册。如果晚于页面脚本，页面注册在前的监听器会先收到事件，拦截就失效了。

第四层（透明遮罩）没有覆盖——遮罩层形态太多样，通用识别成本高，实际遇到的频率也低。第五层（图片/Canvas）和第七层（字体混淆）在原理上就无法通过 DOM 操作解决，README 里也明确写了这两个限制，需要配合 OCR。

仓库里附了一个 test-page.html，模拟了禁选择、禁右键、复制劫持、禁快捷键、CSS 限制五种场景，装完扩展可以直接验证效果。

实战中怎么组合：成本取舍#

没有单一手段能做到绝对防复制，但多层组合可以把成本拉到大部分人不愿意付的程度。

普通博客 / 内容站： CSS user-select + JS 事件拦截 + 剪贴板追加来源，三层叠加已经能挡住 95% 的随手复制。实现成本低，用户体验影响可控。

付费内容平台： 在上面的基础上加 DOM 碎片化或字体混淆。两者都能保持视觉正常，但复制出来是乱码。字体混淆更强但成本更高，需要服务端配合生成字体。

在线考试 / 法律文书： 文字转图片 + Canvas 渲染是最常见的方案。配合禁用 DevTools 的检测（检测窗口尺寸变化、debugger 断点），进一步提高提取难度。但要注意无障碍合规问题。

底线

不管你选哪种方案，别忘了用户体验。禁右键会影响翻译插件和辅助功能，文字转图片会让屏幕阅读器用户完全失去内容，字体混淆会导致浏览器内搜索失效。防复制的每一层都在消耗用户体验预算——加到什么程度，取决于你的内容值多少钱。

如果用户能看到，用户就能复制。区别只在于成本。