HTML表格无法真正加密数据，“加密展示”实为前端脱敏，必须在数据写入DOM前完成；base64和md5均不安全，前者可逆，后者易撞库；脱敏需预处理原始数据并配合data-raw属性支持搜索，高敏字段不应传至前端。
HTML表格本身不能加密数据，所谓“加密展示”实际是前端脱敏或混淆显示，且必须在数据写入DOM前完成——等它渲染成 <td>13812345678</td> 再去遮盖，用户右键查看源码或调试器里一眼就看到明文。
为什么不能用 base64 或 md5 做“表格加密”
常见错误是把手机号 "13812345678" 用 btoa() 编码成 "MTM4MTIzNDU2Nzg=" 再塞进表格，以为“加密了”。但这是可逆编码，控制台敲一行 atob("MTM4MTIzNDU2Nzg=") 就还原；md5 更糟——它不可逆，但你根本不需要还原，只要比对哈希值就能撞库。这类操作既不防窥探，也不防篡改，纯属自我安慰。
真正可行的脱敏逻辑必须在 JS 插入 DOM 前执行
关键动作发生在数据从后端返回、但尚未写入 innerHTML 或 textContent 的那一瞬间。比如拿到用户列表数组后，先批量处理再渲染：
- 用正则替换手机号：
phone.replace(/(\d{3})\d{4}(\d{4})/, '$1****$2') - 身份证号只留前4后4：
idCard.replace(/(\d{4})\d{10}(\d{4})/, '$1**********$2') - 金额保留整数位，小数部分统一显示为
"**"，避免暴露精度 - 若字段为空或格式异常（如非11位数字），不强行脱敏，而是留空或打“—”，防止误脱敏引发业务歧义
模糊搜索时别让脱敏干扰匹配逻辑
如果表格支持搜索，而你又对单元格做了脱敏（比如显示 "138****1234"），那用户搜 "13812345678" 就永远匹配不上——因为 DOM 里根本没有完整字符串。解决方法只有一个：搜索时用原始数据比对，展示时用脱敏后数据。
立即学习“前端免费学习笔记（深入）”；
典型做法是把原始值存在 data-raw 属性里：
<td data-raw="13812345678">138****1234</td>
搜索函数里读 td.dataset.raw，而不是 td.textContent。注意：这个 data-raw 仅用于前端搜索，绝不能包含密码、银行卡 CVV 等高敏字段——那些本就不该出现在前端。
最易被忽略的一点：脱敏不是加一层 CSS 遮罩或伪元素，也不是靠 text-security: disc 这种表面功夫。只要数据以明文形式存在于内存或 DOM 属性中，它就不是真正受控的。能被 JavaScript 读到，就能被恶意脚本读到。高敏字段唯一安全的做法，是压根不传到前端。
