PHP更新富文本需用预处理语句防SQL注入，入库前必须用HTMLPurifier等工具净化XSS风险内容，字段类型宜选TEXT/MEDIUMTEXT，输出时依场景决定是否二次转义。

PHP 更新富文本内容时，UPDATE 语句本身没特殊要求，但 HTML 内容必须安全转义

直接拼接 HTML 字符串进 SQL 是高危操作，极易触发 SQL 注入。PHP 中不能靠手动 addslashes() 或字符串替换来“修”HTML，而应使用参数化查询。哪怕 HTML 看起来只是普通文本，只要含单引号、反斜杠、'、"、\0 等字符，未经处理就进 INSERT/UPDATE 就可能报错或被利用。

实操建议：

• 始终用 PDO 或 MySQLi 的预处理语句，HTML 字段作为 ? 占位符传入
• 避免用 mysql_real_escape_string()（已废弃）或 mysqli_real_escape_string() 手动转义——它不解决所有边界情况，且易遗漏编码问题
• 如果 HTML 来自前端 contenteditable 或富文本编辑器（如 TinyMCE、Quill），注意它可能自带 、内联 onerror=、javascript: 链接，这些属于 XSS 范畴，SQL 层不负责过滤，得在入库前净化

富文本入库前必须做 HTML 净化，否则 UPDATE 存的是安全隐患

很多人以为“只要 SQL 安全了，HTML 就能随便存”，结果前端一 echo $row['content'] 就执行了恶意脚本。PHP 没内置 HTML 净化函数，strip_tags() 过于粗暴（会删掉所有标签），htmlentities() 又把整个富文本变成不可读的源码。

推荐方案：

• 用 HTMLPurifier 库（最成熟）：允许白名单式保留
  、、 等，自动剥离 、危险属性、CSS 表达式
• 轻量替代可选 kses（WordPress 同源）或 DOMDocument + XPath 自定义过滤，但需仔细测试嵌套和闭合
• 切勿信任前端传来的 innerHTML 值——即使加了 CSRF Token，也不能跳过服务端净化

UPDATE 语句中 HTML 字段长度超限？检查字段类型和实际字节数

MySQL 的 VARCHAR(65535) 并不等于能存 65535 个中文字符。UTF8MB4 编码下，一个 emoji 或生僻汉字占 4 字节，VARCHAR 实际最大有效长度约 21844 字符（65535 ÷ 3 向下取整，再扣协议开销）。富文本常含大量空格、换行、style 属性，体积膨胀快。

应对方式：

• 字段类型优先用 TEXT（最大 65535 字节）、MEDIUMTEXT（16MB），别硬卡 VARCHAR
• 执行 UPDATE 前可用 strlen($html) 粗略看字节数，超 64KB 就得切到 MEDIUMTEXT
• MySQL 报错 Packet too large 或 data too long for column 时，不只是字段长度问题，也可能是 max_allowed_packet 设置太小（需调大服务器配置）

更新后前端渲染富文本，echo 前仍要区分场景决定是否二次转义

数据库里存的是净化后的 HTML，但输出时不是无条件 echo 就完事。比如用户资料页显示简介，可以放心 echo $user['bio']；但如果这个字段同时用于生成邮件模板、PDF 导出、或作为 JSON API 返回值，直接输出就会出乱码或破坏结构。

关键判断点：

• 输出到 HTML 页面？确认已用 HTMLPurifier 净化过，且未被其他逻辑二次污染，此时 echo 是安全的
• 输出到 JSON 接口？必须用 json_encode()，它会自动转义 、> 等，否则前端 innerHTML 渲染会出错
• 输出到属性值（如 title="xxx"）？需额外用 htmlspecialchars($html, ENT_QUOTES, 'UTF-8')，否则双引号会提前截断属性

$pdo->prepare("UPDATE posts SET content = ? WHERE id = ?")->execute([$cleaned_html, $id]);

真正麻烦的从来不是怎么写那条 UPDATE，而是从编辑器拿到原始 HTML 开始，到最终浏览器渲染之间，每一步都可能漏掉一个转义、一次净化、一种编码假设。