嗨，@SSJSIAT！很高兴再次看到你在这里提出问题。希望你今天过得不错！

根据我在Apollo仓库中的查找，Apollo在处理非properties格式配置文件（如yml）的继承时，确实是在整个文件内容粒度进行的。这是通过关联类型（继承类型）的Namespace实现的。关联类型的Namespace从公共类型的Namespace继承，并用于覆盖公共Namespace的某些配置。这种机制允许在粒度级别继承和覆盖配置，包括非properties格式文件，如XML，YAML，JSON等。

例如，如果公共Namespace有配置：

k1 = v1
k2 = v2

应用程序有一个关联类型的Namespace，它用新值 v3 覆盖配置项 k1 ，那么该应用程序的有效配置将是：

k1 = v3
k2 = v2

这展示了Apollo如何支持在文件内容粒度级别继承和覆盖配置，包括非properties格式。你可以在 Apollo核心概念 - Namespace 中找到更多信息。

关于Apollo 2.1.0版本和最新版本2.2.0在处理非properties格式配置文件的继承方面的差异，我没有在仓库中找到明确的答案。但是，从2.1.0版本到最新的2.2.0版本，对非properties格式配置文件的处理做出了一些改变，例如 为非properties namespaces支持灰度特性 。

对于你提到的问题，如果非properties格式的公共配置文件，继承依然是在整个文件内容粒度进行，我同意应该明确告知用户，并将相关case也表示出来。这将有助于用户更好地理解和使用Apollo。

Sources

• yml格式配置关联公共配置后，配置任意内容将会覆盖公共的所有配置
• 继承yml格式的 后覆盖属性, 再删除覆盖属性,会报错!
• docs/en/design/apollo-core-concept-namespace.md
• changes/changes-2.2.0.md

About Dosu

This response is meant to be useful and save you time. It is not meant to be a precise solution, but rather a starting point for your own research.

Help me be more useful! Please leave a 👍 if this is helpful and 👎 if it is irrelevant.

If you want to continue the conversation, start your reply with @dosu-bot.

@nobodyiam

如果非 properties 格式的公共配置文件，继承依然是在整个文件内容粒度进行，请明确告知用户，并将相关case也表示出来

目前确实是这样的逻辑，对于用户的提示是否有啥建议？

当前提示不友好的点有2个：
1.官方说明文档（namespace部分）：没有明确写明非 properties 格式的公共配置文件，继承依然是在整个文件内容粒度进行
2.产品界面上（namespace Tips部分）：在关联的NameSpace里配置需要覆盖的配置即可，这其实只在properties 格式的公共配置文件可以这样操作
优化建议：
1.官方说明文档（namespace部分）：可以说明一下，（XX版本前），非properties 格式继承依然是在整个文件内容粒度进行，对于properties 格式，通过XX方式进行继承，对于非properties 格式，通过XX方式进行继承
2.产品界面上（namespace Tips部分）：可以参照上述表达，把不同的地方指出来
当前就我个人体会，是发现了问题后再回头找官方文档，最后只有从issue中才找到相关说明
或者说有这么一种使用场景：运维A习惯使用properties，他一直都这么使用，并形成了惯性思维，突然有一天有个应用要使用非 properties，这时候就可能没有注意到这点，问题就会发生

很好的建议，如果有兴趣的话，欢迎直接提交 PR~

请问什么时候能支持非properties的继承合并功能， 目前如果公共配置是json格式，内容为 { “k1": "a”, "k2":"b"} , 如果在覆盖配置中定义了{"k1":"c“}， 那么其实整个公共配置就都丢失了，只得到了{"k1":"c“}的结果（k2丢失了）， 这种情况下一旦使用了覆盖配置， 继承就失去意义了。