上传了一份TIFF格式的扫描件或设计稿，页面上却只剩一个空白框。进度条已经走完，文件名也出现在列表里，点开却看不到任何图像。遇到这种情况，很多人的第一反应是文件坏了，于是让用户重新导出。但在实际排查中，更常见的原因是浏览器端对TIFF的支持本身就有限，文件本身是完好的，只是当前这条预览链路没有能力把它显示出来。把原因找对，才能决定是转码、限制上传，还是补充提示。
先核对文件本身。TIFF是一个容器性质很强的格式，同样叫TIFF，内部差异可能很大。第一要看是否为多页TIFF，扫描件经常把多页内容放在一个文件里，而多数预览组件只读取第一页，甚至直接放弃解析。第二要看压缩方式，LZW和JPEG压缩在桌面软件里很常见，但部分轻量解码库只支持未压缩或少数几种压缩。第三要看位深和色彩模式，超出常见解码范围的位深、少见的色彩通道组合，都可能让解码中途失败。核对方法不复杂，用系统自带的预览工具打开一次，能正常显示说明文件可读；再用命令行工具查看基本信息，重点确认页数、压缩方式和位深三项，把结果记录下来，作为后续判断的依据。
再核对服务端的解码链路。很多网站的上传逻辑是把原图直接透传存储，前端拿到的就是原始TIFF，浏览器自然无法渲染。如果系统有缩略图生成服务，要确认它是否支持该文件的压缩方式，生成失败时是返回错误、返回空图，还是有一张回退占位图。没有回退机制时，前端拿到的就是一个空白区域，看起来像文件损坏，实际是链路中间断了一环。这一层的判断标准很直接：看存储里有没有生成成功的缩略图文件，看生成服务的日志里有没有对应的失败记录。
第三层核对体积与超时。TIFF单文件达到数十兆并不罕见，扫描件和分层设计稿尤其如此。体积带来的问题有三种，表现却很像。上传超时表现为进度卡住或请求中断，文件根本没有完整到达服务端；缩略图生成超时表现为文件已存储但缩略图缺失，日志里往往有处理时长记录；前端加载超时表现为图片地址可访问，但页面等待一段时间后放弃渲染。区分方法是分别检查存储中的文件大小是否与本地一致、缩略图是否存在、图片地址单独打开是否可访问，三个结果对应三个不同环节，不要混在一起判断。
维护侧可以整理一份检查清单。格式白名单要明确列出允许直接预览的格式，TIFF这类浏览器支持有限的格式单独标注处理方式。转码策略要写清楚是上传时转成通用格式，还是按需生成预览图，以及转码失败时的降级方案。失败提示文案要区分“格式暂不支持预览”和“文件处理失败”，避免让用户误以为文件损坏。日志记录字段至少包含文件名、大小、页数、压缩方式、处理耗时和失败环节，方便后续复盘。it数运在网站维护中处理这类问题时，通常先把问题定位到解码不支持、转码失败或传输超时中的具体一层，再决定是补转码能力还是调整上传限制，而不是一律让用户重新导出文件。
回到最初的问题，预览空白不等于文件有问题。先判断是解码不支持还是传输失败，再决定转码还是限制上传，这个顺序能减少大量无效沟通，也能让维护工作有据可依。
