textarea的maxlength中，\n（LF）算1个字符，\r\n（CRLF）在多数现代浏览器中也按1个字符处理，但旧版Android WebView或IE可能误判为2个；其本质是按UTF-16码元计数，导致换行符影响实际可用字数。
textarea 的 maxlength 怎么算换行符长度
maxlength 对 <textarea> 计数时，\n（LF）算 1 个字符，\r\n（CRLF，常见于 Windows 粘贴内容）在多数现代浏览器中也统一按 1 个字符处理——但旧版 Android WebView 或 IE 可能误判为 2 个。这不是 bug，而是 HTML 规范按 UTF-16 码元计数的必然结果。
实际影响明显：用户粘贴一段含 5 行的文本，即使每行只有 1 个字，value.length 也会多出 4 或 5 个“隐藏长度”，导致提前截断或显示剩余字数不准。
为什么 JS 实时统计和 maxlength 显示不一致
常见现象：<textarea maxlength="150">，JS 用 el.value.length 统计却显示 “149/150”，但用户再按一次回车就输不进去了——因为第 150 位已被 \n 占用。
- 根本原因：浏览器内部校验和 JS 获取的
.length基于同一规则（UTF-16 码元），所以理论上应一致；差异往往来自输入法未上屏、粘贴后未触发input事件、或手动修改了 DOM value 但没同步光标位置 - 移动端尤其明显：微信内置浏览器对 CRLF 处理不稳定，有时把
\r\n拆成两个码元，导致长度多算 1 - 别用
onkeydown判断长度——它在输入法组合阶段就触发，此时value还没更新，数值完全不可靠
如何安全地同步处理换行与长度限制
不能只依赖 maxlength 属性，必须用 JS 主动归一化换行符并实时校验。关键不是“怎么算”，而是“怎么让前后端、JS 和浏览器用同一套逻辑”。
立即学习“前端免费学习笔记（深入）”；
- 统一换行符：监听
input和paste，用value.replace(/\r\n/g, '\n')预处理，避免 CRLF 引入歧义 - 裁剪时用
String.prototype.slice(0, N)，不用正则替换或substr，防止代理对（如 emoji）被截断 - 若需保持光标位置，必须在赋值后调用
el.setSelectionRange(pos, pos)，否则光标会跳到末尾 - 服务端接收后仍要按 UTF-8 字节数校验——因为
maxlength="150"不代表“最多 150 字节”，一个汉字 UTF-8 编码占 3 字节，emoji 可能占 4 字节
textarea 的 maxlength 在哪些场景下会失效
它不是“开关式控制”，而是一个浏览器尽力而为的提示机制。以下情况它完全不生效：
- 用户禁用 JavaScript 后手动改 DOM：
el.setAttribute('maxlength', '999') - 通过
fetch或curl直接发 POST 请求，绕过前端所有限制 - 旧版 Safari（iOS 11 及更早）和部分 Android 4.x WebView 忽略
textarea的maxlength - 输入法处于 composition 状态（如拼音打字中途），
input事件不触发，maxlength也不拦截
真正难的不是写一行 slice()，而是让换行、输入法、粘贴、光标、服务端字节校验全部对齐——少一个环节，用户就会遇到“明明没超限却输不进”或“前端显示 OK，后端报错超长”。
