小程序里上传一张竖拍照片，预览时却横躺着显示，很多人的第一反应是压缩把图片“压坏了”。但压缩改变的是文件大小和画质，并不会重新排列像素的方向。竖拍变横躺，绝大多数情况是方向信息在读取、传递或覆盖的某个环节出了偏差。把问题直接归给压缩，容易在错误的方向上反复调参数，真正的原因反而被放过。
先核对原始文件。手机拍摄的照片通常带有EXIF方向标记，用来记录拍摄时传感器的朝向。用系统相册打开原图，如果显示正常，说明方向标记存在且被系统识别。接着看小程序上传组件拿到的文件对象，是否保留了完整的EXIF信息。部分组件在选取图片时会默认压缩或裁剪，这一过程可能直接丢弃方向标记。验证方法很简单：上传前后分别读取同一张图的EXIF，对比方向字段是否还在。如果上传前有、上传后没有，问题就出在选取或压缩环节。
再核对服务端处理链路。图片到达服务器后，常会经历缩放、转码、生成缩略图等步骤。某些图像处理库在重新编码时默认不写入方向标记，或者按像素直接输出，导致方向信息丢失。逐步验证的方法是：先保存一份未经任何处理的原始上传文件，再保存一份经过服务端处理后的文件，分别读取两者的方向字段和像素尺寸。如果原始文件带标记、处理后标记消失，说明服务端在二次编码时丢弃了方向信息。此时应检查处理库是否提供保留元数据的选项，或在读取阶段先按方向标记旋转像素，再进入后续流程。
然后核对前端展示层。图片最终显示时，CSS变换可能与图片自身的像素方向叠加。常见错误写法包括：对已经按方向标记旋转过的图片再次施加旋转，导致转两次变成反向；或者容器设置了固定的宽高与旋转角度，图片按原始像素比例填充后出现横竖错位。还有一种情况是背景图与前景图方向处理不一致，视觉上像是图片被压扁。检查时先把CSS中所有旋转、翻转相关的声明临时去掉，观察图片是否恢复正确方向。如果去掉后正常，说明展示层存在重复旋转；如果仍不正常，再回到前两个环节继续排查。
把三段串起来，可以形成一份检查清单。上传段：确认选取组件是否保留EXIF，压缩参数是否影响方向字段，必要时关闭自动压缩做对比测试。存储段：确认服务端处理库的元数据策略，缩略图与原图是否采用同一方向基准，转码前后各存一份样本比对。展示段：确认CSS变换是否与像素方向叠加，容器比例是否与图片实际比例匹配，背景图与前景图是否使用同一处理逻辑。修复优先级上，先解决上传段的方向标记丢失，因为这是源头；再处理服务端的二次编码问题；最后清理展示层的重复变换。顺序反过来做，容易在展示层反复调样式，却掩盖了源头的标记缺失。
方向问题的定位顺序可以概括为：先看原图有没有标记，再看上传有没有传标记，再看服务端有没有丢标记，最后看展示有没有多转一次。每一步都用同一张测试图做前后对比，避免多因素混在一起。it数运在小程序开发的需求梳理阶段，会把图片上传的完整链路拆成选取、传输、处理、展示四段，逐段确认方向信息的传递方式，交付核对时也用固定测试图走一遍全流程，减少上线后因方向问题反复返工的情况。
