CSS框架不提供拖拽逻辑，仅负责样式与布局；拖拽需结合原生draggable属性、事件及JS实现，Tailwind等原子化框架易被误认为支持拖拽，实则仅辅助视觉构建。
拖拽组件在CSS框架里根本不是“框架的事”
绝大多数 CSS 框架（如 Bootstrap、Tailwind、Bulma）本身不提供拖拽逻辑，它们只负责布局和样式。所谓“用 CSS 框架实现拖拽布局适配”，本质是：用框架的栅格或 flex/grid 工具控制容器结构，再靠原生 draggable 属性 + dragstart/drop 事件 + 框架类名做视觉反馈。框架只管“长得像”，拖拽行为必须自己写 JS。
为什么 Tailwind 用户容易误以为它支持拖拽
Tailwind 因为高度原子化，常被拿来配合第三方库（如 react-dnd 或 interact.js）快速搭建拖拽区域。但注意：flex、grid-cols-4、min-h-screen 这些类名只是让容器“能装下拖拽目标”，并不触发任何拖拽行为。常见错误包括：
- 给
div加了class="flex grid-cols-3 draggable"，但没设draggable="true"—— 浏览器根本不识别 - 用
transition-all duration-200做拖拽动画，结果发现拖动时元素跳变 —— 因为没禁用默认ghost image，也没用event.dataTransfer.setDragImage()替换 - 在响应式断点里切换
grid→flex-col，但拖拽目标的order或grid-row没同步重算 —— 移动端顺序错乱
Grid 布局下拖拽排序最易踩坑的参数
用 CSS Grid 实现卡片拖拽排序时，order 属性看似简单，实则受 display: grid 容器的 grid-auto-flow 影响极大。Chrome 和 Firefox 对 grid-row-start 的内联设置解析也不一致。
-
grid-auto-flow: row（默认）时，order有效；设成column或dense后，order可能被忽略 - 直接写
style="grid-row: 2 / 3"在 Firefox 下可能失效，应改用grid-row-start: 2; grid-row-end: 3 - 拖拽过程中临时插入占位符（placeholder）时，别用
visibility: hidden—— 它仍占网格轨道；改用height: 0; overflow: hidden; padding: 0
移动端拖拽适配的关键不是 media query
移动端真正在意的不是屏幕宽度，而是 touch 事件与滚动冲突。例如在 overflow-y: auto 的容器里拖拽，手指一滑就触发页面滚动，拖拽直接中断。
立即学习“前端免费学习笔记（深入）”；
- 必须在
touchstart时调用ev.preventDefault()，但仅限拖拽目标元素，不能全局阻止 —— 否则页面无法滚动 - 用
position: fixed做拖拽浮层时，iOS Safari 会丢失transform动画帧率，建议降级为top/left+will-change: transform - 不要依赖
dragover判断落点位置 —— 移动端该事件触发不稳定；改用touchmove+elementFromPoint()实时查目标
真正难的从来不是“怎么拖”，而是拖完之后状态怎么存、跨设备怎么同步、DOM 顺序和视觉顺序不一致时用户是否感知到断裂 —— 这些都得跳出 CSS 框架去解决。
