css grid更适合现代开发，尤其在二维布局、响应式复杂、性能敏感场景；bootstrap栅格基于flex一维封装，强行改display: grid会破坏列宽、间隙和断点；真正用grid应绕开.row/.col，改用语义容器+自定义类。
直接结论：不用非此即彼，但必须分清主次——CSS Grid 负责结构布局，Bootstrap 负责组件交互。
什么时候该用 CSS Grid 而不是 .row/.col
当你要控制的是「二维空间关系」：比如仪表盘里 header 跨三列、sidebar 固宽、main 自适应、footer 拉通底部，且需要在不同断点下重排区域顺序（grid-template-areas 改写即可），这时硬套 .row 和 .col-md-6 反而增加 DOM 层级、干扰语义、让响应式逻辑散落在 HTML 类名里。
常见错误现象：.row 加了 display: grid 后列宽塌缩、.g-3 间距失效、.offset-md-2 不起作用——因为 Bootstrap 的栅格类全部基于 Flexbox 计算，Grid 下不识别 flex-basis、负 margin 对齐、order 等行为。
- 真正用 Grid，就删掉
.container > .row > .col三层嵌套，改用语义容器 +display: grid+grid-template-columns - 响应式只需在媒体查询里改
grid-template-areas或repeat(auto-fit, minmax(200px, 1fr)))，不用预设 12 列思维 - 移动端首屏渲染更快：DOM 更浅、无 JS 初始化、样式体积可压到 1KB 以内
什么时候还得留着 Bootstrap 的 .col 类
当你依赖的是「组件级行为」而非「布局逻辑」：比如表单控件对齐、按钮尺寸一致性、模态框定位、折叠导航栏的 JS 交互、data-bs-toggle 触发机制——这些和栅格无关，但去掉 Bootstrap 就得自己重写一堆 JS 和 reset 样式。
容易踩的坑：col-12 col-sm-6 col-md-4 这类写法在调试时难定位——生效的是最后匹配的断点规则，类优先级、覆盖顺序、伪类钩子都可能干扰；而 Grid 把所有响应逻辑收在 CSS 里，行为确定、无歧义。
- 已重度使用
.col-lg-8的老项目，强行切 Grid 会引发 HTML 结构重写 + 样式链断裂 - 团队协作中统一规范比技术先进更重要，尤其当设计师交付的是基于 Bootstrap 断点的设计稿
- 需要 IE11 兼容？Grid 必须配 Flex fallback，而 Bootstrap 的 Flex 栅格原生支持更好
Bootstrap 5.3 的 .grid/.g-col-* 是什么
这是 Bootstrap 官方提供的实验性 Grid 工具集，**独立于传统栅格体系**，不是对 .row 的升级，而是全新一套类名：容器用 .grid，子项用 .g-col-4，靠 CSS 变量 --bs-columns 控制总列数。
它不兼容 .col-md-6，也不能和 .row 混用。启用后需全量替换旧栅格类，且仍受限于 Bootstrap 的 12 列默认值、断点命名方式、工具类粒度（比如没有 g-col-start-2 这种轨道定位）。
- 适合新项目起步阶段想轻量接入 Grid，又不愿完全脱离 Bootstrap 生态
- 不能替代原生 Grid 的
grid-area、跨行/跨列、隐式网格线等能力 - 若你真需要二维控制力，不如直接写
display: grid，省去学两套语法
真正难的不是选哪个，而是哪块该用哪个：首页卡片流、后台仪表盘、文章详情页主结构交给 Grid；表单、弹窗、按钮组继续用 Bootstrap 组件。混用没问题，但别把 .row 当 Grid 容器用——那是最常被忽略、也最容易引发样式错乱的点。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
