maxlength仅对（type为text、search、password、email、tel）和有效，按utf-16码元计数，非安全机制，后端必须二次校验。
直接用 maxlength 属性就行，但必须写对位置、类型和拼写，否则完全不生效。
哪些元素支持 maxlength？
只对表单控件有效：<input type="text">、<input type="search">、<input type="password">、<input type="email">、<input type="tel"> 和 <textarea></textarea>。其他标签（比如 <div>、<code><span></span> 或带 contenteditable 的元素）加了也无效。
常见错误现象：
- 写成
max-length或maxLength—— 浏览器直接忽略 - 加在
<input type="number">上 —— 该类型不支持maxlength，数值输入逻辑不同 - 移动端用
type="number"却指望它响应maxlength—— 它根本不处理字符截断
maxlength 怎么计数？中英文、换行、emoji 都算几个？
按 UTF-16 码元（code unit）计数，不是字节，也不是“人眼看到的字数”。
这意味着：
- 一个汉字（如“你”）通常占 1 个码元 → 算 1 个字符
- 一个 ASCII 字符（如“a”）也占 1 个码元 → 算 1 个字符
- 一个换行符
\n算 1 个字符（<textarea></textarea>里粘贴带换行的内容时要注意） - 大多数 emoji（如 ??）属于辅助平面，占 2 个码元 →
maxlength="10"时，输入 5 个 ?? 就满了
所以如果后端要求的是“UTF-8 字节数 ≤ 32”，maxlength="10" 完全无法对应——必须服务端重新校验字节长度。
为什么写了 maxlength 却没拦住超长输入？
表面看是前端失效，实际往往是以下几种情况之一：
- 用了 React/Vue 等框架的受控组件，却只设了
maxLength属性，没在onInput或@input里手动截断 → 框架会覆盖原生截断逻辑 - 用户粘贴了一段超长文本，老安卓 WebView（4.4 之前）或某些定制内核对
<textarea></textarea>的粘贴截断支持不稳定 - 测试时用开发者工具临时删掉了
maxlength属性，误以为“浏览器没起作用” - 后端返回的错误提示让人误以为是前端没拦住，其实是后端自己没校验，把超长内容存进数据库时报错了
记住：maxlength 是用户体验层的友好拦截，不是安全机制。只要删掉属性、禁用 JS 或发个 curl 请求，就能绕过。
什么时候必须放弃 maxlength 改用 JavaScript？
遇到这些真实需求时，原生属性就撑不住了：
- “用户名最多 12 字，但含英文时放宽到 20 字符” → 需要动态判断字符类型
- 要过滤空格、制表符、emoji 或控制字符 →
maxlength不做内容清洗 - 需要实时显示“还剩 X 字”，且兼容 IE9–（
maxlength在 IE9 不支持<textarea></textarea>） - 字段允许富文本粘贴（比如从 Word 复制带样式的文字），需剥离 HTML 标签后再计数
实操建议：监听 input 事件（不是 keyup），用 .slice(0, N) 截断，避免用正则替换导致代理对错乱；React 中优先用 maxLength + onInput 手动 event.preventDefault() 和重置 value。
最常被忽略的一点：无论你前端做了多严密的限制，后端收到数据后，必须用自己语言的标准库（如 Python 的 len(text)、Node.js 的 Buffer.byteLength(str, 'utf8')）重新计算并校验——这是唯一不可绕过的防线。
