maxlength按Unicode码点计数，emoji占2–4码点，input[type="number"]不支持，粘贴可绕过，需JS截断+后端校验，Safari对textarea和maxlength="0"有兼容问题，字节限制须用TextEncoder等手动实现。
maxlength 属性在 <input> 和 <textarea> 中的行为差异
maxlength 对 <input type="text"> 和 <textarea> 都有效，但底层计数逻辑一致：按 Unicode 码点（code point）计数，不是字节数，也不是“人眼看到的字数”。这意味着一个 emoji（如 ??）可能占 2–4 个码点，maxlength="10" 下它可能只允许输入 2~3 个就满额。中文、英文、数字、标点均按单个码点计算，这点和预期基本一致。
注意：<input type="number"> 不支持 maxlength —— 浏览器会直接忽略该属性，必须改用 max + JavaScript 校验或换为 type="text" 并监听 input 事件做限制。
为什么设置了 maxlength 还能粘贴超长内容？
原生 maxlength 只拦截键盘输入和部分剪贴板操作（如 Chrome 对 Ctrl+V 的基础截断），但对右键粘贴、拖放文本、程序化 .value = longString 无约束力。用户仍可通过粘贴绕过限制，导致表单提交时数据超标。
安全做法是双重校验：
立即学习“前端免费学习笔记（深入）”；
- 保留
maxlength提供即时 UI 反馈 - 在
input或blur事件中用 JavaScript 截断：input.addEventListener('input', () => { if (input.value.length > 50) { input.value = input.value.slice(0, 50); } }); - 后端必须再次校验——
maxlength完全不可信
maxlength 在不同浏览器中的兼容性与边缘表现
所有现代浏览器（Chrome/Firefox/Safari/Edge）均支持 maxlength，但存在两个易忽略的细节：
- Safari 对
<textarea>的maxlength在 iOS 上偶尔失效（尤其配合contenteditable或第三方输入法时），建议加一层input事件兜底 - 当
maxlength="0"时，Chrome 和 Firefox 会禁用输入，但 Safari 允许输入——这不是 bug，而是规范未明确定义 0 值语义，应避免使用maxlength="0"，改用disabled或readonly - 若同时设置
minlength和maxlength，且minlength > maxlength，表单将永远 invalid，但不会报错，需人工检查逻辑
替代方案：需要统计“显示长度”或“字节数”时怎么办？
如果业务要求限制 UTF-8 字节数（如对接短信网关、数据库字段长度为 byte）、或按“中文字符算 2 字节、英文算 1 字节”计费，maxlength 完全无法满足。
此时必须用 JavaScript 手动计算：
- UTF-8 字节数估算（较准）：
new TextEncoder().encode(str).length - 双字节字符粗略统计（中文/日文/韩文）：
str.replace(/[^\u4e00-\u9fa5]/g, '').length * 2 + str.replace(/[\u4e00-\u9fa5]/g, '').length - 关键点：这类逻辑不能只在提交前运行，必须在
input事件中实时响应，并主动input.value = truncated，否则用户会看到光标跳变或输入被吞
真正难的不是写截断逻辑，而是让截断不破坏用户编辑体验——比如光标位置重置、撤销栈中断、输入法组合状态丢失。这些细节在简单 slice(0, N) 里全被掩盖了。
