CSS盒模型是HTML元素在页面中的可视化表示模型，每个元素被视为矩形盒子，从内到外依次为内容区（content）、内边距（padding）、边框（border）和外边距（margin），共同决定元素占据的空间与布局行为。
HTML文档结构决定元素在渲染树中的层级与顺序，CSS盒模型则定义每个节点在布局阶段如何占据空间；二者不是“一一对应”，而是通过浏览器渲染流水线协同作用——DOM树 → 样式计算 → 布局（Layout）→ 绘制（Paint）。脱离这个链条谈“映射”，容易误判尺寸、错估回流范围。
DOM节点如何触发盒模型计算
不是所有HTML元素都会生成独立的盒模型。只有参与文档流且具有渲染样式的元素（即 display 不为 none）才会进入布局流程：
-
display: none的元素不生成盒，也不占空间，直接跳过布局阶段 -
display: contents会移除自身盒子，但子元素仍参与布局（常用于语义化容器） - 伪元素
::before/::after在满足content非空时，会生成匿名盒并参与盒模型计算 - 文本节点本身不单独成盒，但会被包裹进行内上下文的“行盒（line box）”中，其
padding、border无效，margin也仅部分生效
box-sizing 如何影响 layout 阶段的 width/height 解析
浏览器在 layout 阶段解析 width 和 height 时，实际采用的计算逻辑取决于元素的 box-sizing 值，且该值在样式计算阶段就已确定：
-
box-sizing: content-box（默认）：width仅约束内容区，总宽度 =width+padding-left+padding-right+border-left-width+border-right-width -
box-sizing: border-box：width约束的是 content + padding + border 的总和，内容区宽度 =width−padding−border - 注意：
margin永远不参与box-sizing计算，它始终是盒外部的空白，不影响盒自身尺寸解析 - Flex 容器子项、Grid 容器子项默认忽略
box-sizing对主轴尺寸的干预，它们的width行为由 flex/grid 轴向规则主导
外边距合并（margin collapse）发生在哪个环节
外边距合并不是 CSS 解析阶段的静态计算，而是在 layout 阶段对块级格式化上下文（BFC）内相邻块级盒进行垂直方向间距优化时动态发生的：
立即学习“前端免费学习笔记（深入）”；
- 只发生在普通文档流中的块级盒之间，且必须是垂直方向（
margin-top与margin-bottom） - 父-子 margin 合并需满足：父元素无 border/padding，子元素是第一个/最后一个常规流块级子元素
- 兄弟元素间合并取两者中较大值，而非相加；若一者为负，则实际间距 = max(m1, m2) + min(m1, m2)
- 创建新 BFC（如
overflow: hidden、display: flow-root）可阻止合并，因为合并只在同一个 BFC 内发生
脱离文档流的元素还遵循盒模型吗
脱离文档流（如 position: absolute、position: fixed、float、display: flex 子项）的元素依然有完整的盒模型，但布局行为完全不同：
- 它们不再参与普通流的 margin 合并，也不受父容器
padding影响（除非是相对定位的 containing block） -
width/height解析仍受box-sizing控制，但尺寸基准可能变为 containing block 而非父元素 content box - 绝对定位元素的
top/right/bottom/left是相对于最近的定位祖先（containing block），而非盒模型四层本身 - 浮动元素会形成新的 BFC，其
margin不与外部块合并，但可能与自身清除后的元素产生间隙
真正容易被忽略的，是盒模型各层在不同渲染阶段的“可见性”：content 和 padding 决定背景绘制区域，border 是绘制层边界，margin 只影响布局位置而不绘制——但它一旦参与 margin collapse，就会间接改写 layout 输出结果，而这个过程对开发者完全不可见。
