HTML实体编码本身不防敏感数据泄漏，只影响浏览器渲染，不影响源码明文暴露；它能拦XSS但拦不住信息泄露，因查看源码、抓包或模板未脱敏时，编码内容仍原样可见，真正防泄漏需服务端逻辑隔离与前端最小化输出。
HTML字符实体编码本身不防敏感数据泄漏，它只解决“浏览器怎么解析字符串”这一个问题；把密码、token、手机号这类字段用@或<包一层，对爬虫、开发者查看源码、中间代理抓包完全无效。
哪些场景下 HTML 实体编码能拦住 XSS，但拦不住信息泄露
实体编码只影响浏览器渲染行为，不影响原始 HTML 源码内容。只要攻击者能拿到页面 HTML（比如右键“查看源码”、抓包、服务端模板未删敏就吐出），所有编码后的字符都会原样暴露。
- 用户邮箱显示为
user@example.com→ 查看源码立刻看到真实邮箱 - 订单号渲染成
ORD-2026-7890→ 源码里就是ORD-2026-7890的编码形式，一解就还原 - API 返回的 JSON 被直接
innerHTML = JSON.stringify(data)→ 即使里面含<script>被编码了，整个 JSON 结构和字段值（含身份证号、地址）全在源码里明文躺着
真正防泄漏必须靠服务端逻辑隔离 + 前端最小化输出
敏感字段不该出现在 HTML 源码里，无论是否编码。关键不是“怎么编码”，而是“该不该发”。
- 后端模板中禁止直接插敏感字段：
{{ user.phone }}或必须先判断当前用户权限，再决定是否传入模板 - 前端 JS 从 API 拿数据时，敏感字段应由后端做过滤（如返回
{"phone": "138****1234"}），而非前端靠replace()遮掩 - 避免在
data-属性里塞 token：<div data-token="abc123..."> → 即使 <code>token被 HTML 编码，仍可被 JS 读取、被爬虫提取 - 调试用的
console.log(user)或debugger未清理 → 生产环境源码里留着完整对象，含所有字段 -
html_entity_decode("user@example.com")→ 返回user@example.com，原始字符串反而更易被正则匹配 - 数据库里存的是
@，查出来再 decode，等于把脱敏动作后移到了应用层，没减少任何暴露面 - 真正要脱敏，得在查询时就做字段掩码：
SELECT CONCAT(LEFT(phone,3), '****', RIGHT(phone,4)) AS phone FROM users
html_entity_decode() 不是解密，只是还原编码字符
有人误以为对已编码的敏感字段调用 html_entity_decode() 是“解密操作”，其实它只是把 变回 <code>，把 <code>@ 变回 @ —— 完全不改变数据是否暴露的事实。
立即学习“前端免费学习笔记（深入）”；
最常被忽略的一点：HTML 编码只管“浏览器怎么显示”，不管“谁能看到源码”。只要敏感数据进了 HTML 字符串，就已经泄漏了——编码只是让它不执行，不是让它看不见。
