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