resize 不更新 css 变量，因它是纯渲染层行为，只改内联 width/height，不触发事件或同步 --panel-width；需在 mouseup 时用 offsetwidth 读取并 setproperty 写入变量。
resize 属性本身不更新 CSS 变量，必须用 JS 主动读取并写入，否则依赖 --panel-width 的布局不会响应变化。
为什么 resize 改了尺寸，但 var(--panel-width) 还是旧值？
CSS 的 resize 是纯渲染层行为：它直接修改元素的内联 style="width: 320px"，不触发任何事件，也不通知 JS。浏览器不会自动把新宽高同步到自定义属性。你调用 getComputedStyle(el).getPropertyValue('--panel-width') 拿到的仍是初始值或上一次 JS 写入的值，不是当前真实尺寸。
常见错误现象：
- 面板拖完变宽了，但右侧区域没收缩（因为
calc(100% - var(--panel-width))没更新） - 用
MutationObserver监听style变化 —— 太重，且 resize 写的是像素值，频繁触发不可控 - 监听
window.resize—— 这是窗口大小变化事件，和元素resize完全无关
mouseup + offsetWidth 是最轻量可靠的同步时机
用户松手那一刻才是尺寸确定的稳定点，此时读取最准、开销最小。不要在拖拽中轮询或用 requestAnimationFrame 频繁读取 —— 既没必要，又可能因重排造成卡顿。
实操建议：
- 只监听目标元素的
mouseup，不是document全局 - 用
element.offsetWidth（带边框），比getBoundingClientRect().width更快，且避开四舍五入误差 - 写入时用
element.style.setProperty('--panel-width', w + 'px')，确保作用域局部、不污染全局 - 如果面板有
min-width或max-width，先读getComputedStyle(element).minWidth做校验，避免变量值超出合法范围
textarea 能省掉 JS 吗？别被表象骗了
textarea 确实原生支持 resize 并触发 input 事件，但它的语义和行为与布局容器冲突：
-
input事件在拖拽过程中连续触发，频率高，容易引发重绘抖动 - 它默认可聚焦、可输入、有换行逻辑，需加
readonly、user-select: none、border: none等掩盖，代码反而更重 - 无法控制拖拽方向（比如只允许水平拉伸），
resize: horizontal在部分浏览器仍可能被垂直触发 - 一旦后续要加拖拽移动、等比缩放、边界限制等功能，
textarea就彻底不适用，得重写
所以除非是极简内部工具、且只用 textarea 当占位器，否则不如从一开始就用 div + 明确的 JS 同步逻辑，扩展性更好。
伪元素放大 resize 区域时，别忘了 overflow 和 display 约束
想让整个右边栏边缘都可拖拽，常通过 ::-webkit-scrollbar 放大滚动条交界处来间接扩大 resize 手柄。但这个技巧有硬前提：
-
overflow必须是auto、scroll或hidden，visible下resize完全失效 - 元素不能是
inline或inline-block，至少要是block、flex子项或grid子项 -
::-webkit-scrollbar仅在 Chromium/WebKit 内核生效；Firefox 不支持该伪类，需 fallback 到 JS 方案或接受其垂直方向限制 - 放大后若手柄超出父容器，可能遮挡相邻元素，需用
z-index和pointer-events: none配合微调
真正难的不是让拖拽“能用”，而是让变量同步“不掉帧”、边界校验“不越界”、多方向缩放“不打架”。这些细节一旦漏掉，用户一拉就错位、卡死或崩溃，比不用 resize 还糟。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
