如何解决 Windows 10 下 Maven 测试因字符编码失败的问题

Windows 10 环境中 Ma ven 执行测试时出现乱码（如“Текст”），导致含非拉丁字符的断言失败，而 IDEA 内运行正常——根本原因是 Ma ven Surefire 插件默认未显式指定 UTF-8 编码，需在 pom.xml 中配置 ma ven-surefire-plugin 的 encoding 参数。

在 Windows 10 环境下，你是否遇到过这样的场景：在 IntelliJ IDEA 里运行单元测试一切正常，但一到命令行执行 mvn test，测试就莫名其妙地失败了？控制台输出的日志里，原本清晰的中文或俄文变成了类似“Текст”的乱码，导致字符串断言直接崩溃。这背后的“元凶”，正是字符编码在作祟。

问题的根源在于环境差异。Windows 系统的默认控制台编码（如 CMD 的 GBK 或某些区域的 CP1251）与 Ja va 项目普遍采用的 UTF-8 编码之间，存在一道看不见的鸿沟。你的 Spring Boot 项目源码、资源文件以及测试数据很可能都是 UTF-8 编码，但 Ma ven 默认调用的测试执行引擎——ma ven-surefire-plugin——并不会自动继承你在 pom.xml 中设置的全局编码（如 project.build.sourceEncoding）。这就导致了测试进程在读取或输出字符串时，使用了错误的编码集，从而引发比较失败。

为什么常见的配置会失效？

很多开发者首先会检查并确认全局编码设置：

  UTF-8
  UTF-8

甚至尝试在插件配置里加入 JVM 参数：-Dfile.encoding=UTF-8。然而，测试依然失败。这是为什么呢？

关键在于理解 -Dfile.encoding 这个参数的作用范围。它主要影响的是 FileReader、FileWriter 这类依赖于平台默认编码的 API。但对于控制台输出（System.out）、字符串的字节转换（String.getBytes()）或者没有明确指定编码的 InputStreamReader，它的保证并不完全。更需要注意的是，ma ven-surefire-plugin 从 2.22.0 版本开始，已经弃用了原先用于报告生成的 encoding 属性。真正决定测试执行期字符串处理行为的，是传递给 JVM 的 argLine 参数，并且必须确保它被正确且优先地应用。

✅ 一劳永逸的解决方案

最可靠、兼容性最佳的做法，是在项目的 pom.xml 中显式声明并配置 ma ven-surefire-plugin，统一指定编码参数。下面是一个经过验证的配置示例：

  
    
      org.apache.ma ven.plugins
      ma ven-surefire-plugin
      3.2.5 
      
        -Dfile.encoding=UTF-8
        
        
          UTF-8
        
      
    
  

这个配置的核心是两重保障：通过 argLine 设置 JVM 启动参数，同时通过 systemPropertyVariables 强制设置系统属性，确保编码设置在整个测试生命周期内生效。

⚠️ 实施时的关键注意事项

仅仅修改配置还不够，以下几个细节同样关乎成败：

• 插件版本：如果项目中从未声明过该插件，Ma ven 会使用其内置的旧版本，这些版本可能包含已知的编码相关缺陷。因此，显式声明并指定一个较新的版本（建议 2.22.0 及以上）是避免踩坑的好习惯。
• 终端环境：Windows 自带的 CMD 或 PowerShell 对 UTF-8 的原生支持有限。推荐在 IntelliJ IDEA 的终端、Git Bash，或者更现代的 Windows Terminal（并启用 UTF-8 支持）中运行 mvn test。如果必须在 CMD 中操作，可以临时执行 chcp 65001 切换到 UTF-8 代码页，但这并非持久化解决方案。
• 文件编码：请务必确认你的 .ja va 源文件、application.properties/yml 配置文件、以及测试用到的资源文件（如 test-data.txt）均以 UTF-8 无 BOM 格式保存。这是所有工作的基础。
• Spring Boot 配置：如果测试使用了 @SpringBootTest 并加载包含非 ASCII 字符的配置项，还需要确认 Spring Boot 的编码设置。Spring Boot 2.4 及以上版本默认会处理，但更早的版本可能需要你在配置中显式指定 spring.config.encoding=UTF-8。

完成以上配置和检查后，再次执行 mvn clean test，那些因乱码而失败的测试用例应该就能顺利通过了。这套方案兼顾了不同环境的可移植性和编码行为的确定性，堪称 Ma ven 项目在多语言、跨平台环境下的标准实践。