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 开始，到最终浏览器渲染之间，每一步都可能漏掉一个转义、一次净化、一种编码假设。
