maxlength 属性原生支持 input 和 textarea 的字符数限制，浏览器层面拦截输入，避免闪烁问题；需注意拼写正确、仅适用于表单元素，且后端必须重复校验。
input 和 textarea 的 maxlength 属性直接生效
HTML 原生就支持字符数限制，maxlength 是最简单也最可靠的方案。它在浏览器层面拦截输入，用户根本输不超——不是靠 JS 监听后截断，所以不会出现“先闪一下再删掉”的闪烁问题。
常见错误现象：textarea 用了 maxlength 却没生效？大概率是写成了 max-length 或 maxLen 这类拼写错误；或者加在了 div、span 这类非表单元素上。
-
input类型（如text、email、search）全部支持maxlength -
textarea同样支持，且对换行符（\n）计为 1 个字符，和大多数后端校验逻辑一致 - 不支持
contenteditable元素或自定义组件，那些得靠 JS 补位 - 移动端软键盘会自动适配：当达到
maxlength时，iOS/Android 输入法通常禁用输入键
用 JavaScript 监听 input 事件做二次控制
原生 maxlength 够用，但有些场景必须用 JS：比如要动态调整上限、要显示实时字数、要兼容老版本 IE（IE9–），或者字段内容含富文本（如带格式的粘贴）。
关键点在于监听时机：input 事件比 keyup 更可靠，能捕获粘贴、拖入、语音输入等所有变更；而 change 只在失焦时触发，完全不适合实时限制。
立即学习“前端免费学习笔记（深入）”；
- 别用
onkeypress或onkeydown拦截——它们无法处理右键粘贴、拖放文本、IME 输入 - 截断逻辑建议用
el.value = el.value.slice(0, limit)，而不是正则替换，避免误删 emoji 或代理对（如 ?? 占 2 个 UTF-16 码元，但算 1 个字符） - 如果用了框架（React/Vue），注意不要在受控组件里直接改
value再触发重渲染，容易卡顿；优先用maxLength属性 +onInput校验
后端必须重复校验，不能信前端传来的长度
前端限制只是用户体验优化，攻击者删掉 maxlength 属性或发个 curl 请求就能绕过。后端收到数据后，必须重新计算字符长度，并按业务规则拒绝超长请求。
容易踩的坑是混淆“字节长度”和“字符长度”。例如 Python 的 len(text) 返回 Unicode 字符数（正确），但 len(text.encode('utf-8')) 返回字节数（可能翻倍）。MySQL 的 VARCHAR(255) 是按字符计，不是字节。
- PHP 用
mb_strlen($str, 'UTF-8')，不是strlen() - Node.js 用
text.length即可（JS 字符串是 UTF-16，但.length对绝大多数 emoji 和中文返回正确字符数；极少数代理对需用[...text].length） - 数据库字段定义要留余量：比如前端限制 200 字，后端字段至少设为
VARCHAR(255)，避免因编码转换或特殊符号导致截断
textarea 高度自适应时，maxlength 依然有效但视觉易误导
很多项目会给 textarea 加自动增高逻辑（比如监听 input 后设 scrollHeight），这时候用户容易以为“拉到底还能打”，其实 maxlength 早拦住了——只是滚动条没消失、光标还能跳到末尾，造成“好像没限制”的错觉。
解决方法不是关掉自适应，而是加视觉反馈：比如在右下角实时显示「还剩 12 字」，或到上限时让边框变红、禁用提交按钮。
- 别用
rows属性控制高度——它只影响初始行数，和字符限制无关 - 用
resize: none配合自适应更稳妥，避免用户手动拖大后误判容量 - 移动端 Safari 对
textarea自适应支持不稳定，建议 fallback 到固定高度 + 显示字数提示
maxlength，而是前后端对“一个字符”的定义是否统一，以及用户粘贴进来的那段文字，到底算几个字符。 
