files.probecontenttype() 可能返回 null，因其仅检查文件前几百字节、扩展名及系统配置，不读取全文件；空文件、无扩展名、缺失libmagic或注册表未关联时均易失败。

Files.probeContentType() 能识别常见文件类型，但别指望它 100% 准确——它依赖系统底层的 MIME 类型探测机制（如 libmagic 或 Windows 注册表），对无扩展名、内容简短或自定义格式的文件经常返回 null。

为什么 probeContentType() 会返回 null

这不是 Java 的 bug，而是设计使然：它不读取全部文件内容，只查前几百字节 + 文件扩展名 + 系统配置。以下情况极易失败：

• 文件没有扩展名（比如临时文件 tmp123）
• 文件是空的，或只有几行纯文本（hello\nworld 不足以触发 text/plain 判定）
• 系统未安装 libmagic（Linux/macOS 默认可能缺失），或 Windows 上注册表未关联该扩展名
• 文件是压缩包内嵌资源（如 ZIP 中的 style.css），probeContentType() 只看路径，不打开 ZIP

如何提高识别成功率

关键不是“调用一次就完事”，而是分层 fallback：

• 先用 Files.probeContentType(path) 快速试探
• 若返回 null，再根据 path.getFileName().toString() 查扩展名映射（用 Files.getFileExtension() 辅助提取）
• 仍不确定？读取前 1024 字节，用简单规则判断：以 "#" 开头且含 "\n" → text/x-shellscript；含 "<?xml " → application/xml；开头是 0x89 0x50 0x4E 0x47 → image/png
• 避免读整个大文件——Files.readAllBytes() 在 GB 级文件上会 OOM

Windows 和 Linux 行为差异

同一段代码在不同系统可能返回不同结果：

• Windows：优先查注册表中 HKEY_CLASSES_ROOT\.txt\Content Type，哪怕文件内容是二进制也返回 text/plain
• Linux/macOS：依赖 file -i 命令背后的 libmagic 数据库，更看重文件头，但需确保 mime.types 或 /usr/share/misc/magic 存在且可读
• 容器环境（如 Alpine）常缺 libmagic，probeContentType() 基本失效，必须手动 fallback

真正麻烦的不是写不对代码，而是忘记检查返回值是否为 null——生产环境里一个没处理的 null 可能导致后续 HTTP 响应头写成 Content-Type: null，浏览器直接下载而不是渲染。