maxlength按UTF-16码元计数，导致换行符、emoji、输入法等场景下长度计算与用户感知不一致，必须在JS层归一化并服务端双重校验。
textarea maxlength 为什么算不准换行符长度
因为 maxlength 按 UTF-16 码元计数，而换行符在不同系统里占位不同：\n 算 1 个，\r\n 算 2 个。用户从 Windows 复制文本粘贴进 textarea，实际长度可能比预期多出一倍——尤其当后端按 \n 统计时，就会出现“前端显示剩 3 字，提交却报超限”的错位。
常见错误现象：同一段文字，在 macOS 上粘贴后 textarea.value.length 是 98，在 Windows 上变成 105，但 maxlength="100" 在两边都生效，只是截断点不同。
- 不要依赖用户操作系统统一换行风格，必须在 JS 层做归一化处理
- 若业务要求严格按“行数”或“纯字符数”限制，
maxlength不适用，得用input事件 +Array.from(value).length重算 - 服务端入库前也得统一转
\n再校验，否则数据库字段溢出风险真实存在
中文输入法下 maxlength 的“假性失效”怎么补
maxlength 对输入法未上屏的拼音串完全不响应，用户敲 “zhongguo” 八个字母时 value 还是空，直到按空格确认才一次性写入 “中国” 两个字——但此时浏览器已错过拦截时机，可能直接突破限制。
这不是 bug，是规范行为：DOM 只在 compositionend 后更新 value，而原生 maxlength 只在每次字符插入时判断。
立即学习“前端免费学习笔记（深入）”；
- 监听
compositionstart临时禁用实时截断逻辑，避免打断输入法上下文 - 在
compositionend和input两个事件里都做长度检查，且优先用event.target.value而非textContent - 别在
compositionstart中直接改value，会导致光标跳到开头或输入法失焦
emoji 和组合字符让 maxlength 显示与感知不一致
一个 ?? 在 JavaScript 中 .length 是 7，maxlength="10" 下最多放 1 个；但用户只看到 1 个图形，以为还能输 9 个字——这种“视觉长度 vs 码元长度”的割裂，会直接导致体验崩塌。
更麻烦的是，Array.from("??").length 返回 1（按图形单元），而 "??".length 是 7（UTF-16 码元），maxlength 跟后者对齐。
- 如果产品文案强调“最多输入 10 个表情”，就不能用原生
maxlength，必须用Intl.Segmenter或Array.from(str).length做 JS 层校验 - 移动端 Safari 目前不支持
Intl.Segmenter，降级方案是用正则粗略匹配常见 emoji 范围，再减去代理对数量 - 服务端不能简单用
substr(0,10)截断，得先做 Unicode 正规化（如NFC），再按图形单元切分，否则可能切开组合字符
粘贴超长内容时 maxlength 完全不触发怎么办
Chrome 和 Firefox 对粘贴的处理是：先插入全部内容，再按 maxlength 截断；但 Safari（尤其是旧版 iOS）可能只截前半段，甚至不截——导致用户看到光标还在动，实际已超限。
根本原因：maxlength 的拦截发生在 beforeinput 阶段，而 paste 行为在部分浏览器中绕过了该流程。
- 必须监听
paste事件，用event.clipboardData.getData('text')拿原始文本 - 计算插入后总长：
el.value.slice(0, el.selectionStart) + pasteText + el.value.slice(el.selectionEnd) - 超限时调用
el.setRangeText(pasteText.substring(0, max - currentLength), el.selectionStart, el.selectionEnd, 'end')，比execCommand更可靠 - 注意：移动端 WebView 可能不支持
setRangeText，需 fallback 到el.value = ...+ 手动恢复光标位置
真正难的不是写对 maxlength，而是意识到它只是一层薄薄的 UI 拦截——只要用户关掉 JS、用 curl 发请求、或在 DevTools 里改 DOM，所有限制都形同虚设。所以每个用到 maxlength 的地方，后端都得重新走一遍相同逻辑，包括换行归一、emoji 计数、组合字符切分。
