一句话总结
Facebook 只有在两个条件同时成立时，才会把一张图片渲染成可拖动的 360° 球面：图片本身是 2:1 的 equirectangular 全景，并且文件里带着声明"我是全景"的 GPano XMP 元数据。少任何一个，Facebook 都会按普通照片处理——一张又宽又拉伸的长方形，拖不动也转不了。
绝大多数"Facebook 360 照片不能用"的情况，卡的都是第二个条件：相机拍下来时元数据是好的，后来某个修图软件在保存时把它悄悄丢掉了。所以先检测、再动手，比凭感觉猜原因省时间得多。
为什么 Facebook 把 360 照片显示成平面图
360° 照片并不是一种特殊的文件格式。它就是一张普通图片，只不过像素按 equirectangular 投影排列，外加一段 XMP 元数据，告诉读取它的程序："这是一个完整球面，请按球面映射。"把这段元数据剥掉，像素一个都没变，但从此所有 App 看到的都只是一张特别宽的普通照片。
大多数翻车都是这么来的。Ricoh Theta、Insta360 或其他 360 相机在拍摄时会正确写入元数据，然后你在 Photoshop 里裁一刀、在 Lightroom 里调个曝光、丢进压缩服务、或者用聊天软件转发一次——保存路径重写了文件，却没把 GPano 那一段带过去。很多软件能老老实实保留 EXIF（相机型号、日期、GPS），却不一定会保留它不认识的 XMP 扩展命名空间。文件看上去毫无变化，但在 Facebook 眼里已经是平面图了。
第二个常见原因出在上传环节。自 2020 年前后 Facebook 界面改版以来，它对 360 上传的处理明显更严格。判定发生在上传那一刻：照片要么带着有效的 360 元数据进来，要么就被当成平面图处理。同一个坏文件反复重传，或者换台设备发，都救不回球面。
快速检测：这真的是一张 360 照片吗？
在动任何元数据工具之前，先搞清楚坏掉的到底是哪个条件。把文件拖进360° 全景查看器——纯浏览器运行，不上传、不注册——然后看它的「图片体检」面板。它会告诉你：
- 尺寸和分辨率档位，以及宽高比是否符合 equirectangular 要求的 2:1。
- 文件里到底有没有 GPano XMP 元数据。
- 文件大小，方便你核对导出这一步实际吐出来的是什么。
然后照着结果判断：
- 2:1，元数据存在 → 文件本身没问题，问题在别处：上传失败、缓存没刷新，或者你发帖用的那个客户端。
- 2:1，元数据缺失 → 最常见的情况，直接跳到下面的元数据章节。
- 不是 2:1 → 像素本身就错了，改元数据也救不回来，看下一节。
查看器还会把你直接丢进球面里，这本身就是一次诊断：如果拖动时地平线是弯的、画面在扭，那它在 Facebook 上只会一样糟。
2:1 equirectangular 是硬性要求
Equirectangular 投影把经度映射到水平轴、纬度映射到垂直轴。完整球面横向 360°、纵向 180°，所以正确的全景图宽度永远恰好是高度的两倍：4096×2048、5400×2700、6000×3000。这个 2:1 的宽高比不是审美习惯，而是投影算式成立的前提。
把非 2:1 的图丢给任何 360 渲染器，它照样会把画面硬撑满整个球面：人脸糊掉、地平线歪斜、天顶和天底被挤成一团看不清的东西。手机全景模式扫出来的 3:1 长图是一张宽照片，不是球面，改再多元数据也变不成球面。
Facebook 对 360 照片的尺寸上限是 6000 × 3000 像素，所以为一条 Facebook 帖子专门准备 8K 母版没有意义。直接导出在这个上限以内，还能省掉一次缩放。
如果你手上只是一张普通照片、而不是真正的球面拍摄，那正确做法是先生成一张真全景。照片转 360° 转换器接受 1–3 张参考图，输出标准的 2:1 equirectangular PNG，最高 4K（3840×1920），并会沿用源图的光线和色调。这一步解决的是投影条件；元数据仍然是下面单独的一步。
GPano XMP 元数据到底是什么？
GPano 是 Google 为球面照片定义的 XMP 命名空间：http://ns.google.com/photos/1.0/panorama/。它存放在文件的 XMP 数据块里，和标准 EXIF 并列，是各大消费级平台判断"这张图要不要当球面打开"的依据。
真正做决定的那个字段是：
GPano:ProjectionType = equirectangular这一个标签就是开关。完整的 GPano 规范还定义了描述裁切区域和完整全景尺寸的配套字段，这些在拍摄没覆盖完整球面时才起作用。对一张普通的全球面照片来说，ProjectionType 到位就已经解决了大半问题。
Google Photos 读的是同一个命名空间。所以一个在 Facebook 上正常的文件，通常在那边也正常；反过来，元数据被剥掉的文件会在两边同时出问题。这也说明元数据值得在源文件上一次性修好，而不是每个平台各绕一次弯。
怎么给照片补上 360 元数据
最快的办法。 用 360 全景照片元数据注入器——它完全在浏览器里运行，写入 GPano XMP 标签时不会重新编码文件，而且免费。
桌面软件。 Exif Fixer 是 Keith Martin 开发的 Mac / Windows 工具，也是大多数 360 拍摄者最后落脚的地方——它就是专门用来把丢失的 360 元数据重新写回图片的。Windows 上还有 Exif Pilot，一个通用 EXIF 编辑器，也能直接处理元数据字段，如果你本来就在改其他标签，用它比较顺手。
更好的办法是别把问题弄出来。 最省事的修法不是补元数据，而是一开始就别弄丢：保留相机原片不动，所有编辑都在副本上做，发布前再把导出文件拖回查看器复检一遍。确实要编辑时，优先选导出时保留 XMP 的软件——并且验证结果，而不是假设它还在。
2026 年 Facebook 还支持 360 照片吗？
支持，但有条件。Facebook 仍然会渲染可交互的 360 照片，只是上传文件必须同时满足三点：equirectangular 投影、6000 × 3000 上限以内的 2:1 尺寸、以及声明 ProjectionType = equirectangular 的 GPano XMP 元数据。三点齐了，照片才会变成能拖动的球面；缺一点，你拿到的就是一张平的、被拉伸的图片，而且平台不会告诉你原因。
所以当 Facebook 识别不出你的 360 照片时，按这个顺序排查：先看形状，再看元数据，最后才怀疑平台。把文件拖进 360° 全景查看器，读一下「图片体检」面板里的那两行，几秒钟就能知道你碰到的是三者中的哪一个。
