resize: both仅控制拖拽交互，手柄样式和位置由浏览器UA决定且不可自定义；其生效需overflow为auto/scroll/hidden，并受父容器transform、固定尺寸及移动端Safari限制。
resize: both 在不同浏览器里显示的手柄样式、位置、是否可拖拽，根本不是 bug，而是各内核的 UA 实现差异——你没法“统一它”，只能控制它是否出现、在哪出现、是否生效。
为什么 textarea 右下角手柄在 Chrome/Firefox/Safari 里长得不一样？
这不是 CSS 层面能改的。Chrome（Blink）和 Firefox（Gecko）用各自 UA 样式绘制 resize 手柄，Safari（WebKit）甚至默认不显示手柄（只保留拖拽逻辑）。它们不共享同一套 UI 组件，也不响应 ::-webkit-resize 这类伪元素（该伪类不存在）。所以你看到的三条横线、小方块、或干脆没图标，都是浏览器自己决定的。
关键点在于：resize 是交互行为控制属性，不是视觉样式属性。它的作用只是“允许/禁止用户拖拽”，图标的渲染完全由 UA 控制，且不可 CSS 定制。
resize: both 失效的常见原因和验证方式
即使写了 resize: both，手柄也可能不出现或无法拖拽。排查顺序如下：
-
overflow值不是auto、scroll或hidden——resize要求元素必须有“可溢出内容”的上下文，overflow: visible直接禁用该功能 - 父容器设置了
transform、will-change或contain: layout，会创建新层叠上下文并截断 resize 区域（尤其在 Safari 中） - 元素本身设置了
width和height为固定值（如100px），部分浏览器（如旧版 Safari）会忽略 resize 行为 - 移动端 iOS Safari 完全不支持
resize的 UI 手柄（即使写了both，也看不到图标，也无法拖拽）
验证是否生效：在 Chrome DevTools 中选中元素 → 查看 Computed 面板 → 搜索 resize，确认值是 both；再手动拖拽右下角，看尺寸是否变化。
如何让 resize 行为更可控、更少意外？
放弃“让它看起来一样”的想法，转而聚焦“让它行为一致”：
- 始终显式设置
overflow: auto（而不是visible或留空），这是resize生效的前提 - 对
textarea等表单控件，加min-width/min-height而非固定尺寸，避免 Safari 拒绝 resize - 用
@media (max-width: 768px)主动关掉移动端的resize：textarea { resize: none; }，因为 iOS 不支持，留着反而误导用户 - 如果业务强依赖拖拽调整，且需跨平台一致体验（比如代码编辑器），别靠原生
resize，直接上 JS 方案（如interact.js或自定义 resize handle +resizeObserver）
resize: both 和 resize: none 在表单场景下的取舍逻辑
很多团队误以为 “禁用 resize 就是加 resize: none”，但实际要考虑语义和辅助功能：
-
textarea默认可 resize 是 WCAG 推荐行为（允许用户按需扩大输入区域），盲目设none可能降低可访问性 - 若 UI 要求严格尺寸控制（如卡片内嵌小文本框），则
resize: none+min-height: 80px+max-height: 120px更稳妥 - 注意 Safari 对
resize: vertical支持不稳定，horizontal在多数浏览器中基本无效，别依赖 - 真正要隐藏手柄又保留拖拽能力？做不到。手柄和行为是一体的，禁用视觉即禁用交互
最常被忽略的一点：你在 SCSS 里写 @include responsive-textarea { resize: both; }，但如果这个 mixin 被 import 在 normalize.css 之后，某些 UA 样式可能已通过更高权重覆盖了你的声明——检查 computed style 里的来源，比猜更可靠。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
