SpringBoot properties中文乱码彻底解决：编码原理与五种实用方案

先给大家讲个我踩过的实在坑SpringBoot项目部署上去之后代码里通过Value(${config.title})注入的配置项数据库里存的好好的日志一打出来却是“æµè¯å颔这种天书更邪门的是本地IDE里跑得好好的一打包到Linux服务器就翻车。我相信凡是搞过Java后端的朋友八成都被这玩意儿折磨过。这个问题的核心在于properties文件的编码机制和Java读取它的默认行为不匹配今天我把这个坑从原理到解法彻底聊透。先说清楚它是什么properties文件本质上是Java定义的资源文件格式按规范它要求使用ISO-8859-1编码但现实中大家写配置文件基本都用UTF-8因为要写中文、日文这些非拉丁字符。SpringBoot继承了Java这套读取逻辑如果你不做任何处理它就会用ISO-8859-1去解码你的UTF-8文件于是满怀期待的中文注释和配置值全部变成一串乱码。它能解决什么问题就是让你在SpringBoot项目中无论用Value注解、ConfigurationProperties绑定还是Environment接口读取都能正确拿到配置文件里的中文内容不用再写\uXXXX这种反人类的Unicode转义也不需要在代码里做二次编码转换。适合谁看刚入坑SpringBoot的新手被乱码坑过但没搞懂原理的初中级开发者以及需要在团队里规范配置管理的同学。我会从编码机制讲起然后给出覆盖不同场景的解决方案每一个方案都附上完整的实操步骤和踩坑记录。1. 问题根源为什么properties天生和中文八字不合1.1 Java对properties文件的编码要求Java的java.util.Properties类从JDK 1.0就存在它的load(InputStream)方法在解析文件时明确规定使用ISO-8859-1字符编码读取字节流。这是Java语言规范层面的硬性约定原因是早期Java设计者为了最大化兼容性选择了一个所有字符都能单字节表示的编码。但这也意味着凡是不属于ISO-8859-1字符集的字符比如中文在文件里必须以\uXXXX这种Unicode转义序列的形式存在否则读取时就会直接丢弃高位字节产生乱码。举个直观例子。UTF-8编码下“测试”两个汉字对应字节序列是E6 B5 8B E8 AF 95。假设IDE把properties文件按UTF-8保存但Java读取时按ISO-8859-1逐个字节解码那么E6 B5 8B就会被解析成“æµ”这三个拉丁字符E8 AF 95会被解析成“试”这就是我开篇日志里那串乱码的真实由来。整个过程不是编码损坏而是解码错误数据本身没丢只是读的方式不对。1.2 SpringBoot的读取链路到底做了什么SpringBoot启动时ConfigDataEnvironmentPostProcessor负责加载application.properties和application.yml等配置文件。对于properties后缀的文件它内部还是走PropertiesPropertySourceLoader而这个Loader最终也是调用了java.util.Properties#load。换句话说SpringBoot并没有在框架层面改变Java对properties文件的编码策略默认就是ISO-8859-1。但这里有个非常容易误解的地方SpringBoot对application.yml和application.yaml的处理却是走YamlPropertySourceLoader这个Loader在解析时使用UTF-8读取。所以同样一个中文配置项你写在application.yml里就能正常显示写在application.properties里就乱码。很多初学者遇到这个问题后一脸懵以为是自己环境有问题其实这就是框架对两种文件格式的编码处理天然不同。另外还要注意一种情况如果你通过PropertySource注解引入额外的properties文件PropertySource本身提供了encoding属性可以指定编码但SpringBoot的配置文件加载机制是独立的不走PropertySource。这就导致很多人照着网上教程给PropertySource加了encoding UTF-8结果application.properties里的乱码依然纹丝不动因为SpringBoot自身加载application.properties时根本没有用到这个注解的逻辑。2. 解决方案总览五条路线怎么选2.1 各方案对比与适用场景我实际排查和解决过不少项目的配置乱码问题总结下来有五种主流方案这里先把它们拉出来做个对比方便大家按自身情况选用。方案改动范围是否根治适用场景设置IDE默认编码为UTF-8开发环境配置否仅保证保存时编码正确所有开发者统一规范设置Maven编译资源编码构建配置部分解决构建期资源拷贝乱码有maven-resources-plugin参与资源处理的项目PropertySource指定encoding单文件加载方式是但仅对该注解加载的文件生效加载自定义properties文件的场景自定义PropertySourceLoader框架级替换是对所有properties文件生效需要彻底解决application.properties中文乱码改用application.yml配置文件格式切换是YAML天然UTF-8新项目或允许切换配置格式的存量项目说句实在话如果你的项目是新的我直接建议你上最后一种方案用application.yml替代application.properties省心省力。但如果项目已经跑起来了配置文件已经积累了一大堆这时候切换格式成本不小那就用第四种方案自定义PropertySourceLoader一劳永逸。2.2 治标与治本怎么平衡这里我说一个比较现实的观点编码问题光靠约定是治不好的。你可以在团队规范里写“所有配置文件使用UTF-8”但总有人用Windows记事本编辑文件总有人IDE右下角编码栏误点了GBK结果文件保存成了其它编码部署上去就是一片乱码。所以我的建议是团队规范要建立但技术手段也必须同步跟上在代码层面强制指定UTF-8读取让系统不依赖于开发者的人为自觉。当然也不能一上来就搞最重的方案。如果只是临时需要加载某个外部properties文件PropertySource就够用如果问题出现在打包后的资源文件中那得先排查maven的资源插件配置。接下来我按从轻到重的顺序把每一步的操作细节讲清楚。3. 环境侧排查与治理IDE、Maven、系统编码三件套3.1 IDE编码设置先确保文件以UTF-8保存先说IDE层面的问题。IDEA和Eclipse默认新建properties文件时编码可能跟项目其它文件不一样。IDEA有个反人类的设计File - Settings - Editor - File Encodings里有一个独立的“Properties Files”编码设置项默认是ISO-8859-1而且它还特意提示“Transparent native-to-ascii conversion”也就是透明启用Unicode转义。这意味着什么即便你把Global Encoding和Project Encoding都改成了UTF-8properties文件也可能是按ISO-8859-1保存的。更坑的是IDEA的“Transparent native-to-ascii conversion”选项它会在编辑时把中文自动转成\uXXXX序列存在磁盘上编辑器里看着是中文实际文件里全是转义字符你打开文件看眉头都皱起来了。这个选项我记得在2020.3版本之后默认是勾选的需要手动取消。正确的设置路径是这样的打开Settings - Editor - File Encodings把Global Encoding设为UTF-8Project Encoding设为UTF-8Default encoding for properties files也设为UTF-8同时取消勾选Transparent native-to-ascii conversion。改完设置后记得用IDEA的File - Invalidate Caches / Restart清理一下缓存否则已打开的文件还保留旧编码状态。改完IDE之后还要注意一个细节如果项目里已经存在乱码文件光改设置不会让乱码自动恢复因为字节在磁盘上已经写坏了。你需要把乱码文件的内容复制出来用支持编码转换的编辑器比如VS Code或Notepad重新按UTF-8编码保存。VS Code打开文件后右下角会显示当前编码点击它可以选择“通过编码重新打开”和“通过编码保存”非常方便。3.2 Maven构建期资源拷贝乱码的排查有一个场景很容易被忽略本地开发正常但用mvn package打成jar包后配置文件里的中文就乱码了。这个问题不在Java读取环节而在Maven的maven-resources-plugin拷贝资源文件时进行了编码转换。Maven默认的资源拷贝编码取决于操作系统。在Windows中文系统上可能默认GBK在Linux上默认UTF-8这就造成了打包环境不一致。解决办法是在pom.xml里显式设置project.build.sourceEncoding和project.reporting.outputEncoding为UTF-8。properties project.build.sourceEncodingUTF-8/project.build.sourceEncoding project.reporting.outputEncodingUTF-8/project.reporting.outputEncoding /properties同时在build节点里配置resources插件强制指定编码build plugins plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-resources-plugin/artifactId version3.3.1/version configuration encodingUTF-8/encoding /configuration /plugin /plugins /build这里我多说一句maven-resources-plugin的encoding参数如果不设置默认会取project.build.sourceEncoding但有些老版本插件有bug最好显式指定。配置完之后执行mvn clean package然后解压jar包用vim或者less直接查看配置文件内容确认中文是否正常。另外还遇到过一种情况开发者在本机把文件保存成了GBK编码然后设置里把Maven的编码配成了UTF-8这时候Maven用UTF-8去读取GBK文件拷贝出来的资源也是乱码。这个坑属于文件本身编码不对不是Maven配置问题需要先把文件另存为UTF-8。3.3 Linux服务器环境变量对LANG的影响部署到Linux服务器后如果发现日志里的中文正常但系统层面读环境变量或者文件时中文乱码这类问题就涉及到系统Locale。虽然Java默认不读取LANG环境变量来解析properties文件但如果你使用Runtime.exec调用外部命令或者通过System.getenv获取环境变量系统Locale会影响外部命令的输出编码。Shell环境验证技巧先执行locale命令查看当前系统的Locale设置重点看LANG和LC_ALL。如果显示POSIX或C说明系统默认不是UTF-8环境有中文相关的操作就可能出问题。可以在/etc/profile或~/.bashrc里添加export LANGen_US.UTF-8确保环境变量层面支持UTF-8。不过我强调一下这不是SpringBoot读取properties乱码的直接原因只是排查时顺带检查一下免得被误导。4. 代码层方案一PropertySource的encoding属性用法4.1 场景定位与基础配置如果你项目里只是额外加载几个自定义的properties文件比如message.properties、custom-config.properties那用PropertySource指定encoding就是最轻量的方案。基础写法如下Configuration PropertySource(value classpath:custom-config.properties, encoding UTF-8) public class CustomConfig { Value(${custom.name}) private String name; }这里的encoding属性是Spring提供的它在读取文件时会使用InputStreamReader并指定UTF-8编码从而绕开Properties.load(InputStream)的ISO-8859-1限制。实测下来这个方案对SpringBoot和传统SpringMVC项目都有效而且不需要额外引入依赖。有一个限制必须提醒PropertySource的value指向的文件路径不能使用通配符也不支持classpath*:这种扫描方式所以只能适用于明确知道路径的场景。如果你的项目有多个环境配置文件比如application-dev.properties、application-prod.properties而这些文件又需要按环境切换PropertySource就不好处理了SpringBoot的profile机制更合适。4.2 结合SpringBoot多环境配置的完整示例先说一个我遇到过的真实场景项目里除了application.properties还有一个biz-dictionary.properties存放业务字典的中文名称这个文件跟环境无关任何环境都要加载。当时我用PropertySource完美解决了问题。但如果你想在application.properties里按环境切换加载不同的自定义properties文件那要配合Spring的PropertySourcesPlaceholderConfigurer来实现。下面给出一个可落地的写法Configuration public class CustomPropertyConfig { Bean public static PropertySourcesPlaceholderConfigurer propertySourcesPlaceholderConfigurer() { PropertySourcesPlaceholderConfigurer configurer new PropertySourcesPlaceholderConfigurer(); configurer.setLocation(new ClassPathResource(config/ activeProfile() -biz.properties)); configurer.setFileEncoding(UTF-8); return configurer; } private static String activeProfile() { return System.getProperty(spring.profiles.active, dev); } }这种方式直接操作PropertySourcesPlaceholderConfigurer它的setFileEncoding方法指定读取编码。不过要注意这个方法必须声明为static否则Spring容器初始化时会因为Bean创建顺序问题报错。这是我实际踩过的坑第一次写漏了static关键字启动直接报BeanCreationException。4.3 动态加载外部properties文件的处理还有一种业务场景配置文件不在classpath内而是放在服务器外部路径比如/opt/config/biz.properties运维可以直接修改而不用重新打包。这时候可以这么搞Configuration public class ExternalConfig { Bean public PropertySourcesPlaceholderConfigurer externalProperties() throws IOException { PropertySourcesPlaceholderConfigurer configurer new PropertySourcesPlaceholderConfigurer(); Path path Paths.get(/opt/config/biz.properties); try (InputStream input Files.newInputStream(path)) { Properties props new Properties(); // 关键用UTF-8的Reader读取而不是load(InputStream) try (Reader reader new InputStreamReader(input, StandardCharsets.UTF_8)) { props.load(reader); } configurer.setProperties(props); } return configurer; } }核心在于使用Properties.load(Reader)重载方法配合InputStreamReader指定UTF-8编码。这里有个识别点Properties类有两个load方法一个接收InputStream按ISO-8859-1解析一个接收Reader按Reader自身编码解析。凡是自定义读取逻辑一律用后者从根源上避开规范限制。5. 代码层方案二自定义PropertySourceLoader一劳永逸5.1 SpringBoot配置文件加载机制的原理解读前面铺垫了那么多现在要说到最彻底的方案了——自定义PropertySourceLoader。要理解这个方案就绕不开SpringBoot配置文件加载器的机制。SpringBoot启动阶段通过ConfigDataEnvironmentPostProcessor扫描classpath下的配置文件它拿到一个文件后会根据文件后缀选择合适的PropertySourceLoader。核心接口定义如下public interface PropertySourceLoader { String[] getFileExtensions(); PropertySource? load(String name, Resource resource) throws IOException; }SpringBoot自带的两个Loader分别是PropertiesPropertySourceLoader负责properties格式和YamlPropertySourceLoader负责yml/yaml格式。框架通过spring.factories机制将这些Loader注册到PropertySourceLoader列表中加载时遍历所有Loader匹配文件扩展名后调用load方法。既然自带的PropertiesPropertySourceLoader用了ISO-8859-1那我们就自己写一个同类型但用UTF-8解析的Loader然后通过spring.factories替换框架默认实现。这里的核心是框架会按照spring.factories里配置的顺序加载Loader同一扩展名只认第一个匹配项。所以只要我们的自定义Loader排在默认Loader前面就能抢先处理.properties文件。5.2 从零实现自定义UTF-8PropertiesLoader上完整代码这个我实际在项目里跑通过import org.springframework.boot.env.PropertySourceLoader; import org.springframework.core.env.PropertySource; import org.springframework.core.io.Resource; import java.io.IOException; import java.io.InputStreamReader; import java.io.Reader; import java.nio.charset.StandardCharsets; import java.util.Collections; import java.util.List; import java.util.Properties; public class Utf8PropertiesPropertySourceLoader implements PropertySourceLoader { Override public String[] getFileExtensions() { // 专门处理properties文件 return new String[]{properties}; } Override public PropertySource? load(String name, Resource resource) throws IOException { Properties properties new Properties(); // 关键点通过Reader读取指定UTF-8编码 try (Reader reader new InputStreamReader(resource.getInputStream(), StandardCharsets.UTF_8)) { properties.load(reader); } if (properties.isEmpty()) { return null; } return new PropertiesPropertySource(name, properties); } }注意PropertiesPropertySource从哪里来它位于org.springframework.core.env包下是Spring Core提供的标准实现。如果你需要支持多文档properties文件SpringBoot 2.4之后引入了profile文档分隔符#---那还要处理getProfiles方法但一般情况下单文档就够用了。我这里刻意保持了简洁没有处理多文档场景因为大多数老项目也用不到这个特性。5.3spring.factories注册与优先级控制自定义Loader写好后必须在META-INF/spring.factories文件里注册否则SpringBoot根本不会加载它。在项目的src/main/resources/META-INF/spring.factories文件中添加org.springframework.boot.env.PropertySourceLoader\ com.example.config.Utf8PropertiesPropertySourceLoader这里有一个很关键的细节PropertySourceLoader的注册位置在org.springframework.boot.env包下而不是org.springframework.boot.autoconfigure。很多人在spring.factories里写错了key导致Loader没生效这是最常见的坑。SpringBoot版本迭代对spring.factories加载顺序有影响。在SpringBoot 2.4版本之前SpringFactoriesLoader.loadFactories会通过AnnotationAwareOrderComparator实例化并排序所以如果多个Loader都声明支持properties扩展名就会按Order注解或Ordered接口排序。但SpringBoot 2.4之后代码逻辑变成了先收集所有实现再按顺序返回第一个匹配的。因此为了保证自定义Loader优先最简单的方式是给类加上Order(0)注解import org.springframework.core.annotation.Order; Order(0) public class Utf8PropertiesPropertySourceLoader implements PropertySourceLoader { // ... }同时SpringBoot项目还可能同时存在多个spring-boot版本依赖导致spring.factories合并顺序不可控。遇到这种情况先把自定义Loader的getFileExtensions改成仅返回properties从扩展名上切断默认Loader的匹配路径也是个有效手段。这个组合拳在实际项目中非常稳。5.4 实测对比自定义Loader接入前后的区别我在一个老项目上做过完整验证。改造前application.properties里有这么一行配置app.notice系统将于今晚22:00进行维护请提前保存数据Value(${app.notice})读出来的值是ç³»ç»å°äºä»æ22:00è¿è¡ç»´æ¤编译成UTF-8打印到日志依然全是乱码。接入自定义Loader之后同一行配置读出来就是完整的中文。注意这两个场景下Java源码文件本身编码没变IDE设置没变唯一的变量就是加载器的解析编码。有个附加的好处配置里不再需要写\u7cfb\u7edf这类Unicode转义序列了。以前为了规避乱码团队里要求中文配置必须转义配置文件可读性极差新同事接手根本看不懂。现在直接写中文维护成本下降了一大截这个体验上的提升真的只有经历过的人才懂。5.5 SpringBoot 2.4的多文档properties兼容处理SpringBoot 2.4引入了一个新特性properties文件支持多文档结构用#---分隔不同的文档块配合spring.config.activate.on-profile实现同一个文件内的profile区分。如果你的项目用到了这个特性上面的简单实现就不够用了因为Properties.load读不进多文档逻辑。要处理多文档场景代码会复杂不少需要参照SpringBoot源码PropertiesPropertySourceLoader的loadDocuments方法。这里我给出一版简化的核心逻辑Override public PropertySource? load(String name, Resource resource) throws IOException { ListDocument documents loadDocuments(resource); if (documents.isEmpty()) { return null; } // 只取第一个文档作为无profile的默认配置 Document first documents.get(0); return new PropertiesPropertySource(name, first.getProperties()); } private ListDocument loadDocuments(Resource resource) throws IOException { ListDocument documents new ArrayList(); try (Reader reader new InputStreamReader(resource.getInputStream(), StandardCharsets.UTF_8)) { // 按行读取利用Properties的load方法逐段解析 // 这里参照SpringBoot源码文档切割逻辑篇幅原因省略细节 } return documents; }不过说实话大多数存量项目不至于在properties文件里写多文档结构有这个需求的基本早就切到YAML了。所以我在实际生产项目中通常只用单文档版本代码短、逻辑简单、出问题也好排查实用性优先。6. 换赛道方案用application.yml彻底绕开历史包袱6.1 YAML为什么天然支持中文如果你已经被properties乱码折磨到怀疑人生又不想搞一堆自定义类那么把配置迁移到application.yml是一个性价比很高的选择。YAML规范基于Unicode字符集设计SpringBoot的YamlPropertySourceLoader在实现时直接使用UTF-8解码不需要做任何额外配置中文就能正确读取。同样的配置内容properties和yml写法对比如下。properties写法app.name用户服务 app.description负责处理用户注册与登录的业务服务yml写法app: name: 用户服务 description: 负责处理用户注册与登录的业务服务从属性和层级来看yml不仅解决了编码问题还把配置结构梳理得更清晰尤其适合配置项多、层级深的场景。6.2 迁移时配置语法兼容性的注意事项从properties迁移到yml不是无脑改格式有几个关键的语法坑要避开。第一个是缩进YAML对空格缩进极其敏感同级配置项必须对齐否则直接解析报错。第二个是特殊字符处理配置值里如果包含冒号和井号需要加引号或转义比如url: http://example.com这种情况:后必须带空格否则解析会出错。我整理了一个迁移对照表配置场景properties写法yml写法数组items[0]aitems:换行- aMapmap.keyvaluemap:换行key: value多行文本textline1\nline2text: |换行line1换行line2数值带单位timeout5000mstimeout: 5000ms无引号布尔值flagtrueflag: true另外还有一个隐藏坑application.properties和application.yml同时存在时SpringBoot默认的优先级是properties优先于yml。但有时候你删了propertiesyml里的配置却没生效排查了半天发现是因为Maven打包时没有把yml文件作为resource资源打包进去。解决办法是在pom.xml里确认src/main/resources目录包含**/*.yml可以在build/resources里显式声明。6.3 存量项目渐进式迁移的策略如果项目太大一次性迁移完所有配置风险太高这里提供一个渐进式方案。第一种是双文件并存策略保留application.properties放系统级配置数据源、端口、日志级别把业务配置迁移到application-biz.yml然后在主类上增加PropertySource(value classpath:application-biz.yml)。注意YAML文件不能用PropertySource加载这里要用PropertySources配合YamlPropertiesFactoryBean做转换或者直接用ConfigurationProperties绑定。第二种是我更推荐的策略SpringBoot支持spring.config.import指令从2.4之后可以用它把外部配置文件引入主配置。你可以在application.properties里保持现有配置不动然后在application.yml里写spring.config.import: classpath:biz-config.yml逐步把中文相关的配置项迁移过去。每迁移一批就验证一次稳扎稳打。7. 常见问题与排查技巧实录7.1 排查工具与手段快速定位乱码环节遇到配置乱码第一步要确认乱码发生在哪个环节。我会按这个顺序排查先看文件本身的编码再看Java读取后的字节内容最后确认输出环节的字符集。查看文件编码的Linux命令file -i application.properties命令输出会显示charsetutf-8或charsetiso-8859-1。如果是后者说明文件本身就没保存成UTF-8这是源头问题。如果文件已经是UTF-8但程序读出来还是乱码那就是读取环节的问题。Java代码侧验证最简单的办法是写个小测试try (Reader reader new InputStreamReader( new FileInputStream(application.properties), StandardCharsets.UTF_8)) { Properties props new Properties(); props.load(reader); System.out.println(props.getProperty(app.notice)); }如果这段代码读出来中文正常而SpringBoot应用读出来乱码那基本可以锁定是PropertySourceLoader的问题直接用第五节的自定义Loader方案。还有一个容易被忽略的环节日志输出。如果配置读取正确但日志控制台显示乱码那可能是日志框架的编码问题跟配置文件无关。排查方法是把读到的值写入一个文件再查看文件内容如果文件是正确的而控制台乱码请检查Logback或Log4j2的pattern编码设置。7.2 高频踩坑点集合我在博客评论区见过很多相似问题这里把高频踩坑点一次性整理出来。第一个坑只改了IDE的全局编码没改properties专属编码。IDEA里File Encodings面板右侧专门有一个Default encoding for properties files下拉框很多人忽略了它导致properties文件一直以ISO-8859-1保存。第二个坑IDEA开启了Transparent native-to-ascii conversion编辑时看着是中文保存到磁盘却变成\uXXXX。这种情况下Java读取本身没问题但运维直接看配置文件时发现全是转义符不符合预期。取消勾选后重新保存一次即可。第三个坑自定义PropertySourceLoader后启动报ConflictingBeanDefinitionException或者提示Loader重复注册。这通常是因为项目里依赖了多个版本的spring-boot导致spring.factories被多次合并或者别的jar包也注册了同名Loader。解决办法是用Order调整优先级同时把getFileExtensions返回值改成只含properties。第四个坑Maven打包后配置文件里的中文变成乱码但IDE里看是正常的。重点检查pom.xml的project.build.sourceEncoding有没有显式设置以及maven-resources-plugin的encoding参数。打包后用一个临时接口把配置内容输出到响应体用浏览器查看这是最直观的验证方式。第五个坑用了ConfigurationProperties绑定配置但注入的值乱码。这里要区分是绑定环节出问题还是绑定前的读取环节出问题。ConfigurationProperties本身不涉及编码转换它只是从Environment里取值所以问题还在PropertySourceLoader。先按第五节方案处理如果绑定的类里还用到了Lombok的Data生成getter/setter注意排除Getter里隐含的字符串编码转换这种情况极少。7.3 我的经验心得与推荐方案做了这么多年Java项目我对编码问题的态度是能技术解决绝不靠自觉。项目初期就统一规定配置文件编码为UTF-8并且把自定义Loader直接放进项目基础组件里一劳永逸。具体到我个人最常用的组合是IDE设置UTF-8并关闭native-to-ascii转换Maven的project.build.sourceEncoding显式设为UTF-8如果项目同时存在application.properties则加上自定义UTF-8PropertySourceLoader。这套组合在本地开发、CI构建、生产部署三套环境都验证过稳定运行好几年没再出现配置乱码问题。如果你刚接手一个老项目配置乱码问题积压已久我的建议是不要急着全量改配置先搭好上述组合让新改动的配置都能正确读取。历史乱码配置项可以在业务迭代时逐个修正——因为它们已经被读成错误字符串并写进数据库或缓存了光改配置文件还不够可能需要刷数据这个要评估影响面再动手。最后再分享一个小技巧给team里每个人统一一个.editorconfig文件规定properties和yml文件的charset utf-8很多现代IDE会自动遵循这个约定从源头上减少人为编码不一致的情况。这个文件我通常会这样写root true [*.properties] charset utf-8 end_of_line lf insert_final_newline true [*.yml] charset utf-8 end_of_line lf insert_final_newline true [*.java] charset utf-8 end_of_line lf indent_style space indent_size 4配置文件编码这个问题说小了是一个乱码说大了是团队协作规范和技术债务的积累点。花一个小时把环境和代码层方案配齐后面能省下无数个补丁式的排查时间这笔账怎么算都是值得的。