银行卡号前端脱敏必须用JavaScript处理：先清洗空格和短横线，校验长度≥16位，再取前4位和后4位拼接为“6228**1234”；input中保持原始值，仅旁侧span展示脱敏结果；服务端脱敏后前端仍需校验并安全渲染。
银行卡号怎么用 HTML + JavaScript 做前端脱敏显示
纯 HTML 无法实现脱敏，必须配合 JavaScript 处理字符串。浏览器不识别“脱敏”语义，input 或 span 里直接写 6228****1234 是静态假数据，真实场景中你拿到的是完整卡号（比如后端返回的 "6228480000001234567"），得靠 JS 截取、替换、再渲染。
用 slice() 和字符串拼接最稳妥
这是兼容性最好、逻辑最直白的方式，适用于所有现代浏览器和 IE11。别用正则去匹配卡号格式——银行卡长度不固定（16/19 位都有），且可能含空格或连字符，先 .replace(/\s|-/g, '') 清洗再处理。
常见错误现象："6228 4800 0000 1234".slice(0, 4) + "****" + slice(-4) 会漏掉中间空格清洗，导致脱敏后变成 "6228****234"（末尾只取了 3 位）。
- 先用
.replace(/[\s-]/g, '')去掉所有空格和短横线 - 确认清洗后长度 ≥ 16，否则不按标准脱敏（避免异常）
- 取前 4 位：
cardNumber.slice(0, 4) - 取后 4 位：
cardNumber.slice(-4) - 拼成：
`${first4}****${last4}`
const raw = "6228-4800-0000-1234";
const cleaned = raw.replace(/[\s-]/g, '');
const masked = cleaned.length >= 16
? `${cleaned.slice(0, 4)}****${cleaned.slice(-4)}`
: raw; // 长度不够就原样显示，不强行脱敏
input 输入框里实时脱敏？别这么做
用户在 input 中输入时，如果一边输一边把中间替换成 *，会导致光标错位、输入中断、无法粘贴全号——浏览器对受控输入框的值变更非常敏感。
立即学习“前端免费学习笔记（深入）”；
生成可在 deepbi 沙箱 iframe 内运行或作为独立文件运行的交互式 HTML 页面，使用 `window.deepbi` JS SDK 实现数据查询、空间管理、文件浏览及用户操作。当用户提出以下需求时启用该能力： - 创建 KPI 仪表盘、数据表格、文件浏览器、成员列表、管理页面； - 明确要求“转成 dhtml”、“转译成 HTML”、“把 XX 页面转成……”、“控制台页面”、“管理后台”、“DeepBI 页面迁移”； - 提及位于 `apps/console/src/featur
正确做法是：保持 input 的 value 为原始卡号（哪怕用户看到的是 6228****1234），只在旁侧 span 或 label 里展示脱敏结果；提交时仍传原始值。
- 不要监听
input事件去修改e.target.value - 不要用
contenteditable模拟输入框来“假装”可编辑脱敏文本 - 如果必须视觉上隐藏中间位，用 CSS
text-security: disc（仅 Safari/Chrome 支持，且不兼容数字键盘）风险更高
服务端已脱敏，前端还用处理吗
如果后端返回的就是 "6228****1234" 这种字符串，前端**仍需校验长度和格式**。因为攻击者可绕过前端直接调 API，拿到完整卡号；而前端展示层若不做清洗，可能把 "6228****1234<script>..."</script> 当纯文本渲染，引发 XSS。
所以即使服务端脱敏，前端也该：document.getElementById("card").textContent = DOMPurify.sanitize(maskedString)，或至少用 textContent 而非 innerHTML 插入。
容易被忽略的地方：脱敏不是“藏起来就安全”，而是“最小必要展示”。如果你的页面要打印银行卡号（比如电子回单），print 媒体查询里还得还原原始值——这时候脱敏逻辑就得可逆或保留原始字段，不能只存一个 **** 字符串。
