用 % 更稳妥。因 iOS Safari 横屏时 100vw 错误包含地址栏高度致溢出，而 width: 90% 基于父容器不受干扰；配合 max-width: 500px、min-width: 280px 及 Flex 居中更可靠。
弹窗宽度用 vw 还是 %？
用 % 更稳妥。虽然 100vw 看似“占满视口”，但 iOS Safari 横屏时会把地址栏高度算进 vw，导致实际宽度溢出——用户左右拖动才能看到完整弹窗。而 width: 90% 基于父容器（通常是 body 或 html），不受地址栏缩放干扰，横竖屏都稳定。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 设最大宽度：
max-width: 500px防止平板横屏时过宽 - 设最小宽度：
min-width: 280px避免小屏竖屏下内容挤成窄条 - 不依赖
vw做主体尺寸，仅在背景遮罩或动画偏移中谨慎使用
position: fixed 在 iOS 横屏下失效？
不是失效，是触发了 Safari 的“视口缩放补偿”：横屏切换瞬间，fixed 元素可能卡在旧视口坐标，尤其当页面有 overflow: hidden 或 body 被强制滚动锁定时。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 给弹窗加
transform: translateZ(0)强制硬件加速，减少重绘抖动 - 监听
orientationchange事件（iOS 专属），触发后短暂setTimeout重置top/left（哪怕只是赋值当前值） - 避免对
body直接设overflow: hidden；改用document.body.style.position = 'fixed'+top偏移来模拟锁屏
弹窗居中用 top: 50% + transform 为什么有时偏移？
因为 50% 是相对于视口高度计算的，而 iOS 横屏时地址栏收起/展开会动态改变可用视口高度，transform: translateY(-50%) 的基准没变，但“50%”的实际像素值已不同。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 改用
top: max(50vh, 50%);（需支持max()的浏览器）或 JS 动态读取window.innerHeight - 更简单可靠的做法：用 Flex 布局居中父容器（
html或全屏遮罩层），再让弹窗自身margin: auto - 禁用
viewport的user-scalable=yes，防止用户双指缩放破坏计算
键盘弹出时弹窗被顶上去或遮挡？
Android 和 iOS 处理软键盘的方式不同：Android 通常缩放视口（visualViewport 变小），iOS 则推高页面（window.innerHeight 不变但内容被挤）。弹窗若固定定位，就可能被键盘盖住或悬空。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 监听
focusin事件，在输入框聚焦时，给弹窗加position: absolute+ 手动计算top（基于document.scrollingElement.scrollTop） - 用
visualViewportAPI（Chrome/Edge/Safari 16.4+）监听尺寸变化，动态调整弹窗top值 - 底线方案：检测到软键盘弹出（如
window.innerHeight突然变小 >150px），立即关闭弹窗或隐藏输入框区域
横竖屏适配真正的难点不在 CSS 写法，而在 Safari 对视口、缩放、键盘三者的耦合行为——它不会报错，只会悄悄错位。调试时别只看 DevTools 的尺寸，真机横屏切几次，再点输入框，问题才露出来。
