每隔一段时间总有人问：能不能让用户没法复制我网站上的内容？
技术上的回答就两个字——不能。浏览器能渲染出来的文字，用户迟早都能拿得走。Ctrl+C、打开 DevTools 把 CSS 改回去、截图扔进 OCR 工具、写一段 Puppeteer 脚本拉一遍、甚至用屏幕阅读器朗读再录回来……每道看似坚固的前端防线，专业用户绕过去的成本也就几秒到几个小时不等。
但架不住加防护的需求从来没断过。问题出在哪儿呢？出钱的人和受益的人根本不是同一拨。防护的成本几乎尽数压在了正常用户身上，而盗版者花一个下午换套工具链就畅通无阻了。这笔账算下来，输的只能是你自己。
四种反爬手段，没一个对用户友好
前端能用的反爬招式基本就这四件，每一件都有自己的账本。
第一件：user-select: none。 最低成本的做法，两行 CSS 让用户选不中文字。代价是用户丢掉了所有依赖“选中”才能用的功能——iOS Safari 和 Chrome Mobile 上的“选中即译”直接瘫痪，代码块没法选中再粘贴，读者想在文章里引用一句话贴到飞书都办不到。而这道墙薄到什么程度呢？控制台里把 user-select 改成 text 就绕过去了。MDN 自己也注明了，user-select: none 并不影响 copy 事件的触发，它只防住了鼠标划选，对键盘操作和 DevTools 完全失效。被拦住的，恰好是那些不会开控制台的普通用户。
第二件：拦截 contextmenu 和 copy 事件。 event.preventDefault() 一上，右键菜单和 Ctrl+C 统统干掉。很多付费内容平台至今还在用这一招。代价是右键菜单里的“翻译”“朗读”“搜索”“打开链接”全被端掉了，用户想翻译一段英文都得换个工具站。可话说回来，F12、Ctrl+Shift+I、各家浏览器菜单里的“开发者工具”走的是另一条路，压根不依赖 contextmenu，所以“禁止右键就能防爬”这个想法从一开始就站不住脚。
第三件：Canvas 渲染。 DOM 里不存文本，全文扔进 <canvas> 里画出来。DOM 层面确实干净——页面源码里除了一个 canvas 标签什么都看不见，普通爬虫拿到的 HTML 就等于一块白板。
账本从这儿开始变得非常重。Google Chrome 团队的现代 Web 文档写得很清楚：Canvas 内容不进屏幕阅读器、不进搜索引擎收录、不进翻译、不进页面内查找、不进打印。等于一口气把这五项可用性全砍了。响应式又是另一摊事儿——字号、行高、换行、缩放全得靠手动算坐标，原来改几行 CSS 就能搞定的事，现在得重调画布绘制逻辑。
而 OCR 那边这两年进展飞快。Tesseract.js 搭上中文语言包在浏览器里跑一轮，Canvas 渲染出来的字基本能还原九成；GitHub 上甚至有专门针对中文字体混淆做反推的开源项目，把渲染后的字形和参考字体做比对，准确率能干到 99.96%。安全/渗透/逆向 这个领域里，专门搞爬的人不会因为你换了 Canvas 就放弃，他们换个工具链接着走就是了。
第四件：字体混淆。 HTML 里存一堆符号乱码，字体 cmap 把每个乱码映射到一个能正常显示的字形。用户看到的是“你好世界”，复制出来却是一堆 𘞱𘞯𘞴𘞲𘞱𘞭。这算是目前最强的纯前端反爬手段了，但中文字库动辄几万个字形，混淆后的字体包体积随随便便几十兆，首屏加载时间直接崩掉。再加上每个字都在 Unicode 私有区 PUA（U+E000-F8FF）分一个码位，这就相当于替爬取方多写了一本字表脚注。结论是“能延缓，但不能杜绝”——专业爬取方可以用截图 OCR 回补字形，也可以直接 dump 操作系统渲染后的帧缓存。
国内网文平台折腾了十年，也没赢
这事儿在网文圈里是最直观的教训。
起点、晋江、刺猬猫，三家加起来用户过亿。从 2010 年代中期开始就在反爬上层层加码。晋江最早用 CSS 禁选，觉得太弱，换成 Canvas 渲染全文，发现 SEO 和可访问性全炸了，又折回来搞字体混淆。起点的路子更狠一些：正文页默认走前端渲染，CI 打包时对每个章节自动生成一份混淆字体，还加了定时刷新 token 和章节切分，防止整本书被一次性下载。
结果呢？盗版照旧。你去任意一个盗版转站看一眼，当天更新的章节当天就挂出来了。对方根本不靠破解前端防护，直接用浏览器自动化加 OCR 流水线，全本从头到尾扔进识别引擎，第一章到最后一章，几小时搞定。反爬的作用，不过是从“发出来三分钟就有盗版”变成了“发出来三小时后就有盗版”。这件事后来被开源仓库反向验证过——GitHub 上的 novel-downloader 项目里有完整的 PUA 字体反推实现，作者写下的不是“我们破解了反爬”，而是 “反爬就是按这个套路绕”。
但正常读者的体验被实实在在地牺牲掉了。字体包太大导致移动端白屏十几秒，选中即译和屏幕朗读全部失效，二维码引用和长按查词在大部分 App 里也跑不起来，视力障碍读者直接被踢出服务范围。这条路付出的代价不是抽象数字——是晋江 App 因为 Canvas 渲染太重、低端安卓机打开一本书要等八秒那一类具体投诉，最终演变成应用商店评分直接掉一整颗星。
哪些场景才需要真正做防护？
上面说的核心意思就一条：别把反爬当成纯前端问题来解。真到了需要保护的时候，有几个方向比在 DOM 上折腾更有用。
第一，在商业模型上设门槛，别在 DOM 上较劲。 付费墙提前三章预览，看全书需要登录。这不是前端反爬，这是权限控制。两者区别在哪？前者不影响付费用户的体验，后者把所有用户一股脑儿拉进了代价账本里。
第二，要做就做全套。 如果确实需要前端防护——比如法律合同、审计底稿、金融底数这类草稿级内容——Canvas 渲染仍然是可以考虑的方案。但上线前必须同时做三件事：给搜索引擎配好 SSR 版本的 meta 段落；给 Canvas 容器加上 aria-label 和 fallback 纯文本以供屏幕阅读器正常消费；提前告诉用户当前页面出于合规原因限制了文本选择。三件事一起做，反爬的成本至少有一部分能在技术层被消化掉，不至于全部转嫁给用户。
第三，用剪贴板归属代替粗暴封禁。 你是内容创作者，最怕的其实不是别人复制，而是复制之后不署名。与其堵住复制这条路，不如在触发复制时告诉对方“这段内容来自哪个站”。CodePen、Medium、知乎都是这个套路——监听 copy 事件之后在原文本末尾自动追加上出处信息。用户体验几乎没有受损，而归属感比你加两行 CSS 强一万倍。
所以，别做了
别加 user-select: none，别拦右键菜单，别往 Canvas 里塞课程大纲。
如果你老板坚持要“防复制”，那就发给他一句话：你是担心内容被盗，还是担心用户流失率不够高？
在 云栈社区 里，不少做独立开发的朋友聊起这个话题时都有一个共识：与其把精力耗在跟爬虫军备竞赛上，不如把内容本身和用户体验打磨好——那才是真正算得回来的账。
#前端反爬 #内容保护 #SEO #HTML
发表于 5 小时前
|
查看: 3|
回复: 0
