overflow对无显式宽高的块级容器无效，需作用于实际内容容器并设min/max-width:100vw；横屏检测应优先用min-aspect-ratio而非orientation；iOS存在overflow-x:hidden失效的WebKit Bug，需配合contain:layout paint等方案；CSS无法单独实现横屏锁定，须JS协同screen.orientation.lock。
横屏时内容撑破视口，overflow 为什么没用？
因为默认情况下，overflow 只对「有明确宽高的块级容器」生效；移动端横屏时，body 或 html 往往没有显式宽度限制，且 viewport 缩放、初始缩放（initial-scale）会干扰渲染尺寸判断。
常见错误现象：overflow: hidden 加在 body 上完全无效，或者横屏后右侧出现不可见的空白滚动区。
- 确保
meta viewport设置不含user-scalable=yes，推荐用<meta name="viewport" content="width=device-width, initial-scale=1.0, maximum-scale=1.0"> -
overflow必须作用于实际承载内容的容器，比如.page-wrapper，而不是body—— iOS Safari 对body的 overflow 处理极不稳定 - 给该容器加
min-width: 100vw和max-width: 100vw，防止内部弹性布局或绝对定位元素意外拉伸容器
用 @media 检测横屏，但 orientation: landscape 不可靠
iOS 设备在 Safari 中，orientation: landscape 媒体查询在键盘弹出、地址栏收起等场景下会误判；更稳的方式是用 min-aspect-ratio 或直接比宽高值。
使用场景：只在真正「宽度 > 高度」时启用横屏专用样式，避免误触发。
立即学习“前端免费学习笔记（深入）”；
- 优先用
@media (min-aspect-ratio: 13/9)（约 1.44），覆盖主流手机横屏比例（如 iPhone 15 Pro 是 19.5:9 ≈ 2.17） - 或写成
@media (min-width: 600px) and (max-height: 400px)，结合具体设备断点，比纯orientation更可控 - 不要依赖
window.orientation—— 已被多数浏览器弃用，且返回值在桌面模拟器里毫无意义
/* 推荐写法 */
@media (min-aspect-ratio: 13/9) {
.content-container {
overflow: hidden;
width: 100vw;
}
}
overflow-x: hidden 在 iOS 上仍可横向拖拽？
这是 WebKit 的经典 Bug：即使设置了 overflow-x: hidden，如果容器内有 position: absolute 元素超出父边界，或存在未重置的 transform: translateX()，iOS 仍允许惯性滚动。
性能影响：这类“伪溢出”会触发额外的图层合成，导致横屏动画卡顿。
- 给容器加
-webkit-overflow-scrolling: touch并设overflow: hidden，但仅限需要滚动的子区域，主容器慎用 - 检查所有子元素是否设置了
left/right超出父宽，或transform偏移后未用will-change: transform提前声明 - 用
contain: layout paint锁定容器边界行为（Chrome 85+ / Safari 15.4+ 支持），比单纯overflow更彻底
横屏锁定不是 CSS 能单独解决的事
CSS 控制的是视觉溢出，但用户物理旋转设备后，页面是否响应、是否强制保持竖屏，取决于 JS + 原生能力协同。
容易被忽略的地方：仅靠 CSS 无法阻止横屏发生，也无法监听“即将横屏”事件；screen.orientation.lock('portrait') 需用户手势触发，且仅在 HTTPS 环境下有效。
- 若需强横屏锁定（如视频播放页），必须配合
screen.orientation.lock('landscape')，并在resize事件中检测window.innerWidth > window.innerHeight后主动调用 - CSS 的
@media+overflow只负责「横屏后不滚出、不撑开」，两者职责不能混用 - 测试时务必真机验证 —— 模拟器常忽略 viewport 缩放和 touch 惯性滚动细节
