应使用 input 事件实时过滤非法字符，因其能捕获粘贴、拖入等操作，避免光标跳变，并需配合后端校验确保安全。
表单提交前用 input 事件实时过滤内容
用户在输入时就该拦住非法字符，而不是等点提交才报错。用 input 事件监听比 change 更及时，也比只靠 submit 校验体验好得多。
常见错误是绑定 keydown 或 keypress —— 它们无法捕获粘贴、拖入、自动填充等操作，过滤会漏掉一大块场景。
- 对
<input type="text">和<textarea></textarea>都有效 - 过滤逻辑建议写在事件回调里，先取
e.target.value，处理完再赋回e.target.value - 注意避免光标跳到末尾：用
e.target.setSelectionRange()保留原位置（尤其替换中间字符时）
input.addEventListener('input', e => {
const raw = e.target.value;
const cleaned = raw.replace(/[^a-zA-Z0-9\u4e00-\u9fa5]/g, '');
if (cleaned !== raw) {
e.target.value = cleaned;
// 这里可选：重置光标位置
}
});
后端必须校验，前端过滤只是体验层
前端任何过滤都能被绕过——禁用 JS、改 DOM、直接发 POST 请求，全都不受影响。所以 input 事件做的只是“让用户输得顺”，不是“让数据变安全”。
典型翻车场景：有人以为加了正则过滤就不用后端检查了，结果数据库存进去了 SQL 注入片段，或渲染时触发 XSS。
立即学习“前端免费学习笔记（深入）”；
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
- 后端收到字段后，仍需做同样逻辑的清洗（比如去除非字母数字字符），不能信任
req.body.xxx - 如果字段用于拼接 SQL 或插入 HTML，必须走参数化查询或 proper escaping，不能只依赖字符白名单
- 前后端正则最好保持一致，否则用户看到“已过滤”但提交失败，会困惑
pattern 属性只能提示，不能阻止提交
pattern 是 HTML5 原生属性，写在 <input> 上，比如 pattern="[a-zA-Z0-9]+" 。但它只影响表单的 checkValidity() 结果和浏览器默认提示，不拦截输入、也不修改值。
容易踩的坑是以为加了 pattern 就万事大吉，结果用户照样能粘贴非法字符，点提交时才弹红框——体验割裂，且没解决脏数据入库问题。
-
pattern不触发实时过滤，只在调用reportValidity()或原生 submit 时校验 - 它不支持中文 Unicode 范围简写（如
\p{Han}），得写成[\u4e00-\u9fa5] - 移动端键盘可能因
pattern变成数字键盘，但不影响实际输入内容，别误判为“已限制”
特殊字段要按语义选过滤策略
邮箱、手机号、金额这些字段，不能一概套用“删掉所有非字母数字”。不同字段的合法边界差异很大，硬统一反而引入 bug。
比如金额字段允许 -、.、,，但小数点最多一个；邮箱里 @ 和 . 是必需的，但不能出现在开头或结尾。
- 邮箱：优先用
type="email"+ 后端 RFC 5322 校验，前端过滤仅限防空格/换行 - 手机号：区分国家代码，国内常用
^1[3-9]\d{9}$，但要注意带区号或分机号的场景 - 富文本输入（如
contenteditable）：不能只靠正则，得用 DOM 操作剥离 script/style 标签
真正麻烦的从来不是怎么写正则，而是想清楚“这个字段在业务里到底允许多大自由度”。比如用户昵称要支持 emoji，就得放开 Unicode 表情区间；而搜索关键词可能需要保留空格和引号来支持短语匹配——过滤逻辑必须跟着业务走，不是越严越好。
