直接用mode="widthFix"实现等比缩放：图片宽度铺满容器（如100%或750rpx），高度按原始宽高比自动计算，不拉伸不变形，需配合明确宽度控制，且父容器不可不定宽高；常见错误是仅设width: 100%而未设mode或误用scaleToFill。
uni-app图片列表怎么用mode="widthFix"实现等比缩放
直接用widthFix是最轻量、最稳定的做法，它让图片宽度铺满容器（比如100%或750rpx），高度按原始宽高比自动计算，不会拉伸变形。这是图文混排、商品列表、新闻卡片里最常用的方式。
常见错误是只写width: 100%但没设mode，结果图片被强制拉宽；或者用了scaleToFill导致严重失真。
-
mode="widthFix"必须配合明确的宽度控制（如width: 100%、width: 400rpx），否则无效 - 如果父容器本身宽高不定（比如flex子项未设
flex-shrink: 0），图片可能被压缩成一条线 - H5端要注意：某些老版浏览器对
image内联元素的width: 100%支持不一致，建议外层加display: block
swiper里多图并排 + 动态缩放怎么配previous-margin和next-margin
想一屏看到“当前图放大 + 左右各露一点”，不能只靠CSS，得靠swiper原生属性控制布局逻辑。previous-margin和next-margin才是决定“露出多少”的关键参数，不是视觉边距，而是内部预留空间。
例如设置previous-margin="60rpx"，意味着当前第一个可见item左侧会空出60rpx，供上一个item“探头”——这个值必须和卡片实际宽度、缩放比例联动计算。
- 卡片原始宽度为
300rpx，想让左右各露出1/3，则previous-margin和next-margin都设为100rpx - 缩放动画要绑定
@change事件，通过detail.current拿到当前索引，再动态更新transform: scale()，别直接改width/height - 在App端，
display-multiple-items和previous-margin同时设置时行为不稳定，建议二选一，优先用后者
movable-area实现双指缩放时，scale-min和scale-max怎么设才合理
movable-view的缩放不是“图片自身缩放”，而是整个可移动区域的变换，所以scale-min和scale-max直接影响用户能否看清细节、是否容易误操作。
设scale-min="0.8"会导致初始状态就缩小，文字模糊；设scale-max="8"则手势稍大就飞出视口，失去控制感。真实项目中这两个值需要平衡体验与实用性。
- 常规图文预览场景：
scale-min="1"（不缩小）、scale-max="3"（最多放大3倍）足够清晰且可控 - 如果图片分辨率极高（如扫描文档），可放宽到
scale-max="4"，但务必配合damping="200"减缓拖拽惯性，否则松手后还会滑很久 - 不要在
movable-view上直接写width/height，它会覆盖缩放计算；所有尺寸应由父级movable-area控制
不同平台下图片缩放行为不一致，怎么统一处理
微信小程序里movable-area支持双指，但H5端需额外监听touchstart/touchmove模拟；App端又默认启用draggable属性干扰缩放逻辑。这种差异不是bug，是平台能力边界决定的。
强行写一套通用JS处理所有平台，反而增加维护成本。更务实的做法是分层适配：基础展示用mode，交互增强用条件编译。
- 微信小程序和App端走
movable-area路线，H5端降级为uni.previewImage全屏预览（它原生支持缩放） - 用
#ifdef H5包裹H5专属逻辑，避免在小程序里加载无用touch事件监听器 - 所有图片URL必须走
uni.downloadFile本地缓存后再渲染，否则iOS下双指缩放时频繁网络请求会卡顿
实际最难的不是写代码，是判断什么时候该用widthFix，什么时候必须上movable-area——前者解决“显示正确”，后者解决“交互自由”。很多团队踩坑，是因为在商品列表页强行给每张图加双指缩放，结果滚动卡顿、内存飙升。把缩放功能留给点击进入详情页再触发，才是多数场景下的合理选择。
