Workerman防范XSS的核心是输出时按HTML上下文手动转义，而非输入过滤；必须使用htmlspecialchars($input, ENT_QUOTES, 'UTF-8')或htmlentities()在最终渲染点处理，禁止存储时转义，并辅以输入验证、长度限制和关键词过滤。
Workerman 本身不自动处理 XSS，所有输出到 HTML 的用户输入都必须手动转义——这是防范反射型和存储型 XSS 的核心前提。
输出前必须用 htmlentities() 或 htmlspecialchars() 转义
反射型 XSS 多发生在 URL 参数直接 echo 到页面的场景（比如搜索结果页、错误提示页）；存储型则出现在从数据库读出内容后未过滤就渲染。两者共同点是：数据最终以未编码形式混入 HTML 文本流。
-
htmlentities()更彻底，会转义所有可表示的字符（含非 ASCII），适合多语言环境；htmlspecialchars()只转义 < > " ' &，性能略高，日常够用 - 务必指定
ENT_QUOTES和UTF-8：<code>htmlspecialchars($input, ENT_QUOTES, 'UTF-8')</code>，否则单引号或编码不一致会导致绕过 - 不要在入库前转义（即“存储时转义”），那会让数据变脏、后续 JSON 输出或 API 返回出错；只在输出到 HTML 时转义
不能只靠转义：对输入也要做基础验证和长度限制
转义解决的是“输出安全”，但输入层放行恶意 payload（比如超长 JS 字符串、嵌套 script 标签）仍可能引发其他问题（如日志污染、前端解析异常、服务端内存溢出）。
- 使用
filter_var()验证基础类型：<code>filter_var($email, FILTER_VALIDATE_EMAIL)</code>、<code>filter_var($url, FILTER_VALIDATE_URL)</code> - 对自由文本字段强制长度限制：<code>mb_strlen($content) <= 1000</code>，避免存储型 XSS 携带巨型 payload
- 禁止客户端传入
<script>、javascript:、onerror=等关键词（用stripos()+ 白名单组合判断），不是为了替代转义，而是增加第一道过滤层
模板渲染时别用 echo 拼接 HTML，优先走框架或安全函数
Workerman 常配合原生 PHP 模板或轻量视图层（如 Plates、Twig）。手写 <div><?php echo $user_input ?></div> 是高危模式。
- 如果用 Twig，确保开启自动转义（默认开启），且禁用
|raw过滤器滥用 - 若坚持原生 PHP，封装一个安全输出函数：<code>function safe_echo($s) { echo htmlspecialchars($s, ENT_QUOTES, 'UTF-8'); }</code>，全局替换所有裸
echo - 绝对避免把用户输入拼进
onclick、href="javascript:..."、style="..."等属性中——这些位置即使转义也难覆盖全部攻击面，应改用 data-* 属性 + JS 绑定
最容易被忽略的一点：JSON 接口返回用户数据时，如果前端用 innerHTML 直接插入，照样触发 XSS。此时后端转义无效，必须由前端用 textContent 或 DOMPurify 处理——Workerman 开发者得和前端对齐这个边界责任。
