在 PHP 开发中，安全地处理 HTML 标签的核心原则其实很简洁：入库时保留原始内容，输出时根据上下文进行编码。但这条准则背后隐藏着许多常见陷阱——不少开发者习惯在数据入库前就使用 htmlspecialchars()，结果富文本全部变成了 HTML 实体，数据彻底报废。另一个极端则是直接拼接 SQL 语句，既未有效防御 SQL 注入，又破坏了 HTML 的完整性。

首先需要明确：直接将未转义的 HTML 存入数据库本身并不会带来安全风险。真正的隐患在于两点：第一，输出时没有根据上下文进行差异化的编码处理，导致跨站脚本（XSS）漏洞；第二，混淆了“入库安全”与“输出安全”的概念，要么破坏数据的可用性，要么留下可被利用的安全缺口。下面从三个典型场景出发，详细说明正确的处理方法。

一、入库：保留原始 HTML，避免任何自动转义

在 PHP 8.5.7 环境下，配合 PDO 或 MySQLi 扩展使用时，数据库驱动默认不会对 HTML 进行任何转义——这是理想的状态，应当保持。需要注意以下几个关键禁忌：

• 入库前绝对不要调用 htmlspecialchars()、addslashes() 或 strip_tags()，否则富文本会变成可读性极差的乱码（例如

  Hello

  ）
• 避免手写类似 Db::execute("INSERT INTO ... '$html'") 这样的 SQL 拼接操作，这种做法既可能引发二次转义，更会直接造成 SQL 注入漏洞
• 强制使用预处理语句：$stmt = $pdo->prepare("INSERT INTO posts(content) VALUES (?)"); $stmt->execute([$rawHtml]);
• 数据库字段建议选用 TEXT 或 MEDIUMTEXT，不要使用 VARCHAR(255) 以免截断较长的 HTML 内容

总结一句话：入库阶段只需原样保存，除此之外什么都不要做。

二、输出：根据输出位置选择编码方式，而非“统一转义”

同一段 HTML 可能会出现在不同的上下文环境中，每种情况下的处理方法各不相同：

• 渲染到 HTML 正文（例如
  ）：使用 htmlspecialchars($content, ENT_QUOTES | ENT_HTML5, 'UTF-8')
• 填入 HTML 属性（例如 ）：同样使用 htmlspecialchars，但必须确保属性值被双引号包裹
• 嵌入 JavaScript 字符串（例如 var desc = "";）：不能使用 htmlspecialchars，必须改用 json_encode($content, JSON_UNESCAPED_UNICODE | JSON_HEX_TAG | JSON_HEX_AMP)
• 输出到自定义属性（例如

  ）：仍然属于属性上下文，使用 htmlspecialchars 即可满足安全要求

核心原则：上下文决定了编码策略，不存在一个通用的“安全函数”能够应对所有场景。

三、富文本场景：HTMLPurifier 是必备工具，而非可选项

当用户能够提交包含 、、 等标签的内容时（例如后台编辑器、评论区域），如果直接使用 htmlspecialchars 会将所有标签破坏掉——这种情况下应该采用清洗（purify）而非简单过滤：