本文详解为何从数据库读取的 WYSIWYG 生成 HTML 在 EJS 页面中显示为纯文本，以及如何通过 语法正确渲染为可执行的 HTML 结构，同时强调 XSS 防护关键实践。
本文详解为何从数据库读取的 wysiwyg 生成 html 在 ejs 页面中显示为纯文本，以及如何通过 `` 语法正确渲染为可执行的 html 结构，同时强调 xss 防护关键实践。
在使用 Froala、TinyMCE 或其他 WYSIWYG 编辑器构建博客系统时，前端编辑并提交的富文本内容（如 <p><strong>Hello</strong></p>）通常以原始 HTML 字符串形式存入数据库。但在 EJS 模板中直接使用 输出该变量时，EJS 默认会对特殊字符进行 HTML 转义（例如将 变为 <code>），导致浏览器将其作为纯文本而非可解析的 DOM 渲染——这正是你看到“源码被显示出来”而非格式化内容的根本原因。
✅ 正确做法：使用 未转义输出语法
EJS 提供 用于输出未经 HTML 编码的原始字符串，使其能被浏览器解析为真实 DOM 元素：
<!-- ✅ 正确：服务端直接注入 HTML 到页面 --> <div class="blog-content"> <%- post %> </div>
⚠️ 注意：此方式等同于 innerHTML = post，绝不适用于未经清洗的用户输入。若 post 直接来自前端表单且未做服务端校验，攻击者可注入恶意脚本（如 <script>alert('xss')</script>），造成严重安全风险。
? 安全最佳实践（必须执行）：
-
服务端 HTML 净化：在保存或渲染前，使用可信库（如
DOMPurify或 Node.js 的sanitize-html）过滤掉危险标签（<script></script>、<iframe></iframe>、onerror等事件属性）； -
仅对可信内容使用
：例如管理员后台发布的文章，且已通过净化流程； -
禁用客户端直接拼接：避免在
<script></script>中用innerHTML += ""—— 这不仅冗余，还绕过 EJS 渲染上下文，易引发双重编码或执行时机问题（如 DOM 尚未就绪）；
? 补充说明：
立即学习“前端免费学习笔记（深入）”；
-
→ 转义输出（安全但显示为文本） -
→ 原始输出（高效但需确保内容可信） - 若需动态加载（如 AJAX 获取后插入），请在客户端使用
DOMPurify.sanitize()处理后再赋值给element.innerHTML。
总结：WYSIWYG 内容渲染失败不是编辑器或数据库的问题，而是模板引擎的安全默认行为。启用 是解法，而配合 HTML 净化才是生产环境的完整答案。
