为什么 DefaultConfigFactory 很多方法都用默认可见性修饰？

[yfwz100]

用 protected 修饰可以让使用者对实际逻辑进行定制，但默认可见性不行。我看很多方法本身是比较解耦的，可复用性很强，但是因为可见性原因无法被复用。

[nobodyiam]

结论：目前 DefaultConfigFactory 里多数默认可见性方法不是遗漏，而是没有被作为稳定的子类扩展 API 暴露出来。

现在对外比较明确的扩展契约是 ConfigFactory 接口本身：实现 create(...) 和 createConfigFile(...)，再通过 Apollo 的 injector/customizer 机制替换或提供自定义 ConfigFactory。DefaultConfigFactory 这层主要是默认实现，里面的 repository 选择逻辑会同时受 namespace 后缀、properties-compatible format、本地文件缓存、K8s ConfigMap 缓存、remote repository 等内部策略影响，例如 create(...) 会在 createConfigRepository(...) 和 createPropertiesCompatibleFileConfigRepository(...) 之间选择。

目前已经开放的继承 hook 是 protected createRepositoryConfig(...)，apollo-client-config-data 里的 PureApolloConfigFactory 就是这样复用默认 repository 组装逻辑，只替换最终创建出来的 Config 类型。也就是说，当前支持的是“复用默认 repository 流程，但替换最终 Config 实现”这一类扩展。

如果目标是定制 repository 创建、namespace format 判断或某个具体构造步骤，当前确实没有稳定的细粒度 protected hook。这个方向可以讨论，但建议按具体场景最小化开放，而不是把所有包可见方法都改成 protected，因为一旦改成 protected，就等于把这些内部步骤变成对外兼容承诺，后续调整默认实现会更受限制。

如果你有明确的复用点，欢迎补充一下具体想覆盖哪个方法、要解决什么场景。可接受的 PR 方向会更倾向于：只开放必要的 protected 方法，补充对应测试，并说明这个 hook 的兼容边界。

[yfwz100]

感谢回复。