maxlength按Unicode码点计数，中英文符号各算1字符；不兼容UTF-8字节数或视觉宽度；JS可绕过但需同步校验；输入法与emoji导致体验偏差，服务端校验不可省。
maxlength属性在中文输入时的实际表现
HTML input 的 maxlength 属性按「字符数」而非「字节数」或「显示宽度」限制，对中文、英文、符号一视同仁。一个汉字、一个英文字母、一个空格都算 1 个字符。这点和后端校验逻辑（如 UTF-8 字节数）常不一致，容易误判超限。
常见错误现象：maxlength="10" 的输入框，用户粘贴一段含全角标点的中文（如“你好，世界！”），看似只有 6 个字，却因逗号、感叹号也是 Unicode 字符而刚好卡在第 10 位——但用户感觉“没输满”，怀疑前端限制不准。
- 浏览器原生行为：所有现代浏览器（Chrome/Firefox/Safari/Edge）均严格按 Unicode 码点计数，
?（U+20BB7，4 字节 UTF-8）也只算 1 个字符 - 不兼容场景：旧版 IE 对代理对（surrogate pair）字符计数有偏差，但 IE 已淘汰，无需兼容
- 注意：
maxlength不影响粘贴内容截断逻辑——超出部分会被自动丢弃，且不触发input事件
textarea与input的maxlength行为完全一致
textarea 和 input[type="text"] 共享同一套 maxlength 实现机制，无差异。区别仅在于换行符处理：用户按 Enter 输入 \n，它被当作 1 个字符计入长度，和字母一样。
使用场景中容易忽略的点：
立即学习“前端免费学习笔记（深入）”；
- 若后端要求「最多 200 字节」，
maxlength="200"无法保证——中文字符可能占 3 字节（UTF-8），200 个汉字实际达 600 字节 - 若需按视觉宽度（如等宽字体下中文占 2 格、英文占 1 格）限制，
maxlength完全无效，必须用 JS 拆解字符串 + 测量或用第三方库 -
textarea中连续换行（\n\n）会快速消耗长度，表单设计时要预留空间
maxlength被JavaScript绕过时的风险
直接修改 input.value 或用 insertAdjacentText 插入内容，不会受 maxlength 约束——这是浏览器规范允许的行为，但会导致 UI 与约束脱节。
典型问题代码：
const input = document.querySelector('input');
input.value = '超长内容超长内容超长内容'; // ✅ 成功赋值，无视 maxlength
input.dispatchEvent(new InputEvent('input')); // ✅ 事件照发，但长度已超标
解决方案不是禁用 JS 赋值，而是同步校验：
- 赋值前用
value.slice(0, maxLength)截断 - 赋值后手动触发
setCustomValidity()提示用户（需配合reportValidity()） - 监听
input事件做实时修正：if (e.target.value.length > maxLength) e.target.value = e.target.value.slice(0, maxLength);
移动端软键盘与maxlength的交互异常
部分安卓输入法（如搜狗、百度）在「全拼」或「五笔」模式下，候选词上屏瞬间可能触发两次 input 事件，导致 maxlength 判断错乱；iOS Safari 在快速连打时偶发跳过截断逻辑。
这不是 maxlength 本身缺陷，而是输入法与浏览器事件调度的竞态问题。务实做法：
- 服务端必须做最终长度校验，前端限制仅为体验优化
- 避免仅依赖
maxlength做关键业务拦截（如用户名注册、短信验证码输入） - 对敏感字段，用
inputmode="text"显式声明输入类型，减少输入法干扰
真正麻烦的是混合中英文加 Emoji 的场景——一个 ?? 国旗 emoji 是两个码点（U+1F1E8 U+1F1F3），maxlength 计为 2，但用户只当它是“1 个图标”。这种语义与技术计数的割裂，只能靠产品提示弥补，没法靠 HTML 属性解决。
