maxlength在粘贴和移动端输入时失效，因其仅截断键盘输入，无法拦截Ctrl+V、拖拽或输入法未确认内容；需监听input事件手动截断并处理光标位置，且服务端必须二次校验。
maxlength在粘贴和移动端输入时为什么失效
因为maxlength只是浏览器对键盘按键输入的被动截断机制，不是事件级拦截器。用户Ctrl+V粘贴、拖拽文本、或在iOS/Android输入法“组词未确认”阶段临时输入超长内容时，maxlength不会实时干预——input.value.length可能瞬间超过input.maxLength，表单照样能提交。
常见现象：<textarea maxlength="200"></textarea> 粘贴300字后无提示，光标还能继续移动，校验通过。
- 必须监听
input事件，手动截断：el.value = el.value.slice(0, el.maxLength) - 若需保留光标位置，得配合
el.setSelectionRange()重置（尤其对textarea） - Android 4.4 以前的 WebView 对
textarea的maxlength支持极不稳定，JS兜底是刚需
emoji和生僻汉字导致计数不准怎么办
maxlength 按 UTF-16 code units 计数，不是 Unicode 字符数。绝大多数中文汉字在基本多文种平面（BMP），占 1 个 unit；但辅助平面字符（如 ??、某些古汉字 U+20000 以上）会被拆成两个代理对（surrogate pair），算作 2 个 units —— 导致“明明只输1个emoji，却占了2个长度”。
- 前端无法靠
String.prototype.length准确统计“视觉字符数”，它返回的就是 UTF-16 units 数 - 若业务要求严格按“用户感知字符数”限制（比如评论最多50个emoji+汉字），需用正则或
Array.from(str).length替代str.length - 但注意：
Array.from()在老旧 Android 浏览器中不支持，生产环境建议用Intl.Segmenter或轻量 polyfill - 无论如何，服务端必须用 Unicode-aware 方式（如 Python 的
len(list(unicodedata.normalize('NFC', s)))）重新校验
type="number"等非文本类型写maxlength根本没用
maxlength 对 type="number"、type="date"、type="range"、type="checkbox" 等完全无效。浏览器静默忽略该属性，控制台不报错，开发者容易误以为“写了就起作用”。
立即学习“前端免费学习笔记（深入）”；
-
<input type="number" maxlength="3">用户仍可输入123456789，甚至粘贴任意长数字串 - 数字位数限制应改用：
min/max属性 +input事件中检查parseInt(el.value) > 999并截断 - 日期类字段用
min="2026-01-01"和max="2026-12-31"，别依赖maxlength - 若坚持用文本框模拟数字输入，设
type="text" inputmode="numeric" pattern="[0-9]*"，再配maxlength
minlength不配required等于白写
minlength 只在输入值非空时才触发校验。如果用户清空了输入框，minlength="6" 不会阻止提交——浏览器认为这是“未填写”，而不是“太短”，真正起效的是 required 控制的 valueMissing 状态。
-
<input minlength="6">→ 允许空提交，也允许输 1~5 字（提交时报tooShort） -
<input minlength="6" required>→ 空值报valueMissing，1~5 字报tooShort，只有恰好 6 字才通过 - 框架场景（如 Vue/React）中，手动赋值
el.value = longStr会绕过maxlength，必须同步更新响应式数据并触发校验逻辑 - 所有前端限制都可被禁用 JS 或修改 DOM 绕过，服务端校验不是可选项，是必选项
真正难处理的从来不是怎么写maxlength，而是怎么让它的行为在粘贴、移动端、emoji、框架绑定、服务端之间保持一致。漏掉任一环节，用户就能轻松突破限制。
