根本原因是容器尺寸、视口行为与方向判断逻辑未对齐设备真实渲染状态；需结合matchMedia校验、使用aspect-ratio或padding-top锁定比例、替换vh为dvh、禁用user-scalable=no，并将尺寸计算塞入resize+requestAnimationFrame链路。
图片在移动端横竖屏切换时拉伸、裁剪或留白，根本原因不是图片本身没写对，而是它所处的上下文（容器尺寸、视口行为、方向判断逻辑）没对齐设备真实渲染状态。只靠 max-width: 100% + height: auto 在横竖屏频繁切换下必然失效。
为什么 @media (orientation: portrait) 经常不触发图片重排
这个媒体查询只比较 innerWidth 和 innerHeight 大小关系，不反映物理朝向。iOS 键盘弹出后 innerHeight 骤降，innerWidth > innerHeight 成立，浏览器就误判为横屏；折叠屏半开状态更会反复抖动。结果就是：用户明明竖着拿手机，图片却被套上横屏样式，撑宽变形。
- 别单独依赖它控制图片尺寸，必须和
window.matchMedia("(orientation: portrait)").matches结合，并在resize事件里二次校验 - 确保父容器没有写死
height（如height: 500px），否则竖屏下高度溢出，object-fit会被强制裁剪 -
viewport必须带width=device-width, initial-scale=1.0，漏掉会导致整个媒体查询失效——浏览器还在用 980px 默认宽度渲染
图片容器必须用 aspect-ratio 锁定比例，不能只靠 img 样式
横竖屏切换时，仅给 <img alt="HTML怎么在移动端让图片自适应横竖屏切换" > 设 width: 100% 和 height: auto，无法阻止它在竖屏中因宽高比失配而“悬浮”或“压扁”。真正起作用的是外层容器是否提供了可预测的高度参照。
- 典型竖屏图容器写法：
.portrait-banner { width: 100vw; height: 100vh; aspect-ratio: 9/16; } -
aspect-ratio在 Safari 15.4+ / Chrome 100+ / Firefox 110+ 稳定支持；老版本可用padding-top: 177.77%替代（对应 9/16） - 图片自身设
width: 100%; height: 100%; object-fit: contain;，避免cover裁关键内容 - 删掉所有对
<img alt="HTML怎么在移动端让图片自适应横竖屏切换" >的内联width或height属性，它们会覆盖 CSS 缩放逻辑
键盘弹起+横竖屏切换时，dvh 和 scroll-margin-top 是刚需
iOS 键盘弹出后切横屏，vh 单位会按键盘收起后的视口计算，导致图片高度突然收缩；Android WebView 则可能把整个容器卷出可视区。这时候用 vh 就等于埋雷。
立即学习“前端免费学习笔记（深入）”；
- 把
height: 100vh全部换成height: 100dvh，dvh动态响应软键盘生命周期 - 如果图片是表单背景或需聚焦交互，给其父容器加
scroll-margin-top: 60px，确保focus()后自动滚动到可视区 - 禁用
viewport中的user-scalable=no，否则横屏后双指缩放失效，用户强行缩放会直接破坏aspect-ratio容器 - 所有基于
getBoundingClientRect()计算位置的浮层（比如点击图片放大提示），必须在resize后重新调用，不能缓存 rect
用 实现横竖屏不同源图切换（非必须但很稳）
当同一张图在横竖屏下构图差异极大（比如横屏是全景，竖屏要突出人脸），光靠 CSS 缩放已不够，得换图源。这时 <picture></picture> 比 JS 动态改 src 更可靠——浏览器原生支持，无闪屏，且能结合方向媒体查询。
- 写法示例：
<picture> <source srcset="hero-landscape.jpg" media="(orientation: landscape)"> <source srcset="hero-portrait.jpg" media="(orientation: portrait)"> <img src="hero-fallback.jpg" alt="主视觉"> </picture>
- 注意：
<source></source>的media条件按顺序匹配，第一个满足的即加载；全部不满足则回退到<img alt="HTML怎么在移动端让图片自适应横竖屏切换" > - 不要在
<source></source>里混用media和type（如 WebP 判断），方向判断和格式判断应拆开处理，避免条件冲突
最易被忽略的点：横竖屏切换不是一次性的尺寸变化，而是伴随软键盘、分屏、折叠屏展开等多状态叠加的连续过程。任何依赖“初始尺寸”或“一次性计算”的方案（比如 onload 读一次 innerWidth 就缓存）都会在第二次旋转时崩掉。必须把关键尺寸读取、容器重绘、定位重算全部塞进 resize + requestAnimationFrame 节流链路里。
