表单 <input> 和 <textarea></textarea> 默认就支持 Emoji 输入
只要用户系统和浏览器没锁死输入法，Emoji 就能正常输入、提交、显示。不需要加任何特殊属性或 JS 拦截——加了反而容易出问题。
常见错误现象：input.value 看起来是空的、提交后后端收不到、数据库存成 ??? 或乱码。这些问题几乎都跟后端处理或数据库配置有关，不是前端表单本身不支持。
- 确保页面声明了 UTF-8 编码：
<meta charset="utf-8"> - 避免用
oninput或onchange里对value做正则过滤（比如删掉非 ASCII 字符），这会直接吞掉 Emoji - 如果用了富文本编辑器（如 TinyMCE、Quill），要确认它没开启「纯文本模式」或内容清理逻辑
MySQL 存 Emoji 必须用 utf8mb4 字符集
这是最常踩的坑：前端一切正常，但提交后数据库只存下问号或报错 Incorrect string value。根本原因是 MySQL 默认的 utf8 实际只支持最多 3 字节的 Unicode 字符，而 Emoji 大多是 4 字节（如 ?、?、??）。
- 建表时指定字符集：
CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci - 连接层也要设对：PHP PDO 需加
charset=utf8mb4到 DSN；Node.js 的 mysql2 库需显式设charset: 'utf8mb4' -
my.cnf中的character-set-server和collation-server也得是utf8mb4，否则新创建的库/表仍可能继承旧默认值
前后端传输中不要用 encodeURIComponent 反复编码
Emoji 是合法的 URL 字符，encodeURIComponent('Hello ?') 结果是 Hello%20%F0%9F%91%8B，看起来没问题，但如果在已编码的字符串上再调一次，就会变成双层编码，后端 decodeURIComponent 一次解不开。
立即学习“前端免费学习笔记（深入）”；
- 用
FormData提交表单时完全不用手动编码，浏览器自动处理 - 用
fetch+JSON.stringify传数据时，JSON 本身支持 Unicode，无需额外编码 - 只有拼接 query string（比如
url?name=...）且值来自用户输入时，才需一次encodeURIComponent，且仅此一次
移动端软键盘 Emoji 面板触发依赖原生行为
没有可靠 JS API 能主动唤起 Emoji 面板。所谓「强制弹出 Emoji 键盘」都是误导——iOS 和 Android 对 inputmode 或 type="text" 的处理不一致，强行改 inputmode="text" 或加 pattern 可能反而禁用 Emoji 入口。
- 保持
<input type="text">或<textarea></textarea>即可，系统会根据语言环境和输入法自动提供 Emoji 按钮 - 不要监听
keydown拦截Enter或Space来“模拟” Emoji 输入，这会破坏粘贴、组合输入（如中文+Emoji混输）等正常流程 - 如果必须引导用户使用 Emoji，用文字提示（如「试试输入 ? 表达喜欢」）比技术干预更可靠
真正卡住的点往往不在表单本身，而在数据库字段长度（utf8mb4 下一个 Emoji 占 4 字节，但 varchar(255) 还是 255 字符，不是 255 字节）、ORM 默认字符集未覆盖、或者 Nginx/CDN 缓存了早期的错误响应。查问题时优先盯住后端日志里的原始请求体和数据库实际存储值，而不是反复改前端代码。
