textarea 大小限制需兼顾视觉尺寸与内容长度，resize 依赖 overflow 设置，maxlength 仅限新增字符且易被绕过，须结合 CSS、JS、服务端四层校验。
textarea 的大小限制分两类：视觉尺寸（宽高）和输入内容长度。两者不能混用，也不能只设一个就以为“搞定”了。
为什么 resize: none 写了还是能拖？
不是属性写错了，是它根本没生效。最常踩的坑是：overflow 缺失或被覆盖——CSS 规范要求 resize 只在 overflow 为 auto、hidden 或 scroll 时才起作用，而 textarea 默认是 visible，此时整个声明会被浏览器忽略。
- 验证方法：打开开发者工具 →「Computed」面板 → 搜索
resize，确认最终计算值是不是none；如果不是，说明样式被更高优先级规则吞掉了 - 第三方 UI 库（如 Ant Design、Element Plus）通常把真实
textarea包在div里，类名类似.el-textarea__inner，直接写textarea { resize: none; }根本不匹配 - Bootstrap 4+ 默认写了
textarea { resize: vertical !important; }，你的普通规则权重不够 - 最稳写法是内联：
<textarea style="resize: none; overflow: auto;"></textarea>，不用!important也能生效
maxlength 在 textarea 上为什么有时拦不住？
它能拦，但只拦「新增字符数」，且依赖浏览器实现。用户可能通过粘贴、拖入、IME 未上屏等绕过前端限制，旧版 Safari（iOS 9–10）和部分 Android WebView 甚至会完全忽略该属性。
-
maxlength统计的是 UTF-16 code units（即 JavaScript 中value.length），不是字节数，也不是人眼感知的“字数”：?? 算 4 个，某些生僻汉字算 2 个，\r\n算 2 个 - 服务端返回的初始值若已超限，
maxlength不会自动截断，需手动处理：textarea.value = textarea.value.slice(0, 200) - 富文本编辑器（如 Quill、TinyMCE）包裹的
textarea，实际输入发生在隐藏 DOM 中，原生maxlength失效，得用其内置 API - 必须监听
input和paste事件做 JS 补位，仅靠keydown无法覆盖粘贴场景
怎么安全地控制特定 textarea 而不误伤？
全局重置 textarea { resize: none; maxlength: 200; } 很危险，容易影响日志面板、调试器等需要自由调整的场景。精准控制靠选择器 + 明确作用域。
立即学习“前端免费学习笔记（深入）”；
- 按 class：
.comment-field { resize: none; overflow: auto; }，HTML 中写<textarea class="comment-field" maxlength="200"></textarea> - 按 name：
textarea[name="description"] { resize: none; overflow: auto; } - 按 id：
#bio-input { resize: none; overflow: auto; } - 慎用内联样式——虽然最稳，但不利于复用和维护；若必须用，记得同时写
overflow: auto
移动端和响应式下的特殊注意点
移动端软键盘行为、字体渲染、缩放逻辑都会放大配置偏差，px 和 cols 这类固定单位尤其容易翻车。
-
resize: vertical不等于安全——用户仍可无限拉高，若没配max-height，可能撑破布局；Safari 下甚至因缺少min-width/max-width导致宽度异常 -
cols属性只影响外观，且基于等宽字体假设，在非等宽字体或缩放后失效；现代项目建议用 CSS 的width: 30ch替代 - 高度控制推荐用
min-height/max-height+box-sizing: border-box，避免padding和border算进高度后超限 - 字数提示和截断逻辑建议用
em或rem做单位，比px更适应系统字体缩放
真正难的不是写对某一行 CSS 或 HTML 属性，而是意识到：视觉控制、交互约束、输入拦截、服务端校验这四层必须各自到位，且不能互相假设对方已覆盖——比如不能因为写了 maxlength 就省掉 JS 截断，也不能因为加了 JS 就不设 overflow: auto。
