文档流起点由tokenizer遇到标签时锚定，dom树构建顺序即原始坐标系；display: none是唯一彻底退出流的方式，float、absolute等仅部分或完全脱离流；父容器塌陷需触发bfc解决。
Tokenizer 遇到
浏览器不是等所有 HTML 加载完才开始排版，而是在解析器（Tokenizer）第一次碰到 标签时，就立刻启动 DOM 树构建，并以此为坐标系原点确定初始文档流。这个顺序就是后续所有布局计算的基准——<p></p> 在 <div> 后面，DOM 树里就一定挂在其后，CSS 再怎么改 position 或 float，也只是在这个既定顺序上做覆盖或退出。
<p>常见错误是以为“没写 CSS 就没流”，其实流从解析那一刻就已固化：比如 <code><script></script> 里的未执行 JS、<template></template> 里的内容、甚至 <noscript></noscript>（JS 禁用时才进流），都不参与这个初始流。而 里漏写 <meta charset="utf-8">，会导致 Tokenizer 解码错乱，后续所有标签位置都偏移，流还在，但语义已崩坏。
<div> 和 <code><span></span> 的默认行为由 UA 样式表硬编码决定
你不用写任何 CSS，<div> 就独占一行、<code><span></span> 就挤在文字中间——这不是浏览器“智能猜测”，而是用户代理（UA）样式表早把 display: block 和 display: inline 写死了。W3C 规范强制要求这些标签的初始 display 值，和语义无关，纯属排版契约。
容易踩的坑：
-
<img>默认是inline，所以底部总有空白（那是基线对齐留的间隙），加display: block或vertical-align: top才能清掉 -
<button></button>默认是inline-block，能设宽高又不换行；但很多人误当纯inline用，结果 margin-top/margin-bottom 不生效 - 把
<ul></ul>里塞<div>，解析器会直接把它踢出列表，变成兄弟节点——DOM 树和你写的源码根本不是一回事 <h3>非法嵌套触发 DOM 自动修复，但结构已不可逆</h3> <p>写 <code><div><p>text</p></div>，浏览器不会报错或卡死，而是立刻闭合<p></p>，再把<div> 当作 <code><p></p>的兄弟节点挂载。你看到 Elements 面板里缩进突兀、灰色半透明节点、右键 Edit as HTML 后结构跳变，都是修复完成后的证据，不是“正在出错”。最典型的撕裂场景：
<table> 内部只认 <code><tr>/<code><td>，塞 <code><div> 或 <code><form></form>会被踢到<table> 外面 <li> <code><ul></ul>和<ol></ol>只接受<li>子元素，其他标签一律移出- PHP 模板循环输出
<input>到<table> 里却不包 <code><tr>，是线上最常见的布局崩溃根源 <p>别依赖浏览器“修好”——W3C Validator 或 <code>html-validate命令行才是唯一能做规范级预判的工具。报错Element div not allowed as child of element p，就是铁律，必须改代码。display: none是唯一彻底退出文档流的方式只有
display: none让元素既不占空间、也不参与布局计算，渲染树直接跳过它。其他所谓“隐藏”全是假象：-
visibility: hidden：元素还在流中占位，父容器高度照算，只是看不见 -
opacity: 0：像素级透明，几何信息全保留，事件还能触发 -
float: left：部分退出——文本绕排，但父容器高度坍缩 -
position: absolute：完全脱离流，定位参考点取决于最近非static祖先；没找到就回退到，组件嵌套时极易偏移
真正容易忽略的是：父容器塌陷（比如
<div> 包着几个 <code>float子项却高度为 0）不是靠clear修复的，而是要触发 BFC（比如加overflow: hidden或display: flow-root）。 -
