1. 项目概述当图表库成为安全短板在开发现代Web应用时我们常常会引入各种第三方库来提升效率和体验Mermaid.js就是这样一个能将文本描述转换为精美图表的利器。它让开发者用类似Markdown的语法就能画出流程图、时序图、类图极大地简化了图表绘制工作。然而一个容易被忽视的真相是任何能够解析并渲染用户输入内容的库都可能成为一个潜在的攻击入口。Mermaid.js也不例外它默认的渲染机制如果不加任何防护就可能成为跨站脚本攻击的温床。想象一下这个场景你的应用有一个“项目协作”功能允许团队成员在任务描述或文档中插入Mermaid代码块来绘制项目流程图。这听起来很酷对吧但如果攻击者在流程图描述文本中精心嵌入一段JavaScript代码比如一个窃取用户登录Cookie的脚本而你的Mermaid渲染器又原封不动地执行了它那么所有查看这个“流程图”的用户都将中招。攻击者甚至不需要直接攻击你的服务器他只需要在用户可输入的地方“投毒”即可。这就是XSS攻击的典型路径而Mermaid.js的默认行为恰恰为这种攻击敞开了大门。我最初意识到这个问题是在一次内部安全审计中。我们一个看似“只读”的数据可视化大屏因为集成了用户可配置的Mermaid图表被安全工具标出了一个中危漏洞。这让我警醒我们往往对来自数据库、API接口的数据充满警惕会做各种转义和过滤却容易对这类“前端渲染库”掉以轻心认为它们只是“画图工具”。但实际上Mermaid.js在解析graph TD这类文本时内部会构建DOM节点如果文本中混入了script或利用SVG事件属性如onload的恶意代码它就有可能被执行。这个项目就是基于多次实战踩坑和修复经验整理出的一份针对Mermaid.js的防XSS配置指南。无论你是前端开发者、全栈工程师还是项目负责人只要你的产品中用到了Mermaid这份指南都能帮你堵上这个可能被忽略的安全漏洞。2. Mermaid.js的XSS风险根源与攻击向量分析要有效防御必须先理解攻击是如何发生的。Mermaid.js的XSS风险并非来自其核心的图形布局算法而是源于其将文本转换为图形这一过程本身。这个过程可以简化为输入文本 - 解析为抽象语法树 - 转换为SVG/HTML DOM元素 - 插入页面。风险就潜伏在“转换”和“插入”这两个环节。2.1 默认渲染机制的安全盲区Mermaid.js默认的mermaid.init或mermaid.run函数其目标是尽可能忠实地将用户定义的文本呈现为图形。为了实现丰富的表现力Mermaid支持在特定上下文中使用一些类HTML的语法。例如在节点文本中你可以使用br换行或者使用b加粗。为了支持这些功能Mermaid在内部可能需要使用innerHTML或类似的机制来设置SVG文本元素的内容。这里就是第一个危险点如果用户输入是scriptalert(xss)/script而库没有对输入进行充分的净化和转义这段脚本就可能通过innerHTML被注入并执行。更隐蔽的攻击向量在于SVG本身。SVG是一种XML格式它支持事件处理属性比如onload、onmouseover、onclick。攻击者可以构造这样的Mermaid代码graph TD A[“正常节点”] -- B{“svg/onloadalert(‘XSS’)”}当Mermaid尝试将这个{“svg/onloadalert(‘XSS’)”}作为节点内容渲染时如果库直接将其作为SVG元素的一部分进行解析那么onload事件就可能被触发。即使内容被放在text标签内如果未做转义它仍然可能被浏览器解析为可执行的属性。2.2 实战中的攻击场景模拟让我们看几个更贴近真实场景的例子存储型XSS最危险一个在线文档编辑器类似Notion允许用户保存包含Mermaid代码块的文章。攻击者发布了一篇包含恶意Mermaid代码的“技术分享”。所有后来阅读这篇文章的用户在其浏览器渲染该图表时恶意脚本都会执行。脚本可以悄无声息地盗取用户的登录凭证、会话Cookie甚至以用户身份执行操作。反射型XSS一个项目管理系统在搜索功能中将搜索关键词如“用户流程图”动态生成一个预览图表。如果搜索接口未过滤输入攻击者可以构造一个包含恶意代码的搜索词生成一个链接发送给受害者。受害者点击链接后其浏览器会执行攻击者预设的脚本。基于DOM的XSS一个单页面应用使用前端路由从URL的hash片段中读取图表定义并渲染。攻击者可以构造一个特殊的URL其中hash片段包含了恶意Mermaid代码。当用户访问这个URL时前端脚本直接从URL中取出内容交给Mermaid渲染导致攻击发生完全绕过了服务器。注意不要以为将Mermaid渲染放在iframe沙箱中就绝对安全。iframe sandbox属性确实能提供重要隔离但如果沙箱配置不当例如允许了script执行风险依然存在。最根本的解决方案还是在数据交给Mermaid之前就进行清洗。2.3 为什么简单的HTML转义不够你可能会想那我先用一个库比如DOMPurify把用户输入的整个Mermaid代码文本过滤一遍不就行了吗事情没那么简单。因为Mermaid语法本身包含了一些特殊字符和结构过度的转义会导致图表无法正常渲染。例如Mermaid流程图的基本语法graph TD; A--B;。如果你将字符转义为gt;Mermaid解析器就无法识别这是箭头图表会解析失败。同样节点标识符中的括号()、定义子图的花括号{}都是语法的一部分不能盲目转义。因此安全的挑战在于我们需要区分“图表定义语法”和“图表中的文本内容”。我们需要允许Mermaid语法符号正常通过但同时要确保这些语法符号中夹杂的、最终会成为DOM节点内容或属性的部分是干净无害的。这需要一个更精细的策略而不是一刀切的转义。3. 构建防御体系从配置到渲染的全链路安全方案防御Mermaid.js的XSS攻击不能依赖单一方法而需要一套组合拳在数据流转的不同阶段层层设防。这套体系的核心思想是默认不信任任何用户输入在最终渲染前强制执行内容净化。3.1 核心安全配置启用securityLevel与自定义secureModeMermaid.js从某个版本开始引入了一个至关重要的配置项securityLevel。这是你抵御XSS的第一道也是最重要的一道防线。// 正确的全局配置方式 mermaid.initialize({ startOnLoad: true, securityLevel: strict, // 或 loose, antiscript theme: default });securityLevel有三个可选值你需要深刻理解它们的区别strict(最安全)这是默认的推荐设置。在此模式下Mermaid会完全禁用任何可能执行脚本的功能。它会移除或转义所有HTML标签。即使你在节点文本中写了b重要/b它也不会被加粗而是会被当作纯文本“b重要/b”显示。禁用所有事件属性如onclick、onload。本质上它确保图表输出是纯静态的SVG/HTML没有任何交互性通过脚本实现的交互。对于绝大多数仅用于展示的图表场景请务必使用此模式。loose(宽松)此模式会恢复对文本内容中简单HTML标签如b,i,br的支持但理论上仍会过滤脚本和事件属性。然而依赖此模式过滤事件属性存在风险因为过滤规则的实现可能不完美或随版本变化。除非你有强烈的文本格式化需求且能接受潜在风险否则不建议使用。antiscript(反脚本)这是一个历史遗留的中间选项旨在阻止脚本但允许HTML。它的行为可能不如strict模式彻底和可预测。在新项目中应优先选择strict模式。仅仅设置securityLevel: ‘strict’就够了吗对于大多数情况是的。但如果你需要允许一些安全的HTML比如来自可信后端的富文本或者你想拥有绝对的控制权可以结合自定义secureMode。secureMode是一个布尔值。当secureMode: true时Mermaid会信任一个名为secureFilters的函数数组。你可以自定义这些过滤器来定义什么样的输入是“安全”的。mermaid.initialize({ securityLevel: strict, secureMode: true, // 这是一个示例过滤器在实际中使用需要更严谨的实现 secureFilters: [ (input) { // 这里可以调用像DOMPurify这样的专业库来净化输入 // 示例仅允许极少数安全的标签和属性 const allowedTags [br, b, i, u]; const regex new RegExp((?!/?(${allowedTags.join(‘|’)})\\b)[^]*, ‘gi’); return input.replace(regex, ‘’); // 移除非允许的标签 }] });实操心得在实践中我强烈建议不要轻易去自定义secureFilters除非你有非常特殊的需求和深厚的安全知识。维护一个完美的HTML过滤器极其困难很容易产生绕过漏洞。securityLevel: ‘strict’是经过Mermaid团队测试的、最可靠的默认安全方案。把它当作一条铁律展示型图表一律strict。3.2 输入净化层在数据抵达Mermaid之前配置Mermaid是最后一道防线更积极的防御是在数据到达Mermaid渲染函数之前就进行清洗和验证。这一层防御在你的后端服务和前端数据处理器中。后端Node.js/Python/Java等职责语法验证在服务器端接收存储Mermaid代码时可以尝试进行一次基本的语法验证。例如使用一个简单的正则表达式检查输入是否以合法的Mermaid图表类型如graph,pie,sequenceDiagram开头。这可以拦截明显非法的、胡乱拼接的输入。长度限制对Mermaid代码块的长度进行合理限制防止超长字符串导致潜在的解析器溢出问题虽然Mermaid本身可能不易受此影响但这是一个好习惯。标记安全来源对于完全由系统生成、用户不可修改的图表如自动化报告可以在数据中打上一个trusted: true的标记。前端看到这个标记可以考虑使用稍宽松的配置如允许一些HTML格式化。对于用户输入的内容则永远标记为untrusted。前端数据处理职责隔离渲染上下文永远不要将未经处理的用户输入字符串直接拼接进HTML模板然后指望Mermaid初始化时去解析整个DOM。这极易导致注入。正确做法是将Mermaid代码以文本形式存储在某个变量或DOM节点的textContent/>// 错误做法直接将不可信字符串插入innerHTML document.getElementById(‘chartContainer’).innerHTML div class“mermaid”${userInputFromAPI}/div; mermaid.init(); // 正确做法使用文本节点或安全的文本设置方法 const codeEl document.createElement(‘pre’); codeEl.className ‘mermaid’; codeEl.textContent userInputFromAPI; // textContent会自动转义 document.getElementById(‘chartContainer’).appendChild(codeEl); mermaid.init(undefined, document.querySelectorAll(‘.mermaid’));3.3 渲染隔离层沙箱环境的使用对于安全要求极高的场景例如渲染完全不可信第三方提供的图表可以考虑终极隔离方案Web Worker或iframe沙箱。iframe沙箱方案你可以创建一个完全独立的iframe来承载Mermaid的渲染。创建一个具有严格沙箱属性的iframeiframe sandbox“allow-same-origin” src“about:blank”/iframe。这里只允许same-origin禁用了脚本、表单、API等。通过postMessage将需要渲染的Mermaid代码从主页面发送到iframe。在iframe内部一个纯净的页面加载Mermaid库securityLevel: ‘strict’接收代码并渲染。将渲染得到的SVG字符串再通过postMessage传回主页面。主页面将这段静态的SVG字符串插入到DOM中。!-- 主页面 -- iframe id“mermaidSandbox” sandbox“allow-same-origin” style“display: none;”/iframe script const sandbox document.getElementById(‘mermaidSandbox’).contentWindow; const untrustedCode graph TD; A[用户输入]--B[可能有害]; // 发送代码到沙箱 sandbox.postMessage({ action: ‘render’, code: untrustedCode }, ‘*’); // 监听沙箱返回的安全SVG window.addEventListener(‘message’, (event) { if (event.data.action ‘rendered’) { document.getElementById(‘output’).innerHTML event.data.svg; } }); /script !-- 沙箱页面 (mermaid-sandbox.html) -- script src“https://cdn.jsdelivr.net/npm/mermaid10/dist/mermaid.min.js”/script script mermaid.initialize({ securityLevel: ‘strict’ }); window.addEventListener(‘message’, async (event) { if (event.data.action ‘render’) { const { svg } await mermaid.render(‘sandbox-graph’, event.data.code); // 将渲染结果传回主页面 window.parent.postMessage({ action: ‘rendered’, svg: svg }, ‘*’); } }); /script这个方案的优点是实现了真正的环境隔离即使Mermaid库本身存在未知的0day漏洞其影响范围也被限制在iframe内无法访问主页面的DOM、Cookie或LocalStorage。缺点是实现复杂且有跨域通信开销。注意事项iframe沙箱的allow-same-origin是双刃剑。如果沙箱页面和主页面同源它就能访问同源的存储。如果你要渲染的代码绝对不可信可以考虑使用一个独立的、无意义的子域名来托管沙箱页面实现真正的原点隔离。4. 分场景实战配置与代码示例理解了理论框架后我们针对几种最常见的开发场景给出具体的配置和代码示例。请根据你的项目情况对号入座。4.1 场景一静态站点生成器如VuePress, Docusaurus, Hexo在这些场景中Mermaid图表通常以Markdown代码块的形式编写并在构建时或客户端渲染。安全策略在构建时/初始化时强制设置securityLevel: ‘strict’。VuePress (v2): 在.vuepress/client.ts或相应的客户端配置文件中import { defineClientConfig } from ‘vuepress/client’ import mermaid from ‘mermaid’ export default defineClientConfig({ setup() { // 在客户端挂载时初始化Mermaid mermaid.initialize({ startOnLoad: true, securityLevel: ‘strict’, theme: ‘dark’ // 按需选择主题 }) }, })Docusaurus: 在docusaurus.config.js中配置主题或自定义脚本module.exports { themes: [‘docusaurus/theme-classic’], scripts: [ { src: ‘https://cdn.jsdelivr.net/npm/mermaid10/dist/mermaid.min.js’, async: false, }, { // 内联脚本在Mermaid加载后立即初始化 innerHTML: if (window.mermaid) { mermaid.initialize({ securityLevel: ‘strict’ }); } , }, ], };Hexo (配合hexo-filter-mermaid)在Hexo的全局配置文件_config.yml中找到mermaid插件配置部分确保安全设置被传递。通常插件会提供配置选项查阅插件文档设置securityLevel: ‘strict’。关键点静态站点通常内容相对可信多为作者本人编写但考虑到可能有第三方投稿或评论嵌入图表坚持strict模式是最省心、最安全的选择。4.2 场景二动态Web应用如React, Vue, Angular在单页面应用中图表数据可能来自用户输入、API接口或数据库动态性更强风险更高。安全策略组件化封装 严格的Props验证 安全的渲染生命周期。以React为例我们创建一个安全的MermaidChart组件import React, { useRef, useEffect } from ‘react’; import mermaid from ‘mermaid’; // 初始化Mermaid仅执行一次 mermaid.initialize({ startOnLoad: false, // 我们手动控制渲染 securityLevel: ‘strict’, }); const MermaidChart ({ chartCode, className ‘’ }) { const containerRef useRef(null); const mermaidIdRef useRef(mermaid-${Math.random().toString(36).substr(2, 9)}); useEffect(() { // 清理容器防止重复渲染 if (containerRef.current) { containerRef.current.innerHTML ‘’; } // 输入验证非字符串或空字符串直接返回 if (typeof chartCode ! ‘string’ || !chartCode.trim()) { containerRef.current.textContent ‘(无图表代码)’; return; } // 可选额外的输入净化例如移除非常规字符长度限制 const sanitizedCode chartCode.slice(0, 5000); // 简单长度限制 // 使用Mermaid的render API进行异步渲染 const renderChart async () { try { const { svg } await mermaid.render(mermaidIdRef.current, sanitizedCode); // 使用dangerouslySetInnerHTML是必要的因为渲染结果是SVG字符串。 // 但由于securityLevel是‘strict’且输入已经过初步处理风险可控。 // 更安全的方式是使用ref插入纯文本节点但mermaid.render直接返回SVG字符串。 // 这里信任Mermaid在strict模式下的输出。 containerRef.current.innerHTML svg; } catch (error) { console.error(‘Mermaid渲染失败:’, error); containerRef.current.textContent 图表渲染错误: ${error.message}; } }; renderChart(); }, [chartCode]); // 当chartCode变化时重新渲染 return div ref{containerRef} className{mermaid-chart ${className}} /; }; export default MermaidChart;使用组件import MermaidChart from ‘./MermaidChart’; function App() { const [userInput, setUserInput] useState(‘graph TD; A--B’); const chartDataFromAPI ‘pie title 项目时间分配\n “设计” : 30\n “开发” : 50\n “测试” : 20’; return ( div textarea value{userInput} onChange{(e) setUserInput(e.target.value)} / {/* 渲染用户实时输入有一定风险但受strict模式保护 */} MermaidChart chartCode{userInput} / {/* 渲染来自API的数据 */} MermaidChart chartCode{chartDataFromAPI} / /div ); }Vue 3 Composition API 示例template div ref“chartContainer” class“mermaid-container”/div /template script setup import { ref, watch, onMounted, onUnmounted } from ‘vue’; import mermaid from ‘mermaid’; mermaid.initialize({ securityLevel: ‘strict’, startOnLoad: false }); const props defineProps({ code: { type: String, required: true, default: ‘’, }, }); const chartContainer ref(null); const mermaidId mermaid-${Math.random().toString(36).slice(2)}; const renderChart async () { if (!chartContainer.value || !props.code.trim()) return; chartContainer.value.innerHTML ‘’; try { const { svg } await mermaid.render(mermaidId, props.code); chartContainer.value.innerHTML svg; } catch (err) { chartContainer.value.textContent 渲染失败: ${err.message}; } }; watch(() props.code, renderChart, { immediate: true }); /script关键点将Mermaid初始化放在模块层面或单例中避免重复初始化。在组件副作用useEffect,watch中执行渲染并妥善管理清理重置innerHTML防止内存泄漏和内容残留。对输入进行基础验证类型、非空并可增加业务层面的长度、关键字限制。使用async/await处理mermaid.render它返回Promise更好的错误处理。错误处理必不可少。捕获渲染异常并给用户友好提示避免未处理的错误导致应用崩溃或暴露内部信息。4.3 场景三Node.js服务器端渲染有时我们需要在服务器端SSR或构建时Static Site Generation将Mermaid图表渲染成图片或SVG文件再发送给客户端。这本身是一种非常安全的方式因为客户端只接收静态图片。安全策略在隔离的Node.js进程中执行渲染并严格限制渲染参数。使用mermaid-cli或puppeteer在服务器端渲染# 使用mermaid-cli (官方命令行工具) # 安装npm install -g mermaid-js/mermaid-cli mmdc -i input.mmd -o output.svg -t dark -b transparent -s 2在Node.js脚本中调用const { exec } require(‘child_process’); const fs require(‘fs’); const path require(‘path’); const { v4: uuidv4 } require(‘uuid’); async function renderMermaidToSVG(mermaidCode, theme ‘default’) { const tempId uuidv4(); const inputPath path.join(__dirname, ‘temp’, ${tempId}.mmd); const outputPath path.join(__dirname, ‘temp’, ${tempId}.svg); // 确保临时目录存在 const tempDir path.join(__dirname, ‘temp’); if (!fs.existsSync(tempDir)) { fs.mkdirSync(tempDir, { recursive: true }); } // 1. 将用户代码写入临时文件 fs.writeFileSync(inputPath, mermaidCode); return new Promise((resolve, reject) { // 2. 调用mermaid-cli进行渲染 // 注意这里通过配置文件或命令行参数传递securityLevel const command mmdc -i ${inputPath} -o ${outputPath} -t ${theme} -c config.json; exec(command, (error, stdout, stderr) { // 3. 清理临时输入文件 try { fs.unlinkSync(inputPath); } catch (e) {} if (error) { // 清理可能生成的部分输出文件 try { fs.unlinkSync(outputPath); } catch (e) {} reject(new Error(渲染失败: ${stderr || error.message})); return; } // 4. 读取渲染好的SVG文件 fs.readFile(outputPath, ‘utf8’, (readErr, svgContent) { // 5. 清理临时输出文件 try { fs.unlinkSync(outputPath); } catch (e) {} if (readErr) { reject(readErr); } else { resolve(svgContent); } }); }); }); } // 配置文件 config.json // { // “securityLevel”: “strict”, // “theme”: “default” // }关键点文件系统隔离使用唯一ID命名临时文件防止并发请求冲突并在完成后立即删除。进程隔离通过子进程执行渲染即使渲染引擎崩溃也不会影响主Node.js服务。资源限制可以考虑使用exec的timeout选项或更高级的spawn配合资源限制防止恶意代码导致渲染进程无限运行。传递安全配置确保通过配置文件或命令行参数将securityLevel: ‘strict’传递给mermaid-cli。5. 深度排查、监控与应急响应即使配置了所有安全措施我们仍需保持警惕建立完整的监控和响应机制。5.1 安全配置检查清单在每次发布前或定期审计时对照此清单检查你的Mermaid集成[ ]全局初始化是否设置了securityLevel: ‘strict’检查所有调用mermaid.initialize的地方。[ ]是否避免了任何形式的innerHTML直接拼接用户输入审查代码确保用户输入的Mermaid代码只通过textContent、value属性或安全的模板引擎如React的JSX、Vue的模板进行绑定。[ ]是否对来自用户或第三方API的图表数据进行了长度限制在前后端均实施限制。[ ]错误处理是否得当渲染失败时是否向用户展示了友好的错误信息而不是将包含潜在敏感信息的堆栈跟踪或原始错误返回给前端[ ]如果使用iframe沙箱沙箱属性是否配置正确确认sandbox属性没有不必要地允许script或allow-same-origin是否必要。[ ]依赖的Mermaid版本是否保持更新定期更新以获取安全补丁。关注Mermaid项目的安全公告。5.2 常见问题与异常排查实录在实际运维中你可能会遇到以下问题问题1设置了securityLevel: ‘strict’后图表中的HTML标签如br不生效了显示为纯文本。原因这是strict模式的预期行为它禁用了所有HTML解析。解决方案首选接受这个限制。用Mermaid本身的语法换行如使用\n在节点文本中但注意Mermaid对\n的支持因图表类型而异有时需要用br这时就只能放弃。替代方案需评估风险如果必须支持简单格式化可以尝试securityLevel: ‘loose’并绝对确保你的输入来源完全可信例如全部来自系统内部生成无任何用户输入。即便如此这也增加了攻击面。后处理方案在Mermaid渲染之后对生成的SVG进行安全的替换。例如用安全的SVGtspan元素替换br标签。这需要操作SVG DOM较为复杂。问题2图表渲染性能突然变差页面卡顿。可能原因用户输入了极其复杂或递归的Mermaid语法虽然不是XSS但可导致拒绝服务。排查与解决在渲染前检查图表定义的长度和复杂度。可以设置一个合理的字符数上限如10000字符。考虑使用Web Worker将渲染任务移出主线程防止阻塞UI。实现渲染超时机制。mermaid.render返回Promise你可以用Promise.race包装它const renderWithTimeout (code, timeoutMs 5000) { return Promise.race([ mermaid.render(‘id’, code), new Promise((_, reject) setTimeout(() reject(new Error(‘渲染超时’)), timeoutMs) ) ]); };问题3在Vue/React中动态更新的图表有时不刷新或出现重复。原因组件更新时旧的SVG没有清理干净或者Mermaid的id冲突。解决在每次渲染前清空容器元素的内容container.innerHTML ‘’。为每次渲染生成一个唯一的id如使用uuid或时间戳确保Mermaid内部缓存不会冲突。问题4如何测试我的防护是否有效构建测试用例创建一个包含各种常见和罕见XSS payload的Mermaid代码列表在你的测试环境中尝试渲染。测试用例示例 1. scriptalert(1)/script 2. graph TD; A[“img srcx onerroralert(1)”] 3. graph TD; A[“javascript:alert(1)”]--B 4. 包含SVG事件处理器的复杂payload。观察结果在strict模式下这些payload应该被转义为纯文本显示不会弹出警告框。你可以使用无头浏览器如Puppeteer自动化这些测试。代码审查定期审查与Mermaid渲染相关的代码变更确保没有引入不安全的模式如误将securityLevel改为loose或使用了不安全的innerHTML拼接。5.3 监控与日志记录在生产环境中监控异常行为至关重要。客户端错误监控集成Sentry、Bugsnag等前端监控工具。捕获mermaid.render抛出的所有异常并记录相关的图表代码片段注意记录前可进行脱敏如只记录前100个字符和哈希值避免将敏感或恶意数据完整存入日志。服务端渲染监控如果使用Node.js服务端渲染监控子进程的执行时间、内存占用和崩溃率。异常的长时间运行或高频崩溃可能预示着攻击尝试。输入模式告警在后端可以记录图表代码的长度、特定字符的出现频率。如果发现某个用户短时间内提交了大量、超长或包含大量特殊字符的图表代码可以触发低级别告警供安全团队审查。安全是一个持续的过程而非一劳永逸的设置。将Mermaid.js的安全配置作为你Web应用安全清单中的标准一项在开发、测试、部署的每个环节都加以关注才能确保这个强大的可视化工具不会成为你系统中最脆弱的一环。从我个人的经验来看最有效的策略始终是默认使用strict模式对所有用户输入保持怀疑并在渲染层之前建立至少一道净化屏障。这样你就能在享受Mermaid带来的便捷的同时牢牢守住安全的大门。