评论中出现 onerror 本质是 xss 风险，必须服务端白名单清洗（如 dompurify），禁用所有 on* 属性及危险标签；前端仅作补救，禁用 innerhtml，优先用 textcontent 渲染。
onerror 在用户评论内容中出现，本质是 XSS 风险点，不是“怎么让它工作”，而是“必须阻止它执行”——任何允许用户输入直接渲染 onerror 的行为，都等于开放了前端执行入口。
为什么评论里写 onerror 不能防循环而要直接过滤
评论内容属于不可信输入，onerror 属性在这里不是降级手段，而是可被利用的 JS 执行通道。浏览器一旦解析到 <img src="x" onerror="alert(1)">，就会尝试执行，不管有没有循环风险。所谓“防无限循环”是针对开发者可控资源兜底的逻辑，对用户输入不适用。
常见错误现象：
- 后台未清洗 HTML，前端用
innerHTML直接插入评论 →onerror立即触发 - 用正则替换
onerror却漏掉大小写、空格绕过（如onError、on error） - 只删属性但保留
<img>标签，仍可能被构造为其他攻击载体（如src="javascript:..."）
评论内容中遇到 onerror 应该怎么做
服务端必须做白名单式 HTML 清洗，而不是简单字符串替换。推荐方案：
- 使用成熟库（如 DOMPurify）在服务端或客户端清洗：
DOMPurify.sanitize(userComment, { ALLOWED_TAGS: ['b', 'i', 'em', 'strong'], ALLOWED_ATTR: [] }) - 若用正则，至少匹配所有事件处理器：
/\bon\w+\s*=\s*["']?[^"']*["']?/gi，并全局替换为空 - 禁用所有内联 JS：直接移除
onerror、onclick、onload等所有以on开头的属性 - 禁止
<script></script>、<iframe></iframe>、<object></object>、<embed></embed>等标签，图片仅允许src且需校验协议（只允http:、https:、data:）
onerror 出现在评论里时，前端还能补救吗
能，但只是最后一道防线，不能替代服务端清洗：
- 不要用
innerHTML插入评论，改用textContent或innerText显示纯文本 - 若必须支持有限 HTML（如加粗、链接），用
createTextNode+createElement逐节点构建，跳过所有含事件属性的元素 - 插入后立即扫描 DOM：
commentEl.querySelectorAll('[onerror], [onclick], [onload]')，对匹配节点执行removeAttribute('onerror')并重置src为占位图（如data:image/svg+xml;base64,...） - 注意：Safari 对动态移除
onerror后是否重新触发有兼容差异，所以优先不渲染它
真正复杂的是混合场景：用户评论里既有正常图片 URL，又混着恶意 onerror。这时候靠“防循环”已经晚了，重点得落在清洗时机和粒度上——服务端入库前清洗一次，CDN 缓存前再校验一次，前端渲染前做最后一次防御性剥离。路径越靠前，风险越小。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
