resize: none是唯一真正禁用textarea拖拽的方式，但必须显式设置overflow为auto或hidden，且样式需作用于真实textarea元素，否则因优先级覆盖、封装结构或WebKit内核限制而失效。
resize 属性是唯一能直接控制 textarea 用户拖拽缩放行为的 CSS 方式，但它不是万能开关——不加条件地写 resize: none; 很可能失效。
为什么 resize: none; 有时没用
浏览器（尤其是 Chrome/Safari）对 textarea 的默认 resize 值是 both，但这个行为受两个隐性前提约束：
- 元素必须有明确的
overflow计算值（比如overflow: auto;或overflow: hidden;），否则部分 WebKit 内核浏览器会忽略resize设置 - 样式必须作用到真实渲染的
textarea元素上，而不是父容器或封装组件内部的 wrapper - 第三方 UI 库（如 Element Plus、Ant Design）通常把
textarea包在一层<div>或自定义 class 里，直接写textarea { resize: none; }会被层叠优先级更高的库样式覆盖
Element Plus / Ant Design 等组件库中怎么禁用缩放
这类库不会暴露原生 textarea 标签，而是用 class 封装。以 Element Plus 为例，实际可编辑区域是带 .el-textarea__inner 类的 textarea 元素：
- 全局禁用：在项目主 CSS 中添加
.el-textarea__inner { resize: none !important; }，!important是必须的，因为 Element Plus 自带resize: both; - 局部禁用（Vue SFC）：
<style scoped> .el-textarea__inner { resize: none; } </style>，注意 scoped 模式下需确保该样式文件加载顺序在 Element Plus 样式之后 - 内联写法（不推荐）：
<el-input type="textarea" style="resize: none;"></el-input>—— 这个无效，因为style绑定在父el-input上，不透传到内部textarea
resize 的四个合法值和实际表现差异
resize 只对设置了 overflow 且非 visible 的块级可替换元素生效（textarea 是特例，天生支持）：
-
none：完全隐藏右下角缩放手柄，用户无法拖拽——这是唯一真正“禁用”的方式 -
vertical：只显示垂直方向手柄，但用户仍可拉高破坏布局；很多人误以为“没横向就安全”，其实高度失控更常见 -
horizontal：仅允许改宽度，对textarea几乎无意义，因多数场景需固定宽度 -
both：默认值，Chrome/Safari 显示斜向双箭头手柄；Firefox 默认不显示手柄但依然响应拖拽（需配合overflow才生效）
容易被忽略的兼容性和副作用
resize 是 CSS3 UI 模块属性，所有现代浏览器都支持，但有两个冷知识：
- 它**不触发重排（reflow）**，只影响渲染层的手柄显示和拖拽逻辑，所以加了
resize: none;不会影响性能 - 它**不影响滚动行为**：即使禁用了缩放，
textarea内容超出时仍会按overflow-y行为显示滚动条，二者完全解耦 - 移动端 Safari 对
resize支持有限，iOS 16+ 才稳定支持none，旧版本即使写了也会显示手柄（但拖拽无效）
最常漏掉的一点：禁用缩放后，如果没同步设置 min-height 或 height，用户首次聚焦时可能看到一个过矮的框体——这不是 resize 的问题，而是你忘了控制基础尺寸。
