Files.probeContentType()识别伪造文件类型方法

Java 的 `Files.probeContentType()` 方法通过分析文件内容（而非扩展名）来识别真实 MIME 类型，是防范用户伪造文件后缀、绕过前端校验的关键辅助手段；但它并非万能——受限于文件头检测机制，存在误判风险且无法发现嵌套恶意代码，必须与服务端重命名、严格白名单、二次解析验证（如 ImageIO/PDFBox）、沙箱扫描等多层防御策略协同使用，才能构建真正鲁棒的文件上传安全体系。

Files.probeContentType() 本身不能直接解决伪造扩展名的安全隐患，但它可以作为**内容检测的辅助手段之一**，配合其他措施共同防御。关键在于：它检查的是文件“实际内容”的 MIME 类型，而非文件名或扩展名。

probeContentType() 的作用与局限

该方法基于文件头（magic bytes）推测内容类型，例如读取前几百字节判断是否为 PNG、PDF 或 ZIP。但它：

• 不保证 100% 准确（尤其对格式模糊、无明确 magic bytes 的文本类文件）
• 无法识别恶意代码嵌入在合法格式中的情况（如带宏的 Excel、含 XSS 的 SVG）
• 依赖系统安装的 mime.types 和 JVM 实现，不同环境结果可能略有差异
• 对空文件、极小文件或自定义二进制格式支持有限

真正有效的防御组合策略

仅靠 probeContentType() 不够，需分层验证：

• 服务端重命名 + 随机文件名：丢弃用户上传的原始文件名，用 UUID 或哈希生成新名，彻底切断扩展名信任链
• 白名单校验内容类型：用 probeContentType() 获取类型后，只允许预设安全类型（如 "image/png", "application/pdf"），拒绝 "text/html"、"application/x-executable" 等高风险类型
• 二次解析验证：对图片调用 ImageIO.read() 尝试解码；对 PDF 用 PDFBox 检查结构；对 Office 文档用 Apache POI 解析——失败即说明内容异常
• 沙箱化处理：对可执行类文件（如 ZIP、JAR）在隔离环境中解压并扫描内部文件头，防止 ZIP Slip 或嵌套恶意格式

实际使用 probeContentType() 的注意事项

不要直接信任返回值，要结合上下文处理：

• 先写临时文件或用 InputStream 包装上传流（注意：probe 需要能 reset 流位置，建议用 ByteArrayInputStream 或缓存前 8KB）
• 若返回 null，说明无法识别，应拒绝而非放行
• 对文本类文件（如 "text/plain"），额外检查是否含脚本标签（