maxlength属性是限制文本框输入长度最直接的html原生方案，适用于text、email、textarea等文本类元素，浏览器自动拦截超长输入，但不防粘贴绕过，且服务端必须二次校验。
用 maxlength 属性做前端基础限制
最直接的方式是给 <input> 或 <textarea></textarea> 加 maxlength 属性，浏览器会自动截断超出的输入。它不依赖 JavaScript，兼容性好（IE10+），且对用户有即时反馈。
常见错误是只加了 maxlength 就以为校验完成了——它只防误输，不防绕过（比如粘贴超长文本、开发者工具改 DOM、或直接发请求）。
-
maxlength对<input type="number">无效，数字输入框不支持该属性 - 中文、emoji、组合字符（如带声调的字母）在不同浏览器中计数可能不一致：多数现代浏览器按 Unicode 码点计数，但旧版 Safari 对某些 emoji 会算作 2 个字符
- 如果后端也做了长度校验，前后端的计数逻辑必须一致，否则用户看到“已输入 50/50”，提交却报错“超出 50 字符”
用 input 和 keydown 事件做实时字数提示与拦截
仅靠 maxlength 不够直观。加一个实时字数提示（如“还剩 3 个字符”）能提升体验，而用 JavaScript 拦截粘贴或拖入的超长内容，则能补上前者漏洞。
关键点在于事件选择：input 事件覆盖粘贴、剪切、拖放、语音输入等所有变更场景；keydown 可用于阻止按键输入（比如按住 Shift+Enter 连续输入），但无法捕获粘贴。
- 不要监听
keyup来做截断——用户松手时内容已写入，再删就晚了 - 对
<textarea></textarea>做长度检查前，先用.value.replace(/\r\n/g, '\n')统一行尾符，避免 Windows 换行符被多算 1 字符 - 显示剩余字数时，建议用
textContent而非innerHTML，防止 XSS（尤其当最大长度来自服务端动态注入）
后端必须校验，且逻辑要和前端一致
前端校验只是用户体验优化，不能替代后端。只要接口可被直接调用（比如通过 cURL、Postman 或脚本），maxlength 和 JS 拦截就完全失效。
后端校验出错时，返回的错误信息应明确指出是哪个字段、超了多少字符，而不是笼统的“参数错误”。同时注意：
- 数据库字段长度（如 MySQL 的
VARCHAR(50)）是字节数还是字符数？UTF8MB4 下一个 emoji 占 4 字节，但算作 1 字符 - Node.js 的
String.length、Python 的len(s)、Java 的s.length()都按 Unicode 字符计数，和现代浏览器一致；但 PHP 的strlen()默认按字节计，需用mb_strlen($s, 'UTF-8') - 如果用了 ORM（如 Django ORM 或 TypeORM），确认其模型字段的
max_length是否参与运行时校验，还是仅用于生成 DDL
特殊字符处理：中文、emoji、全角标点的实际长度
用户输入 “你好?！” 在大多数环境下是 4 个字符，但若后端用字节长度判断（如未指定编码的旧系统），可能返回 10+ 字节，导致校验失败。
真正需要关注的是业务语义上的“长度”：微博限制 140 字，指的是 Unicode 字符数；短信平台限制 70 字，通常指 GBK 字节数。必须和产品、后端对齐定义。
- 测试时别只输英文，至少覆盖：纯中文、中英混排、带 emoji 的句子、全角逗号句号、零宽空格（
\u200B）、连字符（\u2013） - 正则
/[\uD800-\uDFFF]./g可检测代理对（surrogate pairs），用于识别 emoji 是否被拆开，但现代 JS 引擎大多已正确处理.length - 如果业务要求“按视觉宽度计数”（如等宽字体下中文占 2 格、英文占 1 格），那就不是标准字符长度校验了，得另起一套度量逻辑
String.length，一个按 Buffer.byteLength(str, 'utf8')，上线后就会卡在某个 emoji 上。前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
