Grid嵌套超3层会显著拖慢渲染，因每层都触发额外布局计算和重排，实测低端安卓机首屏延迟20–50ms；现代Grid设计本意是父容器直接定义布局，子项无需包裹。

为什么 grid 容器里还套着 3 层

就该立刻删

浏览器构建 DOM 树是同步过程，每多一层

就多一次节点创建 + 样式计算 + 布局重排。实测显示：5 层嵌套在低端安卓机上可拖慢首屏 20–50ms。而现代 Grid 本意就是让父容器直接定义布局关系，子项无需包裹。

• 检查构建后 HTML（不是源码），用开发者工具 Elements 面板看真实 DOM 层级；Vue/React 组件默认可能注入多余根节点，开启 Fragment 或用 v-for 的 :key 直出子元素可跳过一层
• 三列等宽布局，老写法：
  A

  B

  C
  ；新写法：
  A

  B

  C
• 慎用 display: contents：它虽能“隐形”父容器，但 IE 全系不支持，且会剥离可访问性树节点，屏幕阅读器无法识别其子元素

grid-column 写成 1 / 4 却只想要两列？这是线编号不是列编号

Grid 线编号从容器左上角开始，列线从左到右为 1、2、3…，grid-column: 1 / 4 表示跨第 1 条线到第 4 条线——实际占 3 列，不是“第 1 列到第 4 列”。这个混淆点导致大量对齐偏移和响应式错位。

• 用负数反向定位更可控：grid-column: -2 / -1 指倒数第二条列线到最右边列线
• 命名线比数字更安全：grid-template-columns: [start] 1fr [main] 2fr [end]，然后子项直接写 grid-column: start / main
• 省略第二值等价 auto：grid-row: 2 ≡ grid-row: 2 / auto，但容易引发高度不一致，尤其在内容动态加载时

用 place-items: center 后内容被裁剪？缺了两个关键 CSS 重置

place-items 只控制对齐位置，不改变子项尺寸。若子项本身宽高超出网格区域（比如一张未约束的图片或长文本），又没设收缩限制，就会被裁剪或撑破布局。

HTML Text Extract

从HTML页面（URL、文件或标准输入）中提取主体内容文本，去除导航、页脚、广告和模板文本。可直接传递给readability_check或其他文本工具。

下载

• 必须加 min-width: 0 和 min-height: 0 到子项，否则 flex/grid 子项默认不收缩，这是溢出主因
• gap 和 margin 不要混用：gap 是轨道间间距，margin 是子项自身外边距；叠加会导致间距翻倍，尤其在 grid-auto-flow: dense 下 margin 可能被折叠
• 调试时临时加 outline: 1px solid red 到子项，看清它实际占据的网格范围，再判断对齐是否合理

首屏图片加 loading="lazy" 为什么 LCP 直接崩了

loading="lazy" 本质是降级加载优先级。浏览器对首屏可见区域内的 有独立高优策略，加了 lazy 等于主动告诉浏览器：“这图不重要”，LCP（最大内容绘制）指标必然恶化。

• 所有首屏可见区域内的 必须去掉 loading 属性，或显式设为 loading="eager"
• 带 loading="lazy" 的图片，必须同时声明 width 和 height 属性，否则触发 CLS（累积布局偏移）
• 也支持 loading="lazy"，但仅当其内容非首屏关键路径时才启用；服务端渲染拼接 HTML 时容易漏掉这些属性，建议模板引擎内置校验规则

真正卡住性能的，往往不是 JS 执行慢，而是你写的第 4 个

和第 2 个没设 min-width: 0 的网格子项。结构扁平和尺寸收敛，比任何优化插件都管用。

前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！