竖着拍的照片网页里是正的，App 列表缩略图却横过来，先改前端还是先改服务端？

照片上传后在网页或 App 里横躺着，多数不是相机拍歪了，而是 EXIF 方向标记（Orientation）在链路的某一环被丢掉，或者被重复应用了两次。判断顺序可以固定下来：先看原图里的 Orientation 值，再看预览端有没有用 Canvas、裁剪组件重绘过像素，最后看服务端生成缩略图时读没读方向。按 2026 年常见交付经验，只要链路上有一处「读了像素却忽略 EXIF」，方向就一定会丢；而只要业务里存在 App 列表、导出海报这类非浏览器的展示出口，方向就应该在服务端固化一次。

一、EXIF 里的方向到底记了什么

手机竖着拍时，不少机型的摄像头模组是按横向安装的，成像先以横向像素矩阵写进文件，再由 EXIF 中的 Orientation 字段告诉看图软件「显示时要转多少度」。换句话说，像素本身并没有转，转的只是一条播放说明。谁按像素阵列重绘了图却没有读这条说明，结果就是横图；反过来，谁把像素转正了却忘了删掉说明，就会被再转一次。

这也解释了为什么同一张图在不同位置表现不一致：浏览器 img 标签在新版内核里默认会应用 EXIF 方向，原图直出看着是正的；而 Canvas 的 drawImage 只认像素阵列，压缩、裁剪、加水印、生成分享海报都属于这一路，走一遍就横了。服务端的图片处理链路同理，只是很多人没有意识到那一步在用哪份数据。

• Orientation 常见取值有 8 种，1 表示正常，3 是 180 度，6 和 8 分别是顺时针、逆时针 90 度；实际项目里 6 和 8 出现频率最高
• 部分安卓相册编辑、截图工具、社交软件转发时会顺手把像素转正并剥掉 EXIF，所以同一批素材里有的带方向、有的不带
• 剥 EXIF 常是出于隐私考虑（比如 GPS 定位），但方向和定位是两件事，不建议用「一律删 EXIF」的方式顺手把方向也删掉

二、方向一般丢在哪一层：一套可命名的四层核对法

方向本质上是「像素 + 元数据」的组合，谁动了像素，谁就负责把方向固化进像素。按这条原则把链路拆成四层，排查时逐层过一遍，比一上来就翻代码省时间，也能避免只修好一端、另一端还横着。

1. 采集层：确认原图里 Orientation 是否非 1、是否已被上游剥掉。先准备一两张横竖混拍的样图确认现象可复现，别拿别人转发过的图当样本。
2. 预览层：分清是 img 直出（多数会应用方向）还是 Canvas、裁剪组件、压缩库（不会自动应用）。这一层决定你看到的「横」是不是假象。
3. 服务端处理层：缩略图、转码、水印、格式转换有没有先按 EXIF 转正再重绘。这一步没做，App 列表和小程序里基本一定横。
4. 分发层：修好之后旧图 URL 有没有变化、CDN 与客户端缓存有没有失效。不少「改了但没生效」其实是缓存在背锅。

四层里服务端处理层是分水岭：它一旦做对，网页、App、导出、分享都能受益；只在前端做，等于把方向问题锁死在浏览器里。现场排查时常见的情形是——现象在第二层看到，根因却在第三层，所以核对顺序不必死守从上往下，先确认服务端有没有读方向往往更快。

三、前端转、服务端转，还是干脆不转

三种做法在成本、覆盖面和后续维护上差别明显。按 2026 年常见项目交付习惯给一组经验对比，具体取值仍要看图片量级和现有技术栈，不必照搬：

• 做法 A 前端 Canvas 按 EXIF 重绘：落地快，经验区间 0.5~2 人天；只覆盖自己的网页端，App、小程序、第三方回传的图照样横；每张图多一次重编码，画质会有损耗。
• 做法 B 服务端统一固化方向：上传时处理一次，全端受益，历史图可批量重刷；代价是要动存储与转码链路，几万张图批量重跑常见区间在 1~6 小时，还得配合缓存失效和回滚预案。
• 做法 C 只存原图、靠浏览器应用：改动量最小；但只要链路上有缩略图、水印、导出 PDF、生成分享海报中的任意一项，就会露馅。

判断口径并不复杂：只要业务里存在非浏览器的展示出口（App 列表、导出、打印、海报），方向就应该在服务端固化一次。前端修可以作为过渡手段，但不适合当长期方案，否则每新增一个出口都要再补一次。

四、什么情况值得做，什么情况不必上

值得做的场景：以手机端用户上传为主、图片要生成多种尺寸缩略图、要加水印或裁剪、要在 Web、App、小程序多端展示，以及有历史图片需要统一方向的后台系统。这类场景里，方向处理属于上传链路的一部分，越早定下来越省事，后面新增出口时也不用再返工。

不必上重方案的情况：纯内部后台系统、图片只做原图直出且只在浏览器里看；素材由设计统一输出、已经转正且不带方向标记；单次上传量很小、对展示精度要求不高的小工具。这些场景硬加一套独立的图片处理服务，运维成本常常超过收益。边界清楚之后，再谈要不要改造链路。

五、交付现场的取舍与验收口径

方向这类问题修起来不难，难在修对且修全。项目里反复出现过的坑大致是以下几类：

• 只在前端转了，服务端缩略图仍是横的（往往等 App 列表被用户反馈才发现）
• 像素转正了但没剥掉原 EXIF，浏览器再应用一次，图变成 180 度（看起来像新出的翻转缺陷）
• 重压时画质参数设得过低，截图类图片文字发虚（需要返工重跑）
• 只处理新图、历史图没重刷，列表里新旧方向混着（观感上像随机出错）

交付现场常见的情况是：素材来自多个部门、多个型号的手机，预算又不允许单独上一套图片处理服务。这类项目通常的做法是，先在上传链路里同步做「按 EXIF 转正 + 剥掉方向标记」，再用现成脚本重刷历史图。经验区间上，几万张图的重刷叠加 CDN 预热，多数落在半天到一晚；代价主要出在旧图 URL 没变、前端仍命中旧缓存上，另外少数老图 EXIF 早已被剥掉、方向无法还原，只能按横竖分布人工抽检。把这段坑写进上传接口的验收清单，比上线后再补要省很多沟通。

验收建议写成可核对的清单，不要停在「看着正常」这一步：

• 准备至少四种 Orientation（1、3、6、8）的样图，横竖各一张走完整链路
• 原图、缩略图、导出图、分享海报四个出口方向一致
• 处理后的文件里不再存在 Orientation 非 1 的记录，同时按隐私要求清理 GPS 等敏感字段
• 抽 20~50 张真实用户图对比处理前后，确认没有过度锐化或明显偏色

常见问题

手机竖着拍的照片在电脑上打开是横的，是相机坏了吗？

多数不是相机故障。文件里存的是横向像素加一条方向标记，电脑上的看图软件没应用这条标记，所以显示成横的。换一个会读方向的软件打开对比一次，基本就能确认。

同一个上传页面，iPhone 传上去是正的、安卓是横的，问题出在哪？

两个系统相机写方向的方式不同，浏览器自动应用 EXIF 的行为也不一致，差别在中转环节而不是上传页面本身。按样图逐层核对一遍，通常能定位到是哪一端在重绘像素。

方向修好以后，有的图反而上下颠倒了，是怎么回事？

像素已经转正，但原文件的 Orientation 没剥掉，浏览器又按标记应用了一次。转正和剥标记要成对做，缺一步就会出现二次旋转，看着像新冒出来的翻转缺陷。

只想删照片里的 GPS 定位，会不会把方向一起删掉？

有可能。整段删 EXIF 会连同方向一起丢。比较稳的顺序是先按方向把像素转正，再清理敏感字段；顺序反了，后面就得整批重刷一遍。

小程序里预览是正的，分享出去的海报却是横的，该查哪一步？

预览走的是会应用 EXIF 的图片组件，海报是服务端按像素重绘。先查生成海报时有没有按方向转正，再叠加文字和背景；没转正的那一步出来的就是横的。

可以先拿四种方向的样图走一遍链路，确认方向丢在哪一层，再决定是前端过渡还是服务端固化；有历史图的，把重刷和缓存失效一起排进计划。边界提醒：图片只做原图直出、素材已统一转正的小系统，不必为此单独上图片处理服务，按现有上传逻辑核对一次即可。