解读

在国内一线、二线互联网公司的 PHP 面试中，Blade 的自动转义是“必问高频”。
面试官通常不会只问“Blade 会不会转义”，而是给出一段视图代码，要求候选人指出：

1. 哪些变量会被转义、哪些不会；
2. 如果业务需要输出富文本，如何安全放行；
3. 在多语言、组件化、前端 SSR 同构场景下，转义策略对 XSS 防线的影响；
4. 如何在不破坏转义的前提下，保证高并发渲染性能。
   答不到“底层实现 + 安全边界 + 性能”这三个维度，很容易被判定为“只用过，没读过源码”。

知识点

1. 转义核心函数：e()（htmlspecialchars 封装，flags=ENT_QUOTES | ENT_SUBSTITUTE, 编码 UTF-8）。
2. Blade 编译规则：
   {{ var }} → <?php echo e(var); ?>
   {!! var !!} → <?php echo var; ?>
3. 源码位置：
   Illuminate/View/Compilers/BladeCompiler.php 的 compileEchoDefaults() 与 compileRawEchos()。
4. 豁免场景：
   信任内容需用 {!! !!}，但必须在服务端做白名单过滤（HTMLPurifier、DOMPurify、CommonMark 扩展）。
5. 配置开关：
   config/app.php 中 ‘blade_escape’ 可全局覆写，但国内团队几乎不允许关闭，需通过策略类做细粒度放行。
6. 性能相关：
   视图缓存存储在 storage/framework/views，转义发生在编译期而非运行时，OPcache 开启后无额外 CPU 消耗。
7. 国内合规：
   《网络安全法》第21条要求“采取防范计算机病毒和网络攻击、网络侵入等危害网络安全行为的技术措施”，Blade 默认转义是落地该条款成本最低方案之一，审计报告可直接作为“输出编码防护”证据。

答案

“Laravel Blade 默认对所有 {{ }} 输出进行自动转义，编译阶段调用 e() 函数，把 & < > " ’ 五个关键字符转成 HTML 实体，从而阻断反射型与存储型 XSS。
若业务必须渲染富文本，应使用 {!! !!} 并在控制器或服务层引入经过白名单过滤的 HTML，绝不可直接信任用户输入。
生产环境建议：

1. 开启内容安全策略（CSP: default-src ‘self’）；
2. 对富文本走 DOMPurify 服务端过滤，并定期更新规则；
3. 通过单元测试断言：assertSeeText() 验证普通变量被转义，assertSeeHtml() 验证白名单标签放行。
   这样既满足等保测评，也兼顾性能与可维护性。”

拓展思考

1. 在微前端或 SSR 同构场景，Blade 只负责首屏渲染，后续路由由 Vue/React 接管。此时需要保证“服务端转义 + 客户端 hydration 数据二次转义”策略一致，否则会出现双端 HTML 校验失败（hydration mismatch）。
2. 国内大型电商做页面静态化时，会先把 Blade 渲染结果落盘到 CDN。若后期需要切换域名或 HTTPS，必须重新编译视图，防止 e() 把 https:// 中的 // 转义成 // 导致协议相对 URL 失效。
3. 从 PHP 8.1 开始，htmlspecialchars 默认开启 ENT_SUBSTITUTE，Blade 无需额外处理无效编码，但老旧接口若直接 json_encode 后 echo，仍可能抛出 malformed UTF-8 异常，需要 mb_convert_encoding 前置处理。