防xss核心在于安全输出而非拦截输入：twig模板中{{ variable }}默认html转义，确保用户输入不执行脚本；需原样输出时用|raw但须严格清洗；非twig场景需按上下文手动转义，禁用全量预转义。
防XSS的核心不是“拦输入”，而是“准输出”——Symfony默认就做了最关键的一步：Twig模板里用 {{ variable }} 输出时，自动HTML转义。
Twig变量输出自带防护
Twig的双大括号语法不是简单回显，它在渲染那一刻就调用类似 htmlspecialchars() 的机制，把 、<code>>、"、'、& 转成安全的HTML实体。这意味着，哪怕你传入的是 <script>alert(1)</script>，页面上显示的也只是原文字符，不会执行脚本。
- 所有控制器传给模板的字符串，只要走
{{ }}，都默认受保护 - 对象属性、数组元素、方法调用（如
{{ user.name|upper }}）同样适用 - 空值（
null、false）安全输出，不报错也不渲染意外内容
需要原样输出HTML时要主动放行
如果你确实要渲染可信的富文本（比如管理员编辑过的文章内容），必须显式声明信任，否则Twig会继续转义。
- 用
|raw过滤器：{{ article.content|raw }} - 但前提是：该内容已由可信来源生成，且经过严格清洗（例如用 HTMLPurifier 过滤掉 script、on* 事件等危险标签）
- 切勿对用户直接提交的富文本字段无条件加
|raw
非Twig场景需手动转义
当不在模板中输出，比如在控制器里拼接响应、写日志、生成邮件正文或构造JS变量时，Twig不介入，得你自己处理。
- 输出到HTML文本节点或双引号/单引号包裹的属性值，用
htmlspecialchars($str, ENT_QUOTES | ENT_HTML5, 'UTF-8') - 输出到
<script></script>内部或事件属性（如onclick），必须用json_encode($data, JSON_UNESCAPED_UNICODE)包裹后嵌入 - 输出到URL参数中，用
urlencode()或rawurlencode()
别碰“全量预转义”这种伪方案
有人想在接收请求后，就对整个 $_POST 或用户对象递归调用 htmlspecialchars()，这是严重误区。
- 会破坏数据语义：ID、时间戳、JSON字段被转义后无法正常解析或比较
- 性能浪费：大量非HTML上下文字段白白执行字符串操作
- 依然不安全：转义后的字符串若放进JS或CSS上下文，照样可能触发XSS
