Blade的{{ }}默认转义仅防HTML文本上下文XSS，不处理属性值、JS、CSS、URL等场景，富文本必须用HTMLPurifier预净化，否则{!! !!}等于开后门。
Blade 的 {{ }} 默认转义不能替代 HTML 净化，富文本场景下必须额外处理，否则直接 {!! !!} 就等于开后门。
Blade {{ }} 转义到底防住了什么
它只在模板渲染时对变量做 htmlspecialchars($value, ENT_QUOTES, 'UTF-8')，把 、<code>>、"、& 等字符变成对应 HTML 实体。这意味着：
- 用户提交的
<script>alert(1)</script>会原样显示为文本，不会执行 - 但若用户输入的是
<img src=x onerror=alert(1)>，转义后仍保留完整标签结构，只是字符被编码——而浏览器在某些上下文中（如属性值未闭合、内联事件）仍可能触发执行 - 它不解析 HTML 结构，不移除危险标签或属性，也不校验 URL 协议、
javascript:伪协议等
什么时候必须用 HTMLPurifier 或类似库
只要业务允许用户提交“带格式的内容”，比如后台富文本编辑器、评论区支持加粗/链接/图片、CMS 文章正文，就属于高风险场景。此时：
- 不能依赖 {{ }} —— 它不处理已存储的原始 HTML 字符串
- 不能信任 {!! !!} —— 直接输出等于放弃所有防护
- 必须在入库前或渲染前调用净化逻辑，例如使用
Mews\Purifier的Purifier::clean($html, 'default') - 配置中要显式禁用危险项：
'HTML.Allowed'白名单只留p,b,i,u,a[href|title],img[src|alt]这类安全标签，'Attr.EnableID'设为false，'URI.AllowedSchemes'限制为['http', 'https']
为什么 e() 函数和 htmlspecialchars() 不够用
e() 就是 htmlspecialchars() 的封装，它只解决“纯文本输出到 HTML 内容区”的问题。但它无法应对以下情况：
anything-to-html
下载
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
立即学习“前端免费学习笔记（深入）”；
- 输出到
<script>标签内部：需用json_encode($data, JSON_UNESCAPED_UNICODE | JSON_HEX_TAG)+JS上下文转义 - 输出到 HTML 属性（如
value="{{ $val }}"）：若 $val 含双引号且未闭合属性，仍可能逃逸 - 输出到 CSS 或 URL 上下文：
style="color: {{ $color }}"或href="{{ $url }}"需分别校验颜色值格式、URL 协议与结构
绕过 {{ }} 的常见操作及后果
开发者常因“要显示样式”而掉坑，典型错误包括：
- 用
{!! $content !!}渲染未净化的用户输入 —— 100% 开放 XSS 入口 - 先用
e($content)再用!!包裹 ——e()返回字符串，!!仍会取消转义，等于白干 - 在 JS 中拼接 Blade 变量：
var html = "{{ $userHtml }}";—— 若 $userHtml 含换行或未转义引号，直接破坏 JS 语法，且可能注入执行逻辑 - 用
strip_tags()替代净化 —— 它只删标签，不处理属性里的onerror、javascript:等攻击向量
真正安全的路径只有一条：输入即净化（入库前），输出即上下文适配（模板中按位置选转义方式），没有捷径可抄。
