HTML解析器从Tokenizer遇到<body>标签时即锚定文档流起点，DOM树构建顺序即原始坐标系；display: none是唯一彻底退出流的方式，而float、absolute等仅部分或完全脱离流；父容器塌陷需通过触发BFC解决，非clear属性可修复。
HTML解析器如何决定文档流起点
文档流不是CSS加了display: block才开始的，而是从HTML解析器构建DOM树那一刻就已锚定。Tokenizer阶段一旦遇到<body>标签，树构建器就开始按顺序挂载子节点——这个顺序就是文档流的原始坐标系。任何后续CSS对display或position的修改，都是在这个初始流基础上做覆盖或退出。
常见错误是以为“没写CSS就默认有流”，其实流的存在依赖于解析器是否把元素放进DOM树：比如<script>标签内未执行的JS代码、被document.write()动态插入但尚未解析的内容，都不参与初始文档流；而<noscript>里的内容在JS禁用时才会进入流。
-
<head>里声明的<meta charset="utf-8">若缺失或错写，Tokenizer解码失败，后续文本令牌乱码，导致DOM节点内容异常，文档流虽存在但语义崩坏 -
<template>标签内容不参与初始流，只有脚本调用content.cloneNode(true)后插入DOM才真正加入流 - 自定义元素（如
<my-card>）若未定义或定义失败，解析器会当作未知标签处理，仍生成DOM节点并参与流，但无样式/行为
display值如何实时切断或保留文档流占位
display: none是唯一彻底退出文档流的方式：它让元素既不占空间、也不触发重排，渲染树直接跳过该节点。而visibility: hidden只是视觉隐藏，元素仍在流中占位，影响布局计算；opacity: 0同理，只是像素级透明，不影响几何信息。
真正容易混淆的是display: inline和display: inline-block的区别：前者完全忽略width/height/margin-top/margin-bottom，后者支持全部盒模型属性且保持行内排列。按钮用<div>替代<button>却没设display: inline-block，就会因默认block独占一行，在导航栏里强行换行。
立即学习“前端免费学习笔记（深入）”；
-
display: flex和display: grid会创建新的格式化上下文（BFC），其子项脱离父级文档流，但父容器自身仍参与外层流 -
float: left让元素脱离流，但文本内容会绕排——这说明它“部分退出”，父容器高度坍缩正是因为它不再贡献高度计算 -
position: absolute和position: fixed完全脱离流，定位参考点取决于最近非static祖先；若没有，则回退到<html>，这在组件嵌套中极易导致定位偏移
为什么父容器塌陷不是“清浮动”能解决的
用clear: both放在浮动元素后面，只是强制下一个块级元素下移到浮动区域下方，它不修复父容器本身的高度丢失问题。父容器塌陷的本质是：浮动元素脱离文档流后，其高度不再参与父容器的布局计算，而父容器又没设置明确高度，于是计算结果为0。
真正有效的方案是触发BFC（块级格式化上下文），让父容器重新包含浮动子项：
-
overflow: hidden最常用，但可能意外裁剪溢出内容 -
display: flow-root是现代标准解法，专为此设计，无副作用 -
::after { content: ""; display: table; clear: both; }是兼容旧版的伪元素方案，本质是插入一个BFC生成的匿名表格单元格
注意：float本身不会创建BFC，只有它的父容器设置BFC属性才能包含它。
line-height与margin-bottom协同控制段落节奏的底层逻辑
段落可读性崩溃往往不是因为字体太小，而是line-height和margin-bottom没形成稳定比例关系。浏览器渲染时，line-height决定行框（line box）高度，margin-bottom决定段框（block container）之间的间距。两者叠加产生视觉节奏——如果line-height设为1.2而margin-bottom设为1.5em，段间空隙会远大于行间空隙，造成“文字挤成团、段落飞出去”的断裂感。
推荐组合：line-height: 1.6（相对单位，随字体大小缩放），margin-bottom: 1.5em。这样段间距≈2.4倍字号，行间距≈1.6倍字号，形成1.5:1的呼吸比。移动端可将margin-bottom微调为1.2em，避免小屏下段距过大。
- 避免对
<p>同时设置padding和margin，易引发盒模型叠加混乱 -
text-indent在响应式场景下慎用，小屏时2em缩进可能超过视口宽度，建议PC端用，移动端改用margin-top强化段首识别 - 用
<br>代替<p>分段，会导致屏幕阅读器无法识别语义边界，且无法被阅读模式提取
文档流排版的复杂点不在单个属性，而在DOM结构、display行为、盒模型参数、渲染时机四者咬合形成的连锁反应——改一个margin可能触发重排，改一个display可能改变整个父容器的BFC状态，这些细节稍不留意就会在不同设备或辅助技术中暴露出来。
