oncopy属性本身不能阻止复制，必须配合event.preventDefault()才生效；它仅支持单个处理器、在现代框架中易失效且无法访问完整ClipboardEvent，而addEventListener可多次绑定并支持完整API。
oncopy 属性本身不能阻止复制，只提供一个监听入口；真正起效必须配合 event.preventDefault()，否则只是“旁观”——这点很多人在写完 oncopy="return false" 后发现没用，就是因为浏览器已不认这种老式写法。
oncopy 属性和 addEventListener('copy') 的实际区别
HTML 中的 oncopy 属性（如 <input oncopy="handleCopy()">）本质是绑定一个内联事件处理器，它和 addEventListener('copy', ...) 都能触发，但有关键差异：
-
oncopy属性只能绑定一个处理函数，后赋值会覆盖前一个；addEventListener可多次调用，互不干扰 -
oncopy在现代框架（如 React）中常被忽略或自动剥离，尤其在 SSR 或 JSX 渲染时失效 -
oncopy无法访问原生ClipboardEvent的完整能力（比如读取e.clipboardData.items），而addEventListener可以 - 旧版 IE 支持
oncopy属性但不支持addEventListener，但现在基本不用考虑
为什么写了 oncopy 却拦不住剪贴板劫持？
攻击者常用 document.addEventListener('copy', e => { e.clipboardData.setData('text/plain', 'rm -rf /'); e.preventDefault(); }) 劫持内容。你光在某个 <input> 上写 oncopy="return false" 完全无效，原因如下：
- 劫持脚本监听的是
document级别的copy事件，不是某个元素的属性 -
oncopy="return false"不会调用preventDefault()，现代浏览器只当普通返回，不中断默认行为 - 即使你在目标元素上绑了
oncopy，事件冒泡仍会让 document 级监听器执行并覆盖内容 - 部分浏览器（如 Safari）对非用户手势触发的
setData直接静默丢弃，但劫持脚本往往卡在用户真实操作瞬间，刚好满足条件
如何让 oncopy 属性真正生效（仅限简单场景）
如果你坚持用 oncopy 属性（例如快速原型、静态页、CMS 模板限制），必须满足三个硬性条件：
立即学习“前端免费学习笔记（深入）”；
- 属性值里必须显式调用
e.preventDefault()，不能只写return false—— 正确写法：oncopy="event.preventDefault();" - 目标元素需有焦点或可交互（
input、textarea、contenteditable="true"的div），否则事件不触发 - 不能依赖
e.clipboardData做读取或写入：Safari 和某些 iframe 下该对象为null，且需先判空再用 - 若想改写复制内容，必须同时满足：用户手势上下文 +
preventDefault()+ MIME 类型为'text/plain'或'text/html'
示例（仅适用于纯文本输入框）：
<input type="text" value="敏感内容" oncopy="event.preventDefault(); event.clipboardData.setData('text/plain', '[已脱敏]');">
真正防劫持的关键不在 oncopy，而在上下文与权限
剪贴板 API 的安全模型决定了：任何页面都不能无条件读写剪贴板。有效防护必须围绕浏览器策略展开：
- 读取剪贴板（如粘贴校验）必须在用户手势后立即调用
navigator.clipboard.readText()，否则 Firefox 拒绝、Chrome 报NotAllowedError - HTTPS 是硬门槛：HTTP 页面下
navigator.clipboard为undefined，onpaste中的e.clipboardData也可能被清空 - 不要试图“全局禁用 copy”，这既不可靠（右键菜单、开发者工具、截图都绕过），又损害可访问性；应聚焦具体字段（如密码框）做精准拦截
- 最易被忽略的一点：监听
copy事件时，如果 handler 抛错，整个事件链中断，劫持脚本反而得逞 —— 所有剪贴板相关逻辑务必包try/catch
