iban输入需实时分组、过滤非法字符并校验长度与国家码，但mod-97校验必须由后端执行；前端仅负责空格分组（每4位）、清洗不可见符、截断超长内容及快速拦截明显错误。
IBAN 输入框不是加个 type="text" 就完事的——不校验格式、不自动空格分组、不处理粘贴乱序，用户输错率直接翻倍，后端还得兜底验证，纯属重复劳动。
怎么让输入时自动加空格分组
IBAN 标准要求每 4 位一组（如 DE44 5001 0517 0000 0000 00），但用户不会手动敲空格。不能靠 inputmode="text" 或 placeholder 提示，得用事件实时干预。
- 监听
input事件，拿到当前值后先.replace(/\s/g, '')清空所有空格 - 再按每 4 位切片：
value.match(/.{4}/g)，最后.join(' ') - 注意光标跳变问题：原生
input的setSelectionRange必须在值更新后同步重置，否则光标会跳到末尾 - 别用
keydown—— 粘贴、剪切、中文输入法组合键都会绕过它
怎么防止用户输错字符或长度
IBAN 不是任意字母数字拼接，它有严格结构：2 字母国家码 + 2 位校验码 + 最长 30 位基本账号（BBAN）。前端拦截能省掉大量无效请求。
anything-to-html
下载
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
- 实时过滤非法字符：
value.replace(/[^A-Za-z0-9]/g, '')，别留 Unicode 空格、全角数字 - 国家码必须存在且合法——至少检查前 2 位是否为字母（
/^[A-Za-z]{2}/），否则立刻提示“国家代码缺失” - 总长度必须落在该国 IBAN 规定范围内（如德国 22 位、英国 22 位、沙特 24 位），可查 IBAN Structure 建个映射表
- 不要等 onBlur 才校验——用户输到第 3 位就发现是
XX123（非字母开头），应立即截断
怎么安全处理粘贴的 IBAN
用户从邮件、PDF 复制 IBAN 时，常带换行、制表符、多余空格甚至隐藏 Unicode 字符（如 \u200B 零宽空格），直接 .trim() 不够。
- 粘贴时监听
paste事件，e.preventDefault()后取e.clipboardData.getData('text') - 用正则清洗：
cleaned = raw.replace(/[\u200B-\u200D\uFEFF\s]+/g, '')（覆盖常见不可见符） - 再走一遍分组逻辑——别假设粘贴内容已合规，哪怕看起来是
DE44500105170000000000，也要重新分组为DE44 5001 0517 0000 0000 00 - 如果粘贴后总长超限（如沙特 IBAN 要求 24 位，却粘了 30 位），截断前 24 位并提示“已自动截取有效部分”
为什么不能只依赖前端校验
IBAN 最关键的校验是 MOD-97 算法：把国家码转数字、拼上校验码和 BBAN，整个字符串模 97 必须等于 1。这个计算必须由后端执行，前端只能做快速过滤。
- 前端算 MOD-97 容易溢出（JS 数字精度上限
2^53，而完整 IBAN 转数字可能远超此值） - 国家码转换规则（如
A=10, B=11）和顺序（把校验码挪到末尾再计算）极易写错，调试成本高 - 即使前端 JS 校验通过，仍要传原始未分组值（去空格）给后端，避免分组逻辑差异导致不一致
- 真正上线时，后端返回的错误码（如
invalid_iban_checksum）应映射到前端具体提示，而不是笼统说“格式错误”
最麻烦的其实是各国 BBAN 内部结构差异——德国的银行码+账号、英国的 sort code+account number，这些业务规则前端根本不该碰。分组、去杂、长度卡控，做到这三点，就已经挡住 80% 的低级错误。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
