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 里，直接写 <code>textarea { resize: none; } 会被层叠优先级更高的库样式覆盖

  Element Plus / Ant Design 等组件库中怎么禁用缩放

  这类库不会暴露原生 textarea 标签，而是用 class 封装。以 Element Plus 为例，实际可编辑区域是带 .el-textarea__inner 类的 textarea 元素：

  

  Wechat HTML Publisher

  直接上传HTML富文本到微信公众号草稿箱。支持完整的HTML格式,无需Markdown转换。

  下载
  • 全局禁用：在项目主 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 的问题，而是你忘了控制基础尺寸。