在当下的网页设计，特别是面向大型系统（如后台管理、数据看板、SaaS 平台）时，栅格系统的选择已经从“选多少列”转向了“如何让布局更灵活、更贴近内容”。我会结合你提的两个问题，梳理一下传统做法和发展趋势。

一、大型系统，一般用多少栅格合适？

最常用的推荐：24 栅格。
对于信息密度高、组件种类多的大型系统，24 列已经成为事实标准，比如 Ant Design、Element Plus、Arco Design 等企业级组件库都默认使用 24 栅格。原因是：

• 划分粒度更细，适配更多布局
  24 可以被 2、3、4、6、8、12、24 整除，意味着能轻松实现 1/2、1/3、1/4、1/6、1/8、1/12 等常见的分栏比例，几乎不需要嵌套就能完成复杂排版。
  相比之下，经典的 12 栅格虽然也能靠嵌套实现类似效果，但在多级嵌套时会导致标记冗余、对齐困难。

• 直接满足高分辨率大屏
  后台系统常在大屏幕上使用，24 列在 1440px 或更宽的画布上，单列宽度大约 60px（含间距），依然是比较舒适的操作和阅读宽度。
  如果只用 12 列，单列过宽，灵活度会明显下降。

• 一些系统也会搭配 16 栅格
  像 Material Design 的布局网格更多是弹性列 + 固定间距，并不强调固定列数。但部分桌面端工具或网站（如某些编辑器）会用 16 列，适合更强调两侧留白、中间内容居中的设计。

结论：大型系统首选 24 栅格作为底层布局约束，再结合内容特性决定具体使用哪些比例。
这更多是一种“设计约定”，而非代码强制的固定数值。

二、以前的栅格系统（传统做法）

1. 固定宽度栅格时代
   典型代表：960 Grid System。将页面宽度固定为 960px，分为 12 或 16 列，通过 float 实现布局。
   那个年代屏幕分辨率相对统一，设计追求像素级精确控制，但完全不具备响应式能力。

2. 响应式百分比栅格
   Bootstrap 2/3 是其代表，将 12 列基于百分比，通过媒体查询在不同断点切换类名（col-md-6）。本质仍是固定列数的浮动栅格，但能适配不同屏幕。
   这类系统的痛点在于：列数写死，嵌套时比例计算复杂，垂直方向的对齐很难优雅处理。

3. Flexbox 辅助的改进栅格
   Bootstrap 4 开始用 Flexbox 重写了栅格，解决了等高列、垂直居中等问题，但依然保持 12 列的思维，并通过 flex-basis 百分比实现。扩展性比浮动好，但布局仍然是基于“行→列”的线性结构。

传统栅格的共同特征：列数固定、依赖于行容器、难以处理复杂二维布局，且间距和对齐高度依赖外层类名。

三、现在的发展趋势（核心变化）

从“栅格系统”到“智能布局”，现代网页设计的趋势可以总结为几个关键转变：

1. 从“固定列数”到“内置弹性网格”——CSS Grid 的冲击

CSS Grid Layout 的普及彻底改变了栅格的使用方式。我们不再需要用一个全局的 12 或 24 列来约束所有区域，而是按组件或区域定义各自的网格。

• repeat(auto-fill, minmax(200px, 1fr)) 可以自动计算列数，内容自己决定断行。
• grid-template-columns: 1fr 2fr 直接描述比例，不再受限于固定的分母。
  这意味着栅格列数这个数字本身的权重正在下降，更重要的是定义最小尺寸、最大尺寸和弹性行为。

2. 内在网页设计（Intrinsic Web Design）

Jen Simmons 提出的这个概念强调：布局应该由内容本身的特性和可用空间来决定，而不是让内容去适配预先分好的格子。
典型的落地方式：

• 使用 minmax 控制列的最小/最大宽度
• 利用 auto-fit / auto-fill 让卡片网格自动换行
• 不再依赖全局固定的断点去“切换列数”，而是让布局自然流畅地适应容器。

3. 子网格（Subgrid）让嵌套对齐成为可能

传统栅格的嵌套布局中，内部的网格很难和外部网格的轨道保持对齐（比如卡片内文字基线对齐外层网格线）。CSS 的 subgrid 允许子元素继承父网格的轨道定义，这让大型系统的复杂对齐逻辑变得简单且健壮。
这比过去硬套 24 列去试图对齐要灵活得多。

4. 容器查询（Container Queries）带来组件级响应

过去媒体查询只能基于视口大小切换栅格断点，现在容器查询允许组件根据自身容器的宽度改变内部栅格列数。
比如一个仪表板卡片组件，放在宽栏时显示 4 列数据，放在窄栏时自动变为 2 列——不需要依赖全局类名。这与固定栅格系统的“全局断点”思维完全不同。

5. 从“栅格系统”到“空间系统”

现代设计系统（如 Figma 中的 Layout Grid + Spacing Token）更倾向于定义一套间距和列关系的规则，而不是交付一个死板的 24 列框架。

• 常用做法：把页面分为固定边距（Margin）、弹性列（Columns，数量可变）和固定槽（Gutter）。
• 设计工具里即使仍然显示 12 或 24 列，实际上只是辅助线，代码实现时可能完全靠 CSS Grid 动态生成。
• 对于大型系统，很多团队会将 24 列作为设计侧的“高保真参考”，但在前端用更灵活的 Grid 布局去还原，而不是照搬旧式栅格类名。

6. 趋势小结

• 不再纠结于到底用 12、16 还是 24，而是根据内容特性定制网格轨道。
• 固定网格 → 弹性/自适应网格，由 minmax、auto-fit 实现。
• 全局布局 → 区域独立网格，一块区域可以是 2 列，另一块可以是 5 列，不需要强统一。
• 嵌套错位 → subgrid 完美对齐。
• 视口响应 → 容器响应，组件自己决定列数。

四、对大型系统的现实建议

尽管趋势是“去固定列数化”，但在企业级大型系统中，24 栅格依然是一个高效的设计约束，理由如下：

• 它让设计师和开发者的沟通成本极低（工具内置、组件库配套）。
• 对于表单、表格、数据详情页等高度结构化页面，24 栅格足够覆盖绝大部分场景。
• 可以在整体页面框架层沿用 24 列，而在局部卡片、仪表板小部件等区域，大胆使用 CSS Grid 的动态列数，两者结合。

所以，更务实的方案是：用 24 栅格作为页面级骨架，用 CSS Grid 的内在布局能力去赋能每一个局部组件。 这样既保留了大型系统对统一性和开发效率的要求，也拥抱了现代布局的灵活性和可维护性。