最近发布的项目通常会出现问题，通常报告如下：
从记录错误中有一个直观的判断，也就是说，这些被扔掉的密钥不受支持（已过期或删除）。项目的基本信息是：
此外，此错误不会导致项目直接阻止，并且并非每次出现时都有一定的随机性。对于此错误，有两个问题：
以下是分析和研究的过程。
首先，很明显，任何错误报告都会有堆叠或日志的位置。您可以发现它是由该组件或框架生产的。对于一些简单的异常，您可以通过阅读源代码直接找到问题的原因。您可以直接找到问题的原因。对于复杂的异常，可以通过简化项目结构来恢复场景，以及通过调试发现问题的原因。
对于上面的错误日志，现在执行过滤器：
另外，如上所述，找到由异常生成的源代码
通过分析执行堆栈是在此处执行的。在Springboot中，它不是通过ApplicationFailsevent事件发布的，而是通过ApplicationReadyEvent事件发布的，因此在这里说明为什么错误不会阻止程序操作。
这是一个很小的结论：报告错误的键在相关的configproperties中标记为@deprected或@deprecatedConfigurationProperty。
这里得出的一个新问题，被@DepRecated / @deprecatedConfigurationProperty击败。这些配置属性与报告之间的关系之间的逻辑是什么？
以上代码的核心是列举当前类路径下的所有属性项目，然后比较当前项目中的配置。一般策略如下：
假设项目可以提供的所有配置项目的配置项目是：启动已过期，因此第一批使用者包含在三个项目中。
目前，项目中配置了两个项目，因此结果有两个项目，这两个项目将反映在错误日志中。
对于Springboot项目的属性文件，使用时将有一种自动完成的机制，这主要取决于Spring-Boot-Configuration Processor的作用。如果将其引入您的项目中，它将为JSON文件生成：
我认为示例spring.mvc.favicon.enabled作为一个示例：
原始代码如下：
实际上，您可能会从一开始就猜测依赖版本。这里主要取决于Maven的汇编和建设性机制。当Maven构建Fatjar时，依赖有效性的JAR版本的引入是一个复杂的问题。这里没有直接关注Maven。
PS：依靠管理是任何公司，任何项目和任何项目的头痛。
在澄清了问题的具体原因之后，很容易解决该问题。这里有两个考虑因素。第一个错误不会影响项目的启动。是否有必要注意它？如果不确定，请不要移动。第二，当您知道此配置项目并确定它不在项目中或知道其替代方案时，请杀死或更换直接。
在我的项目中，我选择直接删除它，这是历史记录剩余的问题
关于依赖性问题，请不要随意指定任何依赖版本。该项目已经具有>>依赖关系管理器管理和控制版本>>依赖项指定版本。