fixed元素以视口为参考系且脱离文档流，relative元素以自身为基准且不脱离文档流；二者定位参考系与流体行为本质不同，不可互换。
固定定位 position: fixed 的真实行为边界
固定定位的元素始终以浏览器视口（viewport）为参考系，滚动时位置锁定——但这个“锁定”有前提：它必须能被正确解析为“非 static 定位”，且不被 transform、filter 或 will-change 等属性意外干扰。常见错误是以为加了 top: 0 就一定贴顶，结果发现被父容器的 overflow: hidden 剪裁，或因祖先元素设置了 transform: translateZ(0) 触发了新的包含块，导致它实际相对于该祖先而非视口定位。
- 必须显式设置
top/bottom/left/right中至少一个值，否则行为等同于static - 脱离文档流，原位置完全释放，其他元素会立即填补空缺
- 在 iOS Safari 中，若页面存在
input聚焦，软键盘弹出时可能触发视口缩放，导致fixed元素错位（需配合viewportmeta 控制） - 无法响应父容器的尺寸变化（比如侧边栏展开），因为它根本不感知父级
.header {
position: fixed;
top: 0;
left: 0;
right: 0;
height: 60px;
background: #fff;
z-index: 1000;
}
相对定位 position: relative 的隐藏职责
相对定位最常被误用为“微调工具”，但它真正的核心价值是充当 absolute 子元素的定位上下文。只要父元素没设 position: relative（或 absolute/fixed），子元素的 absolute 就会一路向上找，最终落到 body 上——这极易造成布局失控。它不脱离文档流，所以 margin、padding 仍影响周围元素，而 top 移动后留下的空白，也常被误认为“bug”。
- 即使不写
top/left，只声明position: relative，也会创建新的层叠上下文（影响z-index生效范围） - 偏移量是相对于自身原始位置计算的：
top: 20px表示向下移 20px，不是“离顶部 20px” - 不能用于实现“滚动时固定”的效果——它会随页面一起滚动
- 当用作
absolute父容器时，建议显式设height或min-height，避免内容塌陷
.card {
position: relative; /* 让 .badge 可以 relative to this */
padding: 16px;
}
.card .badge {
position: absolute;
top: -8px;
right: -8px;
}选 fixed 还是 relative？关键看“是否需要脱离滚动流”
这不是风格偏好问题，而是行为契约：如果你要的元素必须“永远可见、无视滚动”，就只能用 fixed；如果只是想让某个图标对齐文字基线、或让下拉菜单锚定在按钮右下角，那 relative + absolute 组合才是正解。强行用 fixed 实现菜单定位，会导致菜单随窗口缩放错位，且无法响应父容器宽度变化；反过来，用 relative 做返回顶部按钮，滚动后它就消失了。
-
fixed适合：全局导航栏、悬浮客服按钮、全屏遮罩层 -
relative适合：表单内图标微调、轮播图容器（为子项提供定位基准）、卡片内角标、tooltip 容器 - 两者不可互换：没有“兼容模式”，浏览器不会降级处理
- 移动端需额外测试：部分 Android WebView 对
fixed支持不稳定，relative则几乎无兼容问题
z-index 层级陷阱：它们都受同一套规则约束
无论 fixed 还是 relative，层级控制都依赖 z-index，但前提是它们处于同一层叠上下文。一个常见坑是：父容器设了 z-index: 10，子元素设了 z-index: 999，结果仍被隔壁模块盖住——因为父容器同时触发了新层叠上下文（比如加了 opacity: 0.99 或 transform），子元素的 z-index 只在该上下文中生效。
立即学习“前端免费学习笔记（深入）”；
-
fixed元素默认创建新层叠上下文，relative在设了z-index后也会创建 - 不要假设数值大就一定在上层：必须确保它们没有被更高层叠上下文隔离
- 调试时可用浏览器开发者工具的“Layers”面板查看实际层叠结构
真正难的不是记住语法，而是判断“这个元素到底该属于谁的坐标系”。fixed 拒绝任何父级约束，relative 表面顺从文档流，实则暗中改写子元素的命运——选错一个，整片布局就可能开始漂移。
