订单详情不能用table做整体布局，因其是垂直流式区块而非二维表结构，强行使用会导致语义错误、响应式失效、读屏器误读及DOM维护困难；仅商品明细子表适用table。
订单详情不是二维结构化数据，table标签不适用——强行用会导致语义错误、响应式失效、屏幕阅读器误读，且后续加状态流转、操作按钮或折叠区域时 DOM 僵硬难维护。
订单详情为什么不能套 table 做整体布局
订单详情页典型包含：订单号+时间（顶部横排）、收货信息（地址+联系人+电话）、商品列表（带图片/规格/价格）、物流进度、支付状态、操作按钮组。这些内容逻辑上是「垂直流式区块」，不是行列对齐的二维表。浏览器和读屏软件会把整个页面识别为一张“10行5列的数据表”，结果就是：“订单号 订单号 订单号”连读三遍，而不是按区块播报。
常见翻车点包括：
-
colspan用于“合并收货信息栏”后，后续tr中列数必须严格对齐，稍错一位就整行错位 - 移动端缩放时，
table-layout: fixed下电话号码被截断，但word-break: break-word对td内纯文本支持不稳定 - 点击“查看物流”需动态插入节点，但
tbody里混着tr和非tr元素会触发渲染异常
真正该用 table 的地方：仅限商品明细子表
订单中「已购买的商品列表」才是合格的二维结构化数据：每行一个 SKU，列含「图片、名称、规格、数量、单价、小计」，可直接复制进 Excel 排序筛选。这时才应启用 table，且必须满足：
- 显式包裹
thead和tbody，否则 Safari 下固定表头滚动失效 - 所有
th加scope="col"，确保读屏器知道“数量”管的是整列 - 图片列用
width固定（如 - 移动端用
@media (max-width: 768px)把tr改成display: block，每行转为卡片，保留role="row"语义
主结构用 dl + div 更自然
订单号、下单时间、支付状态等键值对信息，语义上属于定义列表（definition list），比 table 更精准：
- 订单号
- #20261014001
- 下单时间
- 2026-10-14 13:22
- 支付状态
- 已支付
这样写的好处：
-
dl是 HTML5 原生语义标签，读屏器自动播报“订单号 定义：#20261014001” - 不用操心
colspan对齐，CSS 可直接用display: grid控制两栏间距 - 状态文字（如“已支付”）可单独加类控制颜色/背景，不影响结构
- 后续加「复制订单号」按钮，直接塞进
dd里，无需破坏表格嵌套
收货信息这类多字段区块，用 fieldset 而非 table
收货人、电话、地址、邮编属于一组关联字段，fieldset + legend 是语义最匹配的方案：
关键点：
-
legend被读屏器识别为该组字段的标题，比h3更具上下文意义 - 电话中间掩码用
- 不要给
fieldset设border: none后忽略legend样式——它仍需视觉提示，可用border-top: 2px solid #eee+padding-top: 12px替代
复杂点在于字段动态增减（比如“是否为公司地址”展开后多出税号），这时 table 完全无法支撑，而 fieldset 内部追加 div 毫无压力。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
