应先判断字符串是否已含HTML实体再决定是否替换，避免双重转义；推荐用html_entity_decode还原后比对，或检测&[a-z]+;等模式跳过已转义内容。
正则替换前先判断是否已转义
直接用 preg_replace() 处理 HTML 实体，最容易踩的坑就是对已经转义过的字符串重复操作。比如 & 被再次匹配 &，变成 &——浏览器最终渲染为 &，而不是 &。
不要假设输入“干净”。实际场景中，数据可能来自数据库（已被 htmlspecialchars() 处理过）、富文本编辑器导出、或前端 JSON 传入，都可能含实体。
- 先用
html_entity_decode($str, ENT_NOQUOTES, 'UTF-8')尝试还原，再对比长度或字符变化，判断是否已含实体 - 更稳妥的做法：只对纯文本内容做正则替换，若字符串里已存在
&[a-z]+;或\d+;模式，跳过处理或走清洗流程 - 避免写
preg_replace('/&/', '&', $str)这类无条件替换——它不管上下文，必然导致双重转义
用 htmlspecialchars_decode + htmlspecialchars 组合清洗
如果你的目标是“把原始 HTML 字符（如 、<code>&）替换成别的东西，但又要保持输出安全”，不要在实体层做正则，而应走解码 → 修改 → 编码三步。
例如：把所有 <p></p> 标签替换成 <section></section>，但又不能让已有 <p> 被错误替换：
立即学习“PHP免费学习笔记（深入）”；
$raw = html_entity_decode($input, ENT_QUOTES, 'UTF-8');
$cleaned = preg_replace('/<p\b[^>]*>/i', '<section>', $raw);
$output = htmlspecialchars($cleaned, ENT_QUOTES, 'UTF-8');
这个流程确保：输入无论是否含实体，最终输出都是安全且语义正确的 HTML 字符串。
- 必须显式传
ENT_QUOTES和'UTF-8'，否则中文或单引号会出问题 -
html_entity_decode()默认只解&、<、>、"、'，不会误解自定义实体（如©），符合多数场景 - 别用
htmlentities()替代htmlspecialchars()做最后一步——它会把中文也转成你，体积大、可读差
属性值和 JS 上下文里根本别碰正则替换
在 value="..."、onclick="..." 或 var data = <?php echo $json; ?>; 这类位置，用正则替换 HTML 实体不仅无效，而且危险。
浏览器解析顺序是：先按 HTML 规则解析属性引号和标签边界，再执行 JS。你用正则改了引号或 &，很可能破坏结构。
- 属性值统一走
htmlspecialchars($val, ENT_QUOTES, 'UTF-8')，它专为此设计 - JS 变量注入必须用
json_encode($val, JSON_UNESCAPED_UNICODE)，不是htmlspecialchars() - 绝对不要写
preg_replace('/"/', '"', $attr)——这绕过了引号配对逻辑，" onclick=alert(1)会被切成两段
数据库读出带反斜杠的 HTML 怎么办
如果从数据库读出的字符串里有 " 或 \"，说明写入时用了 addslashes() 或开启了过时的 magic_quotes_gpc。这不是 HTML 实体问题，而是 C 风格转义残留。
此时用正则去“修复”极易出错。正确做法是：
- 先用
stripcslashes($str)清除反斜杠转义，还原成原始双引号、单引号 - 再用
htmlspecialchars($str, ENT_QUOTES, 'UTF-8')输出到 HTML - 如果字符串本身是合法 HTML（比如后台编辑器存的），且你要原样渲染，就该用白名单过滤（如 HTMLPurifier），而不是正则替换
真正难处理的从来不是“怎么替换”，而是“什么时候不该替换”——尤其当数据流经过多层存储、编码、传输后，原始意图早已模糊。盯着输入来源比调正则参数更重要。
