resize: both 在 firefox 和旧版 safari 中不显示手柄是规范允许的行为，仅保证拖拽事件触发；需手动添加视觉锚点并绑定 js 拖拽逻辑，移动端应主动禁用。
resize: both 在 Firefox 和旧版 Safari 中不显示手柄，不是 bug，是规范实现差异——它根本没被要求“必须显示 UI”，只保证“拖拽行为可触发”。你不能靠 CSS 修复它，只能绕过它。
为什么 Firefox 不显示 resize 手柄
Firefox（Gecko）从一开始就没实现 resize 的 UI 渲染逻辑，只保留了底层事件支持（resize 事件在 textarea 上仍会触发）。它把“是否画手柄”判定为 UA 样式职责，而 Gecko 的 UA 样式里压根没画。这不是漏加前缀的问题，-moz-resize 不存在，也永远不会存在。
- 写
resize: both+overflow: auto后，Firefox 用户能拖，但看不到任何视觉提示 - DevTools 的 Computed 面板里
resize值是both，但 Elements 面板右下角空空如也 - 别试
::-moz-resize——这个伪元素根本不存在，CSS 规范也没定义它
如何让非 WebKit 用户感知到可拖拽
既然浏览器不画，你就得自己画一个轻量级、跨平台一致的视觉锚点，并绑定真实拖拽逻辑：
- 用
position: absolute在目标元素右下角覆盖一个12px × 12px的div，背景设为三条横线 SVG 或 Unicode 字符☰ - 给它加
user-select: none和pointer-events: auto（父容器可能设了none） - 监听
mousedown+mousemove，读取鼠标位移，动态更新目标元素的width和height - 避免直接监听
resize事件做 UI 反馈——它在 Firefox 中不冒泡，在 Safari 移动端根本不会触发
textarea 上 resize 失效的隐蔽原因
即使写了 resize: both，textarea 在 Safari 15.6–16.x 和部分 Android WebView 中仍不响应拖拽，常见于以下组合：
-
textarea父容器有transform: translateZ(0)或will-change: transform—— Safari 会切断 resize 区域捕获 -
textarea自身设置了width: 100%且父容器无明确width—— Safari 认为“尺寸不可控”，静默禁用 - CSS 中用了
min-width: max-content或fit-content—— 这些值在旧 Safari 中解析为 invalid，导致整条规则被丢弃
验证方式：在 Safari DevTools 中选中 textarea → Computed → 搜索 resize，确认值是 both；再手动拖右下角，看 clientWidth 是否变化。
移动端必须主动降级
iOS Safari 和所有 Android 浏览器（包括 Chrome for Android）完全禁用 resize 的 UI 和交互——不是样式问题，是内核层移除了该能力。试图检测 matchMedia('(hover: hover)') 并不靠谱，因为 iPadOS 会返回 true 却依然不支持。
- 用
@media (pointer: coarse)或@media (max-width: 768px)直接设textarea { resize: none; } - 配合 JS 检测：
if ('ontouchstart' in window || navigator.maxTouchPoints > 0) { /* 禁用 resize UI */ } - 别依赖
resize做关键功能分支——比如编辑器分栏，移动端应默认切为 tab 切换或垂直堆叠
最易被忽略的一点：你在 PC 上调试时看到 Chrome 手柄正常，不代表逻辑可靠；Firefox 不画手柄、Safari 在某些嵌套结构里静默失效、移动端全链路砍掉——这些不是边缘 case，而是 resize 属性的固有边界。把它当开关用，别当 UI 组件用。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
