有用户反馈，在网站上传一份纯文本文件时，页面直接提示格式不支持，或者文件虽然传上去了，打开后却是一堆乱码方块。遇到这种情况，很多人第一反应是文件坏了，或者内容编码有问题。但在网站维护的实际排查中，问题往往不在文件本身，而在类型识别的链路上。TXT被识别成二进制，通常意味着某一层判断逻辑把它的身份认错了。
先看浏览器端的拦截
第一层要核对的是前端。很多上传组件会设置accept属性，用来限制可选文件的类型。如果这里只写了具体的扩展名，或者只允许某几种MIME类型，用户选择TXT时就可能被浏览器直接过滤掉，根本走不到上传接口。需要确认accept里是否包含text/plain，以及扩展名.txt是否在允许范围内。同时注意，不同操作系统对同一扩展名的类型推断并不完全一致，前端不能只依赖一种写法。
再看服务端的判断方式
第二层是服务端的MIME类型判断。常见做法有三种：一是查扩展名映射表，把.txt映射为text/plain；二是读取文件头做内容嗅探；三是两者结合。扩展名映射简单直接，但如果映射表缺失或写错，TXT就会被归到默认的二进制类型。内容嗅探更贴近真实内容，但纯文本没有固定文件头，嗅探算法容易把它误判为application/octet-stream。排查时要确认判断顺序：是先看扩展名，还是先嗅探内容，默认类型又是什么。
第三层容易被忽略，就是存储和回显环节
文件上传后，中间件、对象存储或CDN有时会自动改写Content-Type。即使服务端一开始识别正确，经过这一层也可能被覆盖成二进制类型。需要检查存储返回的响应头，确认Content-Type是否保持了原始判断结果，下载和预览接口有没有重新设置类型。如果预览时前端根据响应头渲染，类型被改写就会直接表现为乱码或无法打开。
可以按五个检查点做回归
一是用户端确认accept和扩展名过滤是否放行TXT；二是接口层确认接收到的文件类型字段；三是服务端确认映射表、嗅探逻辑和默认类型；四是存储层确认Content-Type是否被改写；五是回显层确认预览和下载接口的类型设置。修复后，用几个不同来源的TXT样本重新上传，包括纯英文、中文、带BOM和不带BOM的版本，逐一验证识别结果是否稳定。
这类问题的核心不是文件格式本身，而是每一层对类型的理解是否一致。it数运在网站维护中一直强调把技术问题说明白，把交付过程做清楚，类型识别链路正好是这种思路的典型场景。把每一层的判断依据理清楚，问题就不再靠猜。
