响应式表格痛点在于手动维护多层 media 断点与 grid-template-columns，Sass 通过预设规则（如 make-grid-cols 函数）静态生成 minmax() 布局，配合 display: contents + grid 实现行列可编程控制，但受限于编译时计算、IE 不兼容及 colspan 失效等问题。
响应式表格的痛点在哪？
直接写 @media 套多层断点，表格列数一变就得手动调 grid-template-columns 和 display: contents 的组合，稍不注意就出现横向滚动或列错位。Sass 本身不解析 DOM，所以“自动计算行列”不是靠运行时推导，而是靠预设规则 + 数学映射——比如把「每行显示 N 列」转成 repeat(N, 1fr)，再配合 minmax() 控制最小宽度。
用 Sass 函数生成动态 grid-template-columns
核心是写一个函数，输入列数和最小单元宽，输出带 minmax() 的重复声明。别用 flex 模拟表格，它无法保证行列对齐；也别在 @each 里硬写死断点，维护成本高。
-
$cols: 4时生成grid-template-columns: repeat(4, minmax(120px, 1fr)) - 用
@function make-grid-cols($count, $min: 120px)封装逻辑，避免重复拼字符串 - 注意：Sass 3.5+ 才支持
minmax()直接参与计算，旧版本需用插值#{...}输出 - 实际使用时，把
$count绑定到类名上，如.table--cols-3，比 media 查询更可控
为什么 display: contents + grid 更可靠？
用 display: table 做响应式，tbody > tr > td 在小屏下很难重排；而 display: contents 让 tr 和 td 脱离渲染流，由父级 grid 统一控制布局，真正实现「行列可编程」。
- 必须给
table元素加display: grid，否则contents不生效 -
tr设为display: contents，td设为grid-column: span 1，才能被 grid 容器捕获 - IE 不支持
display: contents，若需兼容，得 fallback 到block+nth-child模拟行列 - 不要给
td设grid-row，它会破坏自然流顺序，用grid-auto-flow: row更稳
数学计算的实际限制在哪？
Sass 的计算是编译时静态的，不能根据内容长度、容器尺寸或屏幕 DPI 动态调整列宽。所谓「计算」，只是把设计师给的「小屏 2 列、中屏 3 列、大屏 4 列」翻译成对应 CSS，不是让 CSS 自己算。
立即学习“前端免费学习笔记（深入）”；
- 列数不能来自
length($list)反推（除非你把表头字段全写死在变量里） -
minmax(100px, 1fr)中的100px是硬编码，内容超长仍会溢出，得配overflow: hidden或text-overflow - 如果表格有合并单元格（
colspan），display: contents会让它失效，此时只能放弃 grid 方案，改用 JavaScript 补齐 - 真正难的不是生成 CSS，而是确定「多少像素切一列」——这得看字体、内边距、是否有图标，没法纯数学解决
