textarea默认支持拖拽，resize: both属冗余声明；限制方向需配合width/height控制；失效常见于样式覆盖或overflow:hidden；移动端及旧IE兼容性差，需JS降级处理。
textarea 默认就能拖拽，resize: both 是冗余写法
现代浏览器（Chrome、Firefox、Safari、Edge）给 textarea 设了默认样式 resize: both 和 overflow: auto，所以右下角那个拖拽把手天然存在——你什么也不写，它 already works。加 resize: both 不报错，但属于重复声明，没实际作用。
想只允许调宽度或高度？用 resize: horizontal 或 resize: vertical
这两个值确实能限制方向，但要注意：它们仍会显示拖拽把手，用户依然可以拉伸，只是被锁定了轴向。
-
resize: horizontal→ 宽度可变，高度固定（但需配合height/max-height才真正稳住） -
resize: vertical→ 高度可变，宽度固定（同理，width或max-width得设上） - 别指望靠它“半禁用”——只要把手还在，就可能撑破布局，尤其在弹性容器或模态框里
为什么写了 resize: both 却没反应？检查三个硬性前提
resize 不是万能开关，它生效必须同时满足：
- 元素
display必须是block或inline-block（textarea默认就是block，没问题） -
overflow不能是visible（textarea默认overflow: auto，也没问题） - 样式必须真正应用到该元素上——常见失效点：
textarea被 UI 框架（如 Bootstrap）的更高级选择器覆盖；或父容器设置了overflow: hidden把把手裁掉了
移动端和旧浏览器支持情况要心里有数
resize 属性在 iOS Safari 上稳定可用，但部分 Android WebView（尤其是 Android 4.x–6.x 的系统 WebView）会忽略它，表现为拖拽把手不出现、或拖了没响应。
立即学习“前端免费学习笔记（深入）”；
- IE ≤10 完全不支持，直接无视该属性
- 如果你的项目仍需兼容这类环境，得 fallback 到 JS 监听
mousedown+preventDefault，但代价是失去原生流畅感 - 真机测试比模拟器靠谱；别只看 Chrome DevTools 的响应式模式
textarea 的 scrollHeight 和 clientHeight 会实时变化，但它的 value 长度、换行逻辑、光标位置不受影响——这意味着你如果用 JS 做自动高度同步，得监听 input 和 resize 两个事件，否则用户拖完再打字，高度又会错位。 
