字段数≤6且核心字段语义明确时用卡片模式，否则优先横滑；字段超6列须隐藏非关键列、重排HTML顺序、服务端写死data-label；横滑需满足容器overflow-x:auto、table无width:100%或table-layout:fixed、关键字段加text-overflow:ellipsis；卡片事件绑定须依赖data-id而非文本提取。
该转卡片，但前提是字段数 ≤ 6 且核心字段语义明确；否则横滑更稳妥——不是“效果差”，而是卡片模式在字段多、内容长、交互链复杂时会直接破坏数据可读性与操作可靠性。
字段超 6 列时，卡片布局会丢失上下文
移动端卡片本质是把一行 tr 拆成垂直堆叠的 td，每项加 ::before { content: attr(data-label) }。但当原始表格有「订单号、下单时间、收货人、电话、地址、商品名、SKU、数量、单价、实付、状态、操作」共 12 列时，单张卡片高度轻松突破 400px，用户必须反复上下滚动才能比对「商品名」和「实付」，反而比横向滑动更耗操作成本。
常见错误现象：data-label 堆砌导致视觉噪音大；地址字段换行后与「操作」按钮错位；「状态」列颜色样式在卡片中被压缩失效。
- 字段数 > 6 时，优先隐藏非关键列（如用
class="hidden-on-mobile"+@media (max-width: 768px)） - 必须保留的字段，按业务优先级重排 HTML 顺序，卡片只渲染前 6 个
td - 别依赖 JS 动态插入
data-label——服务端或构建时就写死，避免首屏闪动或 SSR 不一致
overflow-x: auto 失效的三个硬性条件
横滑不是“凑合”，而是表格语义的自然延伸。但它只在满足以下三点时才真正可用：
立即学习“前端免费学习笔记（深入）”；
- 外层容器是
display: block，且未被父级overflow: hidden截断（CMS 模板常踩此坑） -
table自身没设width: 100%或table-layout: fixed（后者会让文字强制换行，撑高行高，宽度不可控） - 关键字段（如 ID、URL、JSON）加了
text-overflow: ellipsis+white-space: nowrap+ 显式max-width，否则纯字母数字串会无限撑宽
调试时直接检查浏览器开发者工具里该容器的 computed overflow-x 是否为 auto，而不是看 class 名有没有 table-responsive。
卡片模式下事件绑定必须脱离 DOM 文本提取
原表格点击某行触发编辑，靠 tr[data-id="123"] 绑定。卡片化后 tr 被 display 重置，结构变平，event.target 可能落在 td::before 或内嵌 button 上，再用 innerText 反查「订单号」字段极易出错——比如「¥99.00」被读成「¥99.00操作」。
- 所有卡片元素必须带
data-index或data-id，与原始数据数组索引严格对齐 - 事件代理监听容器，用
e.target.closest('[data-id]')拿 ID，再查originData.find(item => item.id === id) - 禁用任何基于
textContent或innerHTML的字段还原逻辑
真正难的从来不是怎么写 CSS，而是上线前确认：这张表在 iPhone SE（320px 宽）上，用户是否能在不缩放、不误触、不来回滚动的前提下，一眼看清「谁、买了什么、多少钱、能不能发货」——卡片和横滑只是手段，这个目标没达成，代码写得再漂亮也没用。
