先说结论：旋转屏幕后 fixed 元素发生偏移，通常并非 CSS 本身的 bug，而是浏览器的“响应延迟”所致。当手机从竖屏切换至横屏时，视口坐标系会短暂停留在旧的尺寸下——而 fixed 元素恰恰依据旧尺寸计算定位，因此自然会出现错位。那么，问题究竟出在哪里？又有哪些可行的解决方案？
旋转屏幕后 fixed 元素位置偏移，先检查 viewport meta 是否完整
移动端进行横竖屏切换时，fixed 元素出现错位，本质上是视口坐标系未能及时重置所致。iOS Safari 以及部分 Android WebView 在旋转后会短暂维持旧视口尺寸，直至布局重排完成，期间 fixed 元素仍按旧尺寸计算位置。你可能会觉得这像是一个“bug”，但实际上最关键的环节在于 标签的写法。
关键点在于 标签必须同时声明 maximum-scale=1.0 和 minimum-scale=1.0。仅仅依靠 user-scalable=no 无法阻止浏览器内部缩放逻辑干扰 fixed 锚定——即使你禁止用户缩放，浏览器自身依然可能悄悄调整缩放比例。
- 错误写法：
- 正确写法：
- 真机测试比模拟器更可靠——模拟器通常忽略视口重绘延迟，而真机在旋转瞬间会明显出现偏移
fixed 元素被祖先 transform “劫持”，旋转后表现更诡异
即便父容器仅写了 transform: translateZ(0)，也会创建新的包含块（containing block）。旋转屏幕时，该祖先的 transform 值可能被浏览器重新计算或缓存，导致 fixed 元素突然从“相对视口”跳变为“相对祖先”，且偏移量与旋转前不一致。
在开发者工具中看不出问题？那就用 getBoundingClientRect() 来验证：
const el = document.querySelector('.na v-fixed');console.log(el.getBoundingClientRect()); // 横屏下top可能突变为非0值
- 逐层检查 Computed 面板中
transform、filter、backdrop-filter、will-change是否为none - 特别注意第三方轮播图、弹窗组件——它们内部默认添加了
transform: translateX(0)，你没写，但它确实存在 - 临时添加
transform: none !important可以快速验证，但不能直接上线——它只是掩盖问题，并未真正修复
用 sticky 替代 fixed 是更稳健的选择
position: sticky 天然不受 transform 祖先影响，并且在横竖屏切换时能自动响应滚动容器尺寸变化。只要目标元素位于滚动容器的顶部或底部，它就是比 fixed 更强壮的方案。这里尤其推荐在移动端开发中使用。
- 适用场景：
top: 0导航栏、bottom: 0操作栏、单页内局部悬浮按钮 - 兼容性：iOS Safari 11+、Chrome 56+、Firefox 64+，覆盖当前所有主流移动端
- 注意：必须保证父容器有明确高度或被内容撑开，否则 sticky 不会触发
真机上软键盘 + 旋转 + fixed 三者叠加时最容易崩溃
iOS 在软键盘弹出时会临时解除 fixed 定位逻辑，转而用 absolute 模拟；紧接着旋转屏幕，视口尺寸突变，导致元素坐标彻底错乱。这时仅靠 CSS 已无法解决，必须介入 JavaScript。
- 监听
resize事件比监听orientationchange更可靠，因为后者在 iOS 15+ 已被废弃 - 键盘唤起时，
window.innerHeight会突变，可用它判断当前是否处于键盘弹出状态 - 慎用
scroll事件动态重设top/left——滚动抖动、输入法遮挡、防抖阈值难以调校，容易引发新问题
真正难以处理的从来不是单一条件，而是横竖屏切换瞬间恰好遇上软键盘弹出、页面同时正在滚动——这种组合态下，fixed 几乎必然失效。此时不必硬扛，更换 DOM 结构或改用 sticky 才是更实际的选择。
