maxlength 是限制输入长度最常用可靠的方式，适用于 text、email、password 和 textarea，浏览器原生截断且兼容性好，但对 number 无效，前后端需统一字符数校验标准。
用 maxlength 属性直接限制输入长度
这是最常用也最可靠的方式，适用于 <input type="text">、<input type="email">、<input type="password"> 和 <textarea>。浏览器会在用户输入时实时截断超出部分，且提交时不会发送超长内容。
注意：maxlength 对 <input type="number"> 无效（数字输入框不按字符计数），对 <input type="search"> 有效，但某些旧版 Safari 在粘贴时可能绕过限制。
示例：
<input type="text" maxlength="20"> <textarea maxlength="100"></textarea>
为什么 maxlength 比 JavaScript 截断更值得优先使用
JavaScript 手动监听 input 或 keydown 并截断字符串，看似灵活，实则容易漏掉边界情况：粘贴、拖入文本、IMF 输入（如中文拼音上屏）、剪贴板 API 调用等。而 maxlength 是原生行为，由浏览器统一处理，兼容性好（IE10+、所有现代浏览器均支持），且无需额外脚本。
立即学习“前端免费学习笔记（深入）”；
只有在需要「显示实时字数提示」或「区分字节数与字符数」（如短信计费）时，才需配合 JS 补充逻辑，而非替代 maxlength。
- 不要用
oninput="this.value = this.value.slice(0, 20)"替代maxlength - 避免在
keydown中阻止按键——会干扰组合键（如 Ctrl+V、Alt+Shift+Tab） -
maxlength值为数字，写成maxlength="5"，不是maxlength="five"
textarea 的 maxlength 和换行符的坑
<textarea> 中的换行符在不同系统下占位不同：Windows 用 "\r\n"（2 字符），macOS/Linux 用 "\n"（1 字符）。但 maxlength 统一按 Unicode 码点计数，"\r\n" 算作 2，"\n" 算作 1——这和你在 JS 中调用 value.length 的结果一致，无需额外转换。
真正容易出错的是后端校验没同步这个规则：如果后端用字节长度（如 UTF-8 编码后长度）做限制，而前端只靠 maxlength，就可能出现「前端没拦住、后端报错」的情况。所以前后端必须约定清楚是按字符数还是字节数校验。
- 前端
maxlength="200"→ 后端也应以 Unicode 字符长度 ≤ 200 校验 - 若后端必须按 UTF-8 字节限制（如数据库字段为
VARCHAR(200)），前端需用 JS 预估字节数（如new TextEncoder().encode(str).length），但此时maxlength已不够用，得降级为 JS 控制 - 移动端软键盘的「换行」键在
<textarea>中插入"\n"，在<input>中通常被忽略
表单提交前用 JS 做二次校验的必要场景
当业务要求比单纯字符数更复杂时，比如「至少包含 1 个数字 + 1 个大写字母」、「禁止连续 3 个相同字符」、「中英文混合时按字节数限制」，就不能只靠 maxlength。这时应在 submit 事件中检查 form.checkValidity() 结果，并手动添加 setCustomValidity() 错误信息。
关键点是：JS 校验不能代替 maxlength，而是叠加在其之上。否则用户可能输入超长内容后，直到点击提交才发现错误，体验更差。
- 始终保留
maxlength作为第一道防线 - 在
submit处理函数里先调用event.preventDefault()，再检查逻辑规则 - 用
input.setCustomValidity("密码需含数字")触发原生提示，比弹 alert 更符合表单习惯 - 不要仅依赖 JS 校验——它可被禁用或绕过，后端必须有完整等效校验
maxlength 就够了；剩下那 10%，问题往往不出在怎么写，而出在前后端对“长度”的定义是否真正对齐。 
