有用户上传了一本电子书，扩展名是MOBI，点开预览却提示格式不支持。换成EPUB上传同一本书，阅读器又能正常翻页。这类问题常被误判为文件损坏，实际上多数情况是格式识别环节没有对上。MOBI、EPUB、AZW3都属于电子书容器，但内部结构、压缩方式和阅读器支持程度差别明显，扩展名相同不代表解析链路能走通。
先核对文件头标识。文件扩展名是用户或系统命名的结果，文件头才是格式的真实身份。MOBI类文件通常在起始位置带有特定的标识字节，EPUB本质是ZIP容器，开头能看到压缩包的通用特征。维护人员可以用十六进制查看工具读取文件前几十个字节，确认实际格式与扩展名是否一致。常见情况是用户把AZW3改名成MOBI，或者把网页另存的文件直接加上MOBI后缀。扩展名与文件头不符时，解析组件按扩展名调用MOBI解析器，自然会失败。这一步的判断标准很简单：文件头特征与扩展名声明一致才进入下一步，不一致就按真实格式重新路由。
再核对阅读器或解析组件的支持清单。不同阅读组件对电子书格式的支持范围不同，有的只支持EPUB，有的支持MOBI但不支持带DRM的版本，有的对AZW3只做有限解析。维护时需要整理一份明确的支持清单，写清每种格式的支持程度和降级顺序。比如MOBI解析失败时，可以先尝试按EPUB容器规则读取，再尝试提取纯文本内容供预览。降级顺序要固定下来，避免每次遇到问题临时判断。清单还应标注哪些格式属于只可下载不可在线预览，让用户在上传前就有预期。
还要核对服务端转码流程。很多网站为了统一预览体验，会把上传的电子书转成通用格式再展示。转码失败时，日志里通常能看到解析器返回的错误类型，是文件头不识别、容器结构异常，还是编码转换中断。定位时先看转码任务在哪一步退出，再对照原始文件的文件头信息，判断是格式误判还是文件本身不完整。转码失败后要有回退策略，比如保留原文件供下载，同时给用户一条明确提示，说明当前格式暂不支持在线预览，而不是只弹一个笼统的失败提示。
落到日常维护，可以按下面的清单检查。上传入口先做文件头校验，扩展名与文件头不一致时直接提示用户；维护一份格式白名单，写清每种格式的支持方式和降级路径；失败提示文案要具体，区分格式不支持、文件不完整和转码异常三种情况；保留人工兜底通道，遇到特殊文件可以转交人工确认。这套做法把格式识别放在入口处，问题在用户上传时就能暴露，不必等到预览环节再排查。
it数运在网站维护中一直强调把技术问题说明白、把交付过程做清楚。电子书格式识别看似是小环节，但把文件头校验、支持清单和转码日志三处对齐，用户遇到的打不开就会少很多。维护工作的价值往往就体现在这些具体判断上。
