移动端 WebView 图片变形问题及解决思路

同一张图片在安卓浏览器正常，却在部分 iPhone 或应用内 WebView 中被拉宽、压扁，甚至需要滑动很久才能看到下一张轮播图。这类问题很容易被归因于图片组件，实际原因通常来自多层约束叠加：父容器给了固定宽高，Flex 项目发生收缩，图片使用了不合适的填充方式，轮播又在布局稳定前计算了宽度。

排查时先区分现象。图片被压扁说明显示比例改变；内容被裁掉说明容器比例与图片不同且使用 cover；出现留白通常是 contain 的正常结果；轮播滑动距离异常则更可能是轮播项或轨道宽度计算错误。不同现象不能用同一个 CSS 属性解决。

图片是否能“完整、无留白、填满固定宽高”取决于图片与容器比例。当两者比例不同，这三个目标无法同时满足：fill 会拉伸，cover 会裁切，contain 会留白。若业务要求完整且不变形，应让容器高度根据实际宽度和原图比例计算；若视觉区域必须固定，则需要接受裁切，并在素材阶段设置安全区域。

Flex 布局是旧版 WebKit 中常见风险。仅设置 width 不代表元素不会被压缩，必要时应使用 flex: 0 0 <width> 同时控制放大、缩小和基准尺寸；如果只是设置 flex-basis，flex-shrink 仍可能生效。左右卡片还要核对 box-sizing、边距和总宽度，避免宽度加间距超过容器。

轮播组件依赖挂载时尺寸。如果组件位于条件渲染、弹层、隐藏容器或异步图片场景，首次测量可能不准确。应在元素可见、DOM 更新和布局稳定后调用尺寸重算，并检查轮播项是否被内部内容撑宽。图片设置 display:block; width:100%; height:100%，同时确保其直接父级与轮播项都有明确宽度和 min-width:0。

针对旧版 iOS，优先使用稳定的比例容器。可通过 padding-bottom 创建比例，再让图片绝对定位铺满；需要动态高度时，根据容器实际宽度与图片尺寸计算。媒体查询只能作为已确认设备缺陷的最后补丁，不建议仅用像素比识别 iPhone，因为部分安卓设备也会命中。

调试时应记录设备、系统、WebView 类型、视口宽度和页面缩放，并输出容器、轮播项、图片的 getBoundingClientRect()。对比正常与异常设备，通常能判断是素材比例、CSS 计算还是组件初始化问题。远程调试还应检查是否存在全局样式覆盖，以及图片加载后尺寸是否改变。

最可靠的解决方案来自设计与开发共同约束：为每种卡片规定比例，为素材设置中央安全区，为旧内核提供比例容器回退，并在真实应用 WebView 中建立回归设备清单。兼容性不是无限补丁，而是让布局规则在不同环境中仍然可预测。