必须用仅当展示行列交叉有明确含义的二维结构化数据，如比价表、出勤统计、参数对照表；其他场景应选用语义正确的配合Flex或Grid布局。
别用 适合 PC 端固定列数（如 4 列商品）、平板 2 列、手机 1 列，且各项目宽度一致、高度接近的场景。 关键不是“能铺开”，而是 将 Markdown 文章转换为微信公众号兼容的纯 HTML 格式。当用户要求"转成微信格式"、"生成公众号文章 HTML"、"排版到微信草稿箱"、"微信粘贴格式"时触发。输出带内联样式的纯 HTML，微信编辑器可直接渲染，无需额外适配。支持标题、段落、列表、粗体、行内代码、表格、引用块、代码块、配图的完整转换。 当商品标题字数差异大、描述行数不一、或要插入“缺货角标”“促销 banner”等非统一结构时， 不用 最容易被跳过的点是：键盘 Tab 导航顺序。Flex/Grid 布局下，DOM 顺序 ≠ 视觉顺序，若 HTML 结构是“图-标题-价格-按钮”，但 CSS 把按钮提到了标题上方，键盘用户仍按 DOM 顺序聚焦——这会导致操作断层。解决办法只有一个：保持 HTML 结构与视觉逻辑一致，靠 CSS order 调整是陷阱。<table> 做“商品列表”“卡片流”或“响应式数据展示”——它不是语义错误那么简单，而是直接卡死后续所有交互、可访问性和维护空间。
<h3>什么时候必须用 <code><table>？
<p>只有当你在表达<strong>真正的二维关系数据</strong>时才该用：<code><table>。比如：某型号手机在不同电商平台的实时比价表、某课程各班级的出勤率统计（行=班级，列=周次）、医疗器械参数对照表（行=设备，列=指标）。
<ul>
<li>检查标准：能否把数据画成「行列交叉有明确含义」的矩阵？如果每行只是独立商品/用户/订单，就不是</li>
<li>HTML 验证器会警告 <code><table> 里嵌套 <code><div> 或滥用 <code>colspan/rowspan —— 这往往是语义错位的信号
<table> 会严格按「第X行第Y列」播报，若内容实际是卡片堆叠，听感完全混乱
<h3>
<code>display: grid 处理等宽列数据表格
grid-template-columns: repeat(auto-fill, minmax(240px, 1fr)) 这句——它让浏览器自动计算最多能塞几列，不靠媒体查询硬切。
minmax(240px, 1fr)：单列最小 240px，剩余空间均分；小屏下自动缩为 1 列，不会溢出auto-fill vs auto-fit：前者保留空列占位（防最后一行左对齐），后者收缩空列；多数情况选 auto-fill
grid，若需兼容，得加 display: flex fallback，并用 @supports (display: grid) 包裹 grid 规则
display: flex 处理高度不一的流式表格flex 比 grid 更容错。
flex-wrap: wrap，否则所有子项强行挤在一行，溢出隐藏或横向滚动flex: 1 1 240px（可伸缩、可折行、基准宽 240px），而不是 width: 240px —— 否则小屏无法自适应压缩justify-content: space-between 在 flex 中对最后一行无效；更稳方案是改用 grid，或用伪元素 ::after 补空白项-webkit-gap 前缀，gap 属性本身不兼容 IE语义和辅助功能不能靠“看起来像”
<table> 不等于可以乱套标签。每个商品仍需包裹在 <code><article></article> 或带 role="article" 的 <div> 中，图片必须有 <code>alt，价格数字要用 <span></span> 包裹并加 aria-label（例如 aria-label="售价 ￥299"）。
