必须用 Unicode 码点级正则（如/\u{1F600}-\u{1F64F}/u.test(str)）检测 emoji，因 maxlength 和 value.length 无法正确处理多码元表情（如??）或单码元符号（如✅），且需加/u标志支持U+FFFF以上码点。
不能靠 maxlength 或 value.length 判断是否含 emoji，得用 Unicode 码点级匹配 —— 否则会漏掉 ?、?? 这类多码元表情，或误判 ✅ 这类单码元符号。
用正则表达式检测 emoji 字符
JavaScript 中最直接的方式是写一个匹配 Unicode emoji 范围的正则，再用 test() 判断：
-
/[\u{1F600}-\u{1F64F}\u{1F300}-\u{1F5FF}\u{1F680}-\u{1F6FF}\u{1F1E0}-\u{1F1FF}\u{200D}\u{FE0F}\u{203C}-\u{3299}]/u.test(str)覆盖常见 emoji（含 ZWJ 连接符、变体选择器） - 注意末尾的
/u标志：必须加，否则无法正确处理 >U+FFFF 的码点（如 ?、??） - 别用
match()返回数组再判空，test()更快、更语义明确 - 这个正则不保证 100% 覆盖所有新 emoji（比如 2025 年新增的 ?），但对当前主流使用足够可靠
监听输入并实时校验 input/textarea
在用户打字过程中检查是否含 emoji，适用于「禁止输入 emoji」或「提示用户已含表情」场景：
- 绑定
input事件，而非change（后者只在失焦时触发） - 避免在事件里直接修改
value（比如删掉 emoji），这会破坏光标位置和组合输入（如中文输入法 + emoji 混输） - 推荐做法：仅做标记或 UI 提示，把拦截逻辑留给提交前校验
- 示例：
const input = document.getElementById('myInput');<br>input.addEventListener('input', () => {<br> if (/[\u{1F600}-\u{1F64F}]/u.test(input.value)) {<br> input.classList.add('has-emoji');<br> } else {<br> input.classList.remove('has-emoji');<br> }<br>});
后端校验必须同步逻辑，别信前端过滤
前端 JS 检测只是体验优化，真正要拦住 emoji，后端必须用相同规则重验：
立即学习“前端免费学习笔记（深入）”；
- Node.js 可用
/[\u{1F600}-\u{1F64F}]/u.test(str)；Python 用re.search(r'[\U0001F600-\U0001F64F]', s)（注意\U大写） - 别依赖数据库字段的
CHARSET=utf8mb4来“允许 emoji”就认为安全 —— 业务规则可能要求禁用，得靠逻辑层判断 - 如果前端显示“已含 emoji”，但后端没校验，用户仍可绕过 JS 提交
- 前后端正则范围尽量一致，否则会出现「前端说有，后端说没有」或反过来的不一致
真正难的不是写出那个正则，而是意识到 emoji 的 Unicode 表示是动态演进的，且不同平台渲染差异大。校验逻辑一旦定下，就要前后端锁死范围，别指望靠“宽松匹配”蒙混过关。
