maxlength按utf-16编码单元计数而非用户感知的字数，中文输入法组词阶段不触发检查，需结合array.from()、input事件监听与服务端字节校验才能真正按“所见即所得”限制长度。
maxlength 在中文输入场景下不是“不准”，而是根本没在用户感知的维度上计数——它按 UTF-16 编码单元（code units）算，不是按汉字、emoji 或输入法上屏后的“字”算。
为什么中文输入时 maxlength 常被绕过
用户用拼音输入法敲 zhongguo，value 仍是空字符串；按下空格后，“中国”两个汉字一次性写入 value，此时才触发 maxlength 检查。中间的组词过程浏览器不干预，也不计入长度，导致“明明只打了两字却超限”的错觉。
- 输入法未上屏阶段，
input事件不触发，maxlength完全静默 - 用户粘贴含中文+emoji 的文本，如
你好??，value.length返回 5（UTF-16 单元），但视觉上只有 4 个“字” - 某些旧版 Android WebView 对
compositionend响应延迟，上屏后截断滞后，造成闪退或光标错位
textarea 粘贴超长内容时的实际行为
现代浏览器对 textarea 的粘贴大多会自动截断，但不可依赖：部分 iOS Safari 和微信内置 WebView 仍会完整插入再触发 input 事件，此时 value.length > el.maxLength 已成事实。
- 仅靠
maxlength属性无法保证 DOM 值合规，必须监听input事件并手动裁剪 - 直接赋值
el.value = el.value.slice(0, N)会把光标重置到末尾，影响体验 - 更稳妥做法是用
el.setRangeText()替换超出部分，或结合el.getSelectionRange()保留原光标位置
真正按“用户看到的字数”限制该怎么做
不能用 String.length，得用 Unicode-aware 方式统计字符数。JavaScript 中最可靠的是 Array.from(value).length，它能正确识别 emoji 序列、组合字符（如 é）、以及增补平面字符（如 ?）。
- 监听
input事件，同时判断!event.isComposing避免打断输入法 - 截断逻辑示例：
const chars = Array.from(el.value); if (chars.length > MAX_CHAR) { el.value = chars.slice(0, MAX_CHAR).join(''); } - 服务端校验必须同步逻辑：Node.js 用
Array.from(str).length；Python 用regex.findall(r'\X', str)（Unicode 字形簇）；Java 用str.codePointCount(0, str.length())
数据库字段长度和前端 maxlength 不匹配的风险
maxlength="32" 和 MySQL 的 VARCHAR(32) 完全是两套体系：前者按 UTF-16 code units，后者按字节数（utf8mb4 下一个 emoji 最多占 4 字节）。一个 ?? 在前端算 2 个字符，在数据库里占 8 字节。
- 若字段定义为
VARCHAR(32)，前端设maxlength="32"可能存不下 8 个 emoji - 更安全的做法是：前端按字符数限制（用户体验），服务端按字节数二次校验（数据落地）
- 尤其注意短信、API 接口等对字节数敏感的场景，需提前换算：中文在
utf8mb4下固定占 3 字节，emoji 多为 4 字节
最难的不是写一行 slice，而是让输入法、粘贴、光标、移动端软键盘、服务端编码全部对齐——漏掉任意一环，用户就会遇到“删不掉”“输不了”“存不进”这类具体问题。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
