应监听input事件并用replace(/1/g, '')实时过滤非法字符，同时判断event.isComposing避免中文输入法中断，后端必须二次校验。a-zA-Z0-9 ↩
HTML表单里怎么阻止用户输入特殊字符
直接在前端拦截特殊字符，靠 input 事件 + 正则判断最可靠。纯用 type="text" 或 contenteditable 区域都得自己监听，pattern 属性只在表单提交时校验，拦不住实时输入。
- 别依赖
pattern做实时过滤——它不触发输入拦截，只影响checkValidity()和提交行为 - 优先监听
input事件，而非keydown：后者拿不到粘贴、自动填充、IME 输入后的最终值 - 正则建议用
/[^a-zA-Z0-9\u4e00-\u9fa5\s]/g匹配非字母、数字、中文、空白的字符（按需调整范围） - 替换时用
target.value = target.value.replace(/[^a-zA-Z0-9\u4e00-\u9fa5\s]/g, '')，别用preventDefault()——它在部分浏览器（如 Safari）对粘贴无效
如何处理中文输入法下的“未确认字符”
用户用拼音/五笔输入时，input 事件会先触发一次带占位符（如 ni_）的值，再触发确认后的中文。直接清除非字数字符会导致输入中断。
- 检查
event.isComposing === true：为true时说明正在 IME 输入中，跳过校验 - 监听
compositionstart和compositionend事件可辅助判断状态，但核心逻辑仍要以isComposing为准 - 示例逻辑：
if (event.isComposing) return; if (/[^a-zA-Z0-9\u4e00-\u9fa5\s]/.test(target.value)) { ... }
后端校验为什么不能省，哪怕前端做了过滤
前端校验能提升体验，但所有输入都可能绕过——禁用 JS、抓包重放、curl 直发请求，特殊字符照样进后端。
- 后端必须做同样规则的白名单校验，不能只依赖前端传来的
value - 数据库写入前，建议用服务端语言的严格正则（如 Python 的
re.fullmatch(r'[a-zA-Z0-9\u4e00-\u9fa5\s]*', s)）再筛一遍 - 如果字段用于 SQL 拼接或 HTML 渲染，额外做转义（如
htmlspecialchars()或参数化查询），别指望“已过滤特殊字符”就安全
textarea 和 contenteditable 元素的特殊处理
textarea 可以照搬 input 的逻辑；但 contenteditable 元素没有原生 value，得操作 innerText 或 textContent，且要防止光标错位。
立即学习“前端免费学习笔记（深入）”；
- 获取内容用
el.innerText（保留换行），或el.textContent（更干净） - 修改后需手动恢复光标位置，否则用户继续打字会从开头插入——可用
getSelection().collapse(el, offset)配合记录上次光标位置 - 更稳妥的做法是：改用
textarea+ CSS 模拟样式，避免contenteditable的 DOM 同步陷阱
isComposing，中文输入就会卡顿；只要后端没独立验证，任何绕过前端的请求都会让过滤形同虚设。 
