files.probecontenttype() 是基于路径的分层探测机制，按扩展名→系统探测→魔数比对顺序 fallback，结果仅为启发式猜测，不可靠；推荐按场景选用 apache tika 或多维度校验。
Files.probeContentType() 不是靠“解析变量”工作的，它根本不处理任何运行时变量或配置字符串；它是一个基于路径触发探测行为的静态方法，返回值（如 text/html）是探测结果，而非输入参数。它的底层逻辑是一套分层、有优先级、平台相关的类型推断机制，不是解析、也不是匹配用户传入的 MIME 字符串。
探测流程：从扩展名到文件头，逐层 fallback
该方法内部按固定顺序尝试多种策略，任一环节成功即返回，不再继续：
- 先查文件扩展名：用内置映射表（如
.html → text/html、.js → application/javascript），这是最快最常命中的一层 - 若扩展名无映射或为空，尝试调用系统级探测器：在 Linux/macOS 上可能执行
file -i命令，在 Windows 上依赖注册表关联或系统 API（具体取决于 JDK 实现） - 部分 JDK（如 OpenJDK）会读取文件前 512 字节，比对已知“魔数”（magic bytes）：例如
89 50 4E 47对应 PNG，FF D8 FF对应 JPEG - 全部失败时，返回
null；某些 JDK 实现可能退化为application/octet-stream，但规范不保证
FileTypeDetector 是可插拔的探测引擎
JVM 启动后维护一个全局的 FileTypeDetector 列表，探测过程本质是依次调用这些实现的 probeContentType(Path) 方法：
- 默认包含
RegistryFileTypeDetector（Windows 注册表）、MimeTypesFileTypeDetector（扩展名查表）等 - 可通过
META-INF/services/java.nio.file.spi.FileTypeDetector文件注册自定义探测器，放在 classpath 的 JAR 中 - 探测器加载使用
ServiceLoader，按类路径顺序发现，但具体调用顺序由 JVM 实现决定，不可控
结果不可靠：这不是内容校验，只是启发式猜测
返回的 MIME 类型（如 text/html）仅表示“当前策略下最可能的类型”，不具备权威性或安全性保障：
- 扩展名可被任意修改，
malware.exe改成report.html就会返回text/html - 不验证文件结构完整性，损坏的 PDF 可能仍报
application/pdf - 对 ZIP 容器类格式（
.docx、.jar、.epub）常误判为application/zip或application/octet-stream - 不同操作系统、JDK 版本、是否启用系统命令，会导致同一文件返回不同结果
替代方案建议：按场景选更稳的方式
若需更高置信度，不应只依赖 probeContentType()：
- 上传文件校验：用 Apache Tika（基于深度内容分析，支持数百种格式）
- 服务端强类型判断：结合扩展名 + 文件头 + 业务规则（如要求 HTML 必须含
） - 安全敏感操作（如执行、渲染）：拒绝仅凭 MIME 类型做决策，必须配合白名单、沙箱、内容解析校验
- 纯展示用途（如图标提示）：
probeContentType()足够，响应快、无额外依赖
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
