我开始使用 Spring Cloud Config，并希望为客户端提供一种方法来覆盖来自 cofnig 服务器的属性。但是，在阅读https://docs.spring.io/spring-boot/docs/current/reference/html/boot-features-external-config.html后，云配置何时适用并不明显。
我还阅读了http://cloud.spring.io/spring-cloud-config/spring-cloud-config.html并谈到了覆盖。但它们似乎与我想要的相反（这些覆盖是为了覆盖客户端提供的属性）。
那么，Cloud Config 在排序中的位置是什么？我仍然可以application.properties在类路径上提供一个本地文件来覆盖某些 Cloud Config 属性吗？
git commit/push 过程是该过程的一部分，实际上......Spring Cloud Config 使用 git 来处理配置文件、更改、审计等，因为 git 非常适合这些，而 Config 充分利用了这些优势。
如果您只是在寻找一种方法来加快配置更改的测试并愿意接受权衡，您可以使用本地（或本地网络）存储库作为您的配置存储库进行测试。我意识到这不是你具体要求的，但它是一个可能有帮助的选项，假设你使用配置服务器应用程序的 application.properties 指向底层 git repo。如果是这样，您可以在命令行上覆盖 spring.cloud.config.server.git.uri ，如下所示：
java -Dspring.cloud.config.server.git.uri=${HOME}/testing/config-repo -jar your_jar_here.jar
这将允许您调整从配置服务器获取其设置的客户端应用程序/服务的配置设置，而不会影响生产配置文件（甚至是分支）。
我希望这有帮助。如果没有，或者我误解了您的目标或限制，请澄清（如果您可以分享一两个用例，可能会帮助我更好地进行三角测量），我会再试一次。:)
干杯，马克