HTML本身不加密，“HTML加密”是误称；真正需将数据脱敏逻辑前置到服务端，前端仅负责安全渲染，混淆、掩码、动态解密等均为补充手段，不可替代服务端输出控制。
HTML 本身不加密，所谓“HTML 加密”是误称；真正要做的，是把数据脱敏逻辑前置到服务端，前端只负责安全渲染——混淆、掩码、动态解密这些操作，都只是补充手段，不能替代可信服务端的输出控制。
服务端脱敏必须先于任何前端处理
如果你在前端用 replace() 或 btoa() 处理手机号，但服务端返回的是明文 {"phone": "13812345678"}，那等于裸奔。用户打开 Network 面板一眼就看到原始值，localStorage、innerHTML、甚至 DevTools 的 console 都能直接读取。
- 后端模板层直接输出掩码：如 Spring Boot 的
@JsonSerialize(using = PhoneMaskSerializer.class)，返回字段已是"138****1234" - 数据库查询时脱敏：MySQL 用
CONCAT(LEFT(phone,3), '****', RIGHT(phone,4))，MyBatis 用<bind>标签预处理 - 不同角色不同精度？必须由服务端根据
role或权限上下文决定是否调用maskPhone()，前端绝不做if (user.role === 'intern') { mask() }这类判断——role 可被篡改
前端掩码不是加密，但必须在 DOM 插入前完成
前端 JS 掩码（如 phone.replace(/(\d{3})\d{4}(\d{4})/, "$1****$2")）只适用于轻量场景，且有严格执行时机要求：必须在 innerHTML 赋值或 React/Vue 渲染前执行，不能等 DOM 挂载完再遍历 querySelectorAll("td.phone") ——那样会短暂闪现明文，肉眼可见。
- 中文/日文姓名掩码慎用
substring(0,3)，应改用.slice(0,3)或正则/^[\u4e00-\u9fa5a-zA-Z0-9]{1,3}/防止截断字节 - 表格中敏感字段（
idCard、email）统一走 service 层封装，避免每个组件重复写掩码逻辑 - 表单提交时，确保隐藏域或内存变量里存的是原始值，不是掩码后的字符串——否则后端收不到真实数据
Web Crypto API 动态解密只适合极少数可信场景
用 window.crypto.subtle.decrypt() 在前端解密敏感内容，听起来很安全，但实际落地门槛极高：密钥不能硬编码，IV 必须每次随机生成（crypto.getRandomValues(new Uint8Array(12))），且整个流程需运行在 HTTPS 下。一旦密钥或 IV 泄露，加密形同虚设。
立即学习“前端免费学习笔记（深入）”；
- 仅建议用于内部系统中「点击查看详情」这类按需加载场景，且解密后内容不写入 DOM 属性、
dataset或全局变量 - 解密结果应暂存在闭包或
Map中，操作完立即delete引用，避免长期驻留内存 - 禁用
console.log()输出解密结果，防止误打日志；禁用input.value = decrypted，改用临时contenteditable区域或受控组件
Base64 / btoa / atob 不是加密，是自欺欺人
btoa("13812345678") 得到的 MTM4MTIzNDU2Nzg=，用户打开控制台敲一行 atob("MTM4MTIzNDU2Nzg=") 就还原了。这种做法常见于把密文塞进 data-encrypted 自定义属性，还配个注释说“已加密”，本质是给开发者自己看的心理安慰。
-
btoa()和atob()是编码/解码，不是加密，无密钥、无算法强度、无防重放能力 - 所有写进 HTML 注释、
data-*属性、textContent的“密文”，都等同于明文暴露 - 如果真需要混淆，至少用 Web Crypto API 的
AES-GCM，并确保密钥由服务端动态下发、单次有效
最常被忽略的一点：脱敏不是加几颗星号就完事，而是从数据源头开始控制——服务端要不要吐出完整字段，取决于接口契约和权限模型。前端所有操作，只是对那个契约的忠实执行，而不是补漏或兜底。
