yii默认不自动转义输出，必须显式调用html::encode()或使用安全渲染方式，否则用户输入直出html将触发xss；该方法将、"、'、&等转为html实体，确保浏览器不解析为标签或脚本，是防御xss最基础且不可跳过的防护措施。
直接结论：Yii 默认不自动转义输出，必须显式调用 Html::encode() 或使用视图中安全的渲染方式，否则用户输入内容直出 HTML 就会触发 XSS。
为什么 Html::encode() 是最基础、最不可跳过的防护
Yii 的 Html::encode() 把 、<code>>、"、'、& 转成对应 HTML 实体（如 <），让浏览器不再解析为标签或脚本。它不依赖上下文，适用于绝大多数 HTML 文本插值场景。
- 必须对所有「可能含用户输入」的变量做此处理，哪怕只是
$model->title或$_GET['q'] - 不能只在控制器里 encode 一次再传给视图——视图层才是最终输出点，编码必须发生在插入 HTML 前一刻
- 不要用
htmlspecialchars($str, ENT_QUOTES)手动替代，因为Html::encode()还兼容 Yii 的字符集配置和扩展逻辑
富文本怎么办？别硬套 Html::encode()，改用 HtmlPurifier
当业务允许用户发带格式的内容（比如后台编辑器提交的新闻正文），Html::encode() 会把所有标签干掉，显然不行。这时要用 Yii 集成的 HtmlPurifier 组件，在白名单机制下保留合法标签。
- 需提前安装
ezyang/htmlpurifierComposer 包，并在配置中启用：'htmlPurifier' => ['class' => 'yii\helpers\HtmlPurifier'] - 调用时指定过滤规则，例如只允许
<p></p>、<strong></strong>、<a href></a>，并校验href是否以http://或https://开头 - 切忌把 purifier 配置写死在控制器里——应统一收口到行为（Behavior）或服务类，避免不同页面策略不一致
JavaScript 中嵌入用户数据是高危区，Html::encode() 不起作用
如果要把 PHP 变量塞进内联 <script></script> 或 onclick 属性里，Html::encode() 无法防止 JS 上下文中的 XSS。例如：<button onclick="alert('<?php echo Html::encode($name); ?>')"></button> 仍可能被闭合引号后注入代码。
- 正确做法是：先用
Json::encode()序列化为 JSON 字符串（自动加引号、转义反斜杠等），再放进 JS 变量声明中 - 避免在 JS 中拼接 HTML 字符串，尤其不要用
innerHTML = '+ userStr +'；优先用 DOM API 或模板引擎 - 禁用
eval()、setTimeout(string)、setInterval(string)等动态执行字符串的 API
容易被忽略的三个“非典型”输出点
XSS 不只发生在 <div>= $content ?></div> 这种地方。以下三处常被漏防：
-
<meta name="description" content="<?= Html::encode($desc) ?>">——content属性值仍可触发 XSS（如通过javascript:协议） -
<a href="<?=%20Html::encode(%24url)%20?>"></a>—— 必须额外校验协议是否在白名单（http、https、mailto），否则javascript:alert(1)会执行 - HTTP 响应头中拼接用户输入（如
Location: = $_GET['redirect'] ?>）——这属于 HTTP Header 注入，Html::encode()完全无效，必须白名单校验或拒绝未知值
真正难的不是加一行 Html::encode()，而是建立「所有输出都默认不信任」的习惯。模板里每处 = 后面都要多看一眼：这个变量有没有可能来自用户？有没有经过上下文适配的转义？没有就补上——别指望框架替你兜底。
