手机拍完照片直接上传，后台提示成功，网页端却只显示空白或一个裂开的图标——这类反馈在网站维护中并不罕见。用户用的是苹果手机，相册默认保存为HEIC格式，文件本身完好，症结往往出在浏览器端。HEIC压缩效率高、体积小，但主流桌面浏览器对它的解码支持并不完整，不少环境直接打开就是无法显示。因此遇到这类问题，先别急着怀疑网络或存储，而应顺着文件从上传到呈现的路径逐层核对。
第一层，先看文件本身。确认扩展名与实际编码是否一致。有些文件被手动改过后缀，名字写着jpg，内部编码仍是HEIC，服务端按jpg处理自然出错。核对方法是读取文件头信息，看真实格式是否与扩展名匹配。同时要确认用户上传的是手机实拍原图，而非经过某些工具转换后又改名的文件。实拍原图编码相对规范，改后缀的文件往往在解码环节暴露问题。这一层确认清楚，后面的排查才有意义。
第二层，看服务端识别。上传接口如果只按扩展名判断文件类型，就会把HEIC当成普通图片放行，后续流程没有针对它做特殊处理。需要核对接口的类型判断逻辑，是读取文件头还是只看后缀。再看转码队列是否真的收到了这个任务，有的系统在入库后就把文件存起来，转码环节根本没有触发，前端拿到的仍是原始HEIC地址。任务有没有入队、有没有执行记录，这两项要逐一确认。
第三层，看浏览器兼容。前端页面如果直接引用原文件地址，等于把HEIC交给浏览器自己解码，支持不了就显示空白。正确做法是前端统一引用转码后的通用格式地址，比如JPEG或WebP。核对时打开页面源码，看图片标签指向的是原文件还是转码产物，两者路径通常不同。如果前端仍指向原文件，说明转码结果没有被正确回填。
第四层，看转码与回退。转码本身可能失败，比如解码库版本旧、内存不足、任务超时。失败之后如果没有任何兜底，页面就只剩空白。需要确认转码失败时是否有占位图和文字提示，让用户知道这张图暂时无法预览，而不是以为网站坏了。同时要有失败日志，方便定位是个别文件问题还是批量问题。
把上面几层串起来，可以形成一份核对清单：确认扩展名与真实编码一致，确认上传接口按文件头判断类型，确认转码任务已入队并执行，确认前端引用的是转码后地址，确认转码失败有占位与提示。按这个顺序走，多数HEIC显示问题都能定位到具体环节。it数运在网站维护流程中，会把图片格式兼容作为上线检查的一项，转码失败留痕、前端地址统一管理，减少这类问题反复出现。
