最小结构为：div.board 包含多个 div.column（含 data-column-id 和 droppable="true"），每列内含 div.card（draggable="true" 且含 data-card-id）；css 用 grid 布局列，禁用 user-select:none，dragstart 设 datatransfer，drop 前需 preventdefault。
用 div + CSS Grid 实现可拖拽看板的最小结构
HTML 本身不提供「看板」语义标签，div 是唯一可靠起点。别用 section 或 article 套壳，它们对拖拽逻辑没帮助，反而干扰 DOM 遍历。
核心结构必须满足三件事：列容器可识别、卡片有唯一标识、拖放目标能被 JS 精确捕获。
- 每列用
<div class="column" data-column-id="todo">，<code>data-column-id后续绑定状态更新 - 每张卡片用
<div class="card" draggable="true" data-card-id="task-123">，<code>draggable="true"是触发原生拖拽的前提 - 列容器必须设
droppable="true"（虽非必需但可提升可访问性），并监听dragover和drop
示例片段：
<div class="board">
<div class="column" data-column-id="todo" droppable="true">
<h3>待办</h3>
<div class="card" draggable="true" data-card-id="task-1">修复登录页样式</div>
</div>
<div class="column" data-column-id="in-progress" droppable="true">
<h3>进行中</h3>
</div>
</div>
为什么不能只靠 flexbox 布局列？
CSS Grid 对列宽控制更稳定，尤其当某列卡片数量极少时，flexbox 容易塌缩或撑满整行，破坏看板视觉节奏。
立即学习“前端免费学习笔记（深入）”；
Grid 还能天然支持响应式断点：用 grid-template-columns: repeat(auto-fit, minmax(300px, 1fr))，比 Flex 的 flex-wrap + min-width 组合更少出错。
- 列间距统一用
gap: 16px，别用margin，避免拖拽时因 margin 折叠导致位置计算偏差 - 卡片内文字换行用
word-break: break-word，否则长任务名会撑破列宽 - 禁用
user-select: none在卡片上——它会阻止拖拽起始，Chrome/Firefox 表现不一致
dragstart / drop 事件里最容易漏掉的两件事
原生拖拽 API 看似简单，但实际落地时 80% 的“拖不动”或“丢数据”问题都出在这两个事件的处理细节上。
-
dragstart中必须调用event.dataTransfer.setData('text/plain', cardId)，只设text/html在 Safari 下失效 -
drop事件里要先event.preventDefault()，否则浏览器默认行为会打开新页面或下载 - 列容器的
dragover也必须preventDefault()，否则drop根本不会触发 - 别在
drop里直接appendChild，先remove()原卡片再插入，否则可能残留 DOM 节点
移动端拖拽失效？不是 HTML 的锅，是 touch 事件没接管
HTML5 原生 draggable 在 iOS 和 Android Chrome 上基本不可用——它依赖鼠标事件，而移动端没有 mousedown。
真要支持触屏，得用 touchstart/touchmove/touchend 模拟拖拽，或引入轻量库如 interact.js。但注意：interact.js 默认开启 autoScroll，在小屏上会导致列表意外滚动，务必关掉。
- 若坚持纯 HTML/CSS/JS，至少给卡片加
cursor: move和touch-action: none，后者防止 touchmove 被浏览器劫持为滚动 - 测试时用真机，模拟器里的 touch 事件行为和真实设备差很多
- 别指望
draggable="true"在微信内置浏览器里工作——它压根不支持
复杂点不在结构，而在拖放状态同步：用户拖着卡片半途切到其他 tab，再切回来，DOM 位置和 JS 状态可能已不同步。这种边界情况，光靠 HTML 搞不定。
