用户从相册选的照片预览是正的，一上传到 App 就躺倒，是不是压缩那一步把方向弄丢了？

先说结论：用户上传后照片方向转了 90 度，多数不是手机拍错，也不是用户姿势问题，而是照片文件里的 EXIF 方向标记在压缩、裁剪或转码那一步丢了。相机存图时往往按传感器方向写像素，方向值单独放在 EXIF 的 Orientation 字段里；上传链路重新编码时若没把方向烧进像素，展示端可能按默认方向渲染，横图就变竖、竖图就躺倒。2026 年做定制 App 时，这类问题仍常见，值得在图片模块需求阶段就写清。

照片里的 EXIF 方向标记，到底是什么

照片文件不只有像素。手机拍照时会写一段元数据，记录光圈、快门、机型，也记录一个叫 Orientation 的整数，常见取值 1 到 8，分别代表不旋转、顺时针 90 度、180 度、镜像等几种情况。它相当于在照片背面贴了张纸条：请把我转过来再看。

问题在于，这张纸条不是所有软件都认。浏览器、部分安卓图片控件和不少后端图像库默认会忽略 Orientation，只按像素矩阵画图。所以在相册里看着是正的，进了 App 或网页就歪了——不是图变了，是读图的人没看纸条。这也是同一条上传链路在 iOS 与 Android 两端表现不一样的原因之一。

为什么这个 90 度值得单独处理

方向错误看起来只是图歪了，但影响不止观感。证件、票据、合同这类上传场景里，方向不对会影响识别准确率，OCR 和人工审核都可能在歪图上认错字段。对做电商、二手交易的 App 来说，歪图还会拉低商品详情页的可读性，间接影响转化。

另一个成本是发现晚。方向问题在开发机和模拟器上常常复现不出来，往往要等真实用户反馈才暴露，而此时已经上线，改动要重新提审、重新灰度。按 2026 年常见的应用市场节奏，一次发版到全量通常要几天，这个延误本身就是成本。所以在图片模块的需求阶段就把方向写清楚，比上线后补要省事。

方向是在哪一层丢的：五步链路逐个看

按 2026 年常见的项目交付习惯，从用户按下快门到图片出现在 App 里，中间大致走五步，方向出问题基本落在后四步。

• 拍照与存图（第 1 步）：系统相册通常已做视觉纠正，用户看到的是正的；如果这一步就歪，问题在相机权限或第三方拍照控件上。
• 选择与读取（第 2 步）：从相册取图时，有的框架会先做一次旋转归一化，有的直接读原始文件，两条路都可能丢方向。
• 压缩与裁剪（第 3 步）：丢方向的高发环节。压缩库如果只重写像素、不复制 EXIF，方向值就没了。
• 上传与转码（第 4 步）：服务端再做一次缩略图或格式转换，同样可能二次丢弃。
• 展示（第 5 步）：渲染控件认不认 Orientation，各端默认行为不完全一致。

判断方法很直接：拿同一张原图和压缩后的图，分别看 EXIF 里的 Orientation 是否还在。前后不一致，就说明丢在了压缩那一步；如果压缩后还在、显示仍是歪的，那问题在展示端读图策略上。

三条可对照的处理路线

方向问题本质是“谁负责把纸条兑现”。常见有三条路线，改动位置、周期和适用对象不一样，可以按项目情况对照选择。下面周期是经验区间，不是承诺值。

1. 路线 A：上传前在客户端把方向烧进像素。读 EXIF，按 Orientation 先旋转再压缩，输出即所见。改动集中在客户端，常见区间约 1 到 3 人天，适合以手机拍图为主的 App。
2. 路线 B：服务端统一纠正。接收原始文件，后端读 EXIF 再旋转，并同步生成缩略图。逻辑集中、便于统一口径，但要占用服务端算力，处理大图时耗时和带宽会增加，常见区间约 2 到 5 人天，另加服务端资源成本。
3. 路线 C：只改展示端。展示时按 Orientation 加一层旋转。看似省事，但导出、转发、下载到别的工具时又会歪，属于把问题往后推。常见区间约 0.5 到 1 人天，但返工概率偏高。

经验上，只要 App 存在下载原图、导出或第三方查看的场景，更适合走 A 或 B，而不是 C。A 和 B 也可以叠加：客户端先烧方向，服务端再做兜底校验，代价是链路更长、排查时要多看一层日志。预算紧、周期短时，优先把 A 做扎实，通常能覆盖大部分用户反馈。

交付现场：常见坑与合格标准

在项目里常见这样的情况：预算和周期都紧，图片模块排在后面，需求方只给了“能传能看”四个字。做法往往是直接调一个压缩库，把体积降下来就算完。结果上线后用户反馈竖图躺倒，返工要重新过一遍客户端、服务端和展示端三处，经验区间是追加 2 到 5 人天，还要补一轮真机回归。这类交付现场经验说明，方向处理不适合完全交给默认参数。

要避免走到这一步，交付前可以按下面几条核对，做到算合格：

• 输入侧：明确支持的图片来源，拍照、相册、第三方分享各测一遍方向。
• 处理侧：确认压缩与裁剪后方向是被正确烧进像素，而不是简单复制或直接删除 EXIF。
• 输出侧：上传成功后的缩略图、原图、列表图三处方向一致。
• 验收侧：iOS 与 Android 各出一台真机，用横拍、竖拍、倒拍三种姿势交叉测。

反例也很典型：只在模拟器里用一张已经是正的测试图验收，三端全过，上线就翻车。方向问题不看设备型号，看的是拍摄方向和读取路径，测试图更适合来自真实相机。一些做定制交付的团队，会把方向单独列进图片模块的验收清单，而不是混在“图片功能正常”一条里。

适用场景与边界

适合提前处理的情况：用户会拿手机拍实物、证件、票据、现场照片；图片会被人下载、导出或转发到微信等外部工具；同一张图要在多个端展示。这几类场景里，方向处理属于基础项，不处理后续往往要补。

不必单独上方案的情况也有：图片全部来自设计稿或素材库、方向本身就统一；或者只做内部使用、图不落盘也不导出。这种情况下为一个方向字段加一层处理，反而多一个维护点，按需即可。边界可以这样记：只要图片会离开 App 的展示环境，方向就更适合被固化进像素。

常见问题

同一张图 iOS 上正、Android 上歪，是哪个系统有毛病吗？

不算毛病，是两个系统读图策略不同：一个默认认 EXIF 方向，一个默认忽略。统一在上传前烧进像素就能规避。

加个旋转按钮让用户自己转，行不行？

能救急，但把纠错成本转给了用户，同一张图每次都要手动转。只适合图片量很小、方向问题偶发的场景。

图片压缩后方向还是错的，问题一般出在哪？

多半是压缩库重写像素时没保留或没应用 Orientation。先对比压缩前后的 EXIF，再决定改读取还是改压缩参数。

服务端已经做了纠正，客户端还要不要处理？

看链路。若存在客户端直传对象存储、绕过服务端的情况，客户端仍要处理，否则这条支路会漏。

只有安卓端反馈歪图，iOS 一直正常，要不要优先查安卓？

可以先看安卓的取图方式和压缩库版本，同时别忽略服务端转码这条公共路径，它也影响两端。

实际推进时，建议把方向正确写进图片模块的验收清单，而不是等用户反馈再补。若是外包交付，可在需求阶段就确认压缩与转码环节由谁负责、按什么口径验收。图片量极少、不导出不外发的内部工具，先做本地方案即可，不必为此额外加一层服务端处理。