技能介绍

问题：只看后缀拦不住伪装文件

前端上传校验里最常见的写法是检查 file.name 的后缀，或者直接相信浏览器给出的 file.type。但这两条信息都由客户端提供，攻击者把可执行文件改名成 photo.jpg、把恶意包套上 .pdf 后缀，校验逻辑会「顺利放行」。历史上大量挂马附件、跨站脚本注入的 Office 文档，都是利用这种「后缀即真相」的假设通过前端、再让服务端照单全收。

思路：读文件头，而不是读文件名

文件的真实类型由头部若干字节的签名决定。PNG 固定以 \x89PNG 开头，PDF 以 %PDF- 开头，JPEG 以 \xFF\xD8\xFF 开头。本技能基于 file-type 库，在浏览器端直接读取文件头部字节（只需前几 KB），调用 fileTypeFromBlob 之类的 API 得到真实 MIME 与扩展名，然后和白名单比对。

核心步骤：

封装一个 inspectRealType，内部以文件头签名为准，不信任 file.name 与 file.type
挂接到文件选择与拖拽上传流程，作为第一层拦截
比对结果与业务白名单（如 image/jpeg、image/png、application/pdf）不一致时，toast 中文原因并清空选择
识别失败（无签名文本等）走单独分支：拒绝或标记「未知类型」，策略写死在封装里

边界与注意点

前端只是第一层，服务端必须再校验一次；绕过前端改包是轻而易举的
全程在本地完成，不把整文件上传到第三方鉴权服务
file-type 不同大版本在模块格式（ESM/CJS）与 API 名称上可能有差异，接入时以项目实际可安装版本的文档为准，但「文件头 + 白名单」的语义不变
白名单是可扩展的业务配置，不是技能硬编码的约束