本文记录了一次文件编码差异引起的profile替换占位符失败的bug，及处理思路。记录成文，以便以后反思，或让后来遇到问题的同学能有据可循。

起因及bug描述

相信大家对于Maven中打包不同环境使用不同profile文件的做法已经很熟悉了。我所在的项目分了好多个profile，每个profile对应不同的properties，如下图：

在开发的过程中，出现其中某几个properties编译打包出来的工程，占位符没有被替换，但是其他的properties则没有问题。war包中的配置文件中还是会有${xxx.xxx.xxx}的字符。

处理思路

• 首先排除了编码失误，字符写错等等初级错误
• 然后我怀疑是maven-resources-plugin插件在filter的过程中出现字符的问题，这个想法是由于在Maven的resource打包过程中，触发resources的filter操作的插件就是maven-resources-plugin，所以出问题一定是在这个插件的工作过程中，查看Maven的package过程日志，如下图：

日志提示使用UTF-8的编码格式，拷贝了16个经过filter操作的resource文件。然后排除了properties文件中的中文干扰，但是依然没有解决问题，Maven打包后依然是那几个properties没有有效的替换占位符。

• 暂时没有其他解决思路，只能逐字逐字的对比能成功替换占位符的properties和不能成功替换占位符的properties。还用上了各种对比工具。结局依然是没有发现什么异常的地方。

• 确定字符没问题后，怀疑是文件本身的问题。复制正常和异常两种properties文件，修改名字，修改properties里面的内容信息。打包测试。测试的结果是，能正常替换占位符的properties复制出来的都能够正常替换占位符，反之不能正确替换占位符的properties复制出来的都不能正常替换占位符。由此可见，这两个properties可能在存档的时候就存在差异。从IDE里复制异常的properties中的字符，到记事本里保存到本地，果然是存档时的编码有问题，而IDE没有提示这个问题。

• 最后替换了有异常编码的字符，就能成功打包替换了。

小结

在排除了大部分低级错误后，不要盲目进行没有必要的盲目测试，投石问路虽然是不错的方法，但是在排除bug时，一步一步的投石问路未免太过耗时。比方说在这次的bug解决中，在排除了大部分低级错误后，不应盲目进行测试，妄图以此找到解决问题的办法，而应该站在更高层次的角度来看待问题出现的缘由。所以在以后的编码学习过程中，应该加强自己的逻辑思维能力，提高分析解决问题的能力。