该用htmlentities()而非htmlspecialchars()时，是需转义所有HTML实体字符（如€、©、ä）并确保源码原样保留；其余场景应优先用更轻量安全的htmlspecialchars()。
什么时候该用 htmlentities() 而不是 htmlspecialchars()
当你需要转义「所有能表示为 HTML 实体的字符」时才用 htmlentities()，比如页面要显示欧元符号 €、版权符 ©、德语变音字母 ä 等，且这些字符必须原样保留在 HTML 源码中（而非被浏览器误解析或乱码）。
绝大多数表单输出、用户评论、动态标题等场景，其实只需要转义 &、、<code>>、"、' 这几个关键字符——这时 htmlspecialchars() 更轻量、更安全、更不易出错。
htmlentities() 的三个参数怎么填才不踩坑
函数签名是 htmlentities(string $string, int $flags = ENT_QUOTES | ENT_SUBSTITUTE | ENT_HTML5, string $encoding = 'UTF-8')，但实际最容易出问题的是后两个参数：
-
$flags不传默认是ENT_QUOTES | ENT_SUBSTITUTE | ENT_HTML5，但老项目若没显式指定，可能因 PHP 版本差异导致引号未转义（比如只用了ENT_COMPAT）；务必写明ENT_QUOTES保证单双引号都处理 -
$encoding必须和你的实际输入编码一致。如果传了'UTF-8'但字符串其实是GBK编码，htmlentities()会静默失败或返回空字符串；不确定时可用mb_detect_encoding($str)先验证 - 别依赖默认值：PHP 8.2+ 已废弃省略
$encoding，强制要求传入；即使旧版本也建议始终显式声明
常见错误现象和对应解法
典型报错或异常表现包括：Warning: htmlentities(): charset `UTF-8' not supported、输出变成空字符串、中文全显示为 你好 或直接乱码。原因和对策如下：
- 传入了不支持的字符集名，如
'utf8'（少了个横线）→ 改成'UTF-8' - 字符串含非法 UTF-8 字节序列（比如从旧数据库读出的 GBK 数据混进了 UTF-8 页面）→ 先用
mb_convert_encoding($str, 'UTF-8', 'GBK')转码，再传给htmlentities() - 启用了
ENT_IGNORE（已弃用且危险）→ 改用ENT_SUBSTITUTE，它会把坏字节替换成�，至少保留结构 - 重复调用
htmlentities()导致二次编码，例如→ 改用 <code>$double_encode = false参数禁止（第四个参数，PHP 5.2.3+ 支持）
和 htmlspecialchars() 混用时的边界要注意什么
两者不能随意替换，尤其在模板拼接或前后端协作场景下：
立即学习“PHP免费学习笔记（深入）”；
-
htmlspecialchars('€', ENT_QUOTES, 'UTF-8')返回€（不转），而htmlentities()返回€或€—— 如果前端 CSS/JS 依赖原始 Unicode 字符（比如用font-family: "Noto Sans"渲染 emoji），用htmlentities()反而破坏显示 - 富文本内容（如带
<strong>的编辑器输出）不该用这两个函数整体处理，否则标签会被转义失效；应只对纯文本段落调用，或用白名单过滤（如strip_tags($str, ['b','i','u'])） - 数据库读出的数据若已用
htmlentities()存储过，再次调用会导致实体嵌套，解码必须用html_entity_decode($str, ENT_QUOTES, 'UTF-8')且注意次数
最常被忽略的一点：字符集声明必须贯穿全程——HTML 响应头、<meta charset="UTF-8">、PHP 文件保存编码、数据库连接编码、htmlentities() 的 $encoding 参数，五者缺一不可。
