position 不该用于整体页面结构布局，因其导致组件脱离文档流、响应式失效、z-index失控、可访问性下降及维护成本剧增；应使用 Grid/Flex 等现代布局方案。
为什么 position 不该用于整体页面结构布局
用 position: absolute 或 position: fixed 搭建整个页面骨架，短期能“快速出效果”，但后续改版、适配、协作时维护成本会指数级上升。这不是语法错误，而是架构选择失误。
绝对定位导致组件无法响应内容变化
一旦用 top/left 硬编码位置，元素就脱离文档流，不再感知兄弟元素高度、字体大小、行高、甚至 padding 变化。常见现象包括：
- 文字换行后，下方
position: absolute的按钮被遮挡，但开发者查不到原因（因为没显式重叠） - 某处加了
margin-bottom: 20px，结果底部导航栏没跟着下移——它被bottom: 0锁死了 - 翻译成多语言后文案变长，
right: 10px的关闭按钮直接溢出容器，却不会触发父容器自动撑开
嵌套层级与 z-index 维护失控
多个 position: relative 父容器 + 多层 absolute 子元素，会让 z-index 成为“玄学调试项”。典型问题：
-
z-index只在同一个 stacking context 内有效，而position: relative+z-index会创建新 stacking context，导致“明明设了 999，还是被 2 的盖住” - 新增一个弹窗组件，要翻遍所有父容器的
z-index值，再找一个“安全间隙”，比如从999改成9999，下次再加又得翻倍 - 不同模块由不同人维护，A 模块设
z-index: 100，B 模块设z-index: 99，合并后视觉错乱，但没人记得谁写的那个 99
响应式与可访问性支持极差
position 布局几乎无法通过媒体查询优雅适配。例如：
立即学习“前端免费学习笔记（深入）”；
- 桌面端
left: 200px控制侧边栏，移动端想让它变成顶部导航栏？不能靠display: block切换，必须重写top/left，甚至改position类型 - 屏幕阅读器依赖 DOM 顺序和语义流，而
absolute元素在视觉上跳离原文档位置，容易造成朗读顺序错乱（比如“提交按钮”在 HTML 里写在表单最后，但视觉上浮在左上角） - 缩放文字到 200% 时，
top: 50px的标题可能直接压住导航栏，而 Flex/Grid 会随内容自然重排
/* 错误示例：用 absolute 拼整个页面 */
.header { position: absolute; top: 0; left: 0; width: 100%; }
.sidebar { position: absolute; top: 60px; left: 0; width: 240px; }
.main { position: absolute; top: 60px; left: 240px; right: 0; bottom: 0; }
.footer { position: absolute; bottom: 0; left: 0; width: 100%; }
/ 正确方向：用 grid 定义区域，内容自然流动 /
body {
display: grid;
grid-template-areas:
"header header"
"sidebar main"
"footer footer";
grid-template-rows: 60px 1fr 40px;
grid-template-columns: 240px 1fr;
}
.header { grid-area: header; }
.sidebar { grid-area: sidebar; }
.main { grid-area: main; }
.footer { grid-area: footer; }
用 position 控制局部微调（如气泡提示、下拉菜单偏移）没问题，但把它当页面骨架，等于主动放弃浏览器原生的流式计算能力——每次改动都在和 layout engine 对着干。
