Jason Song

1. releaseKey 能够唯一确定一个版本，notificationId 相同不一定 releaseKey 相同 2. 可以在本地 install apollo-client/apollo-core 后测试 apollo-configservice，`mvn clean install` 3. 待测试通过后提交 PR 到远端仓库，有 github action 可以[打包](https://github.com/apolloconfig/apollo-java/actions/workflows/release.yml)

> 针对此问题，看看是否可以增加版本控制检查来判断，如果是旧版本，就提示用户刷新页面？ 这个方式是可行的，不过上述例子中 A 用户提交配置后是能看到修改了预期之外的配置，在发布的时候也会有提示的，稍加注意应该是能避免该问题的。

1. 生产环境：portal, config service & admin service 2. 测试环境：config service & admin service（通过 adminServiceUrlOverride 暴露为公网地址） 3. portal 通过公网地址访问测试环境的 admin service > 但是由于lb svc 是local模式， 会存在同一个集群不能通过公网地址访问本集群的问题，导致测试服务不能连通apollo 这个是指啥？你是把测试环境的 config service 也通过 configServiceUrlOverride...

> 所以我在部署dev config的时候把configServiceUrlOverride和adminServiceUrlOverride都写成暴露的ingress地址了 1. configServiceUrlOverride 配置修改的是 client 通过 meta service 发现 config service 返回的地址，在你这个情况下不应该修改。 2. portal 访问 meta service 是在 portal 这里配置的，和 configServiceUrlOverride 无关。

这确实是一个可以改进的点，在 JSON 的标准（RFC 8259）中规定，每个键在一个对象中应该是唯一的，不过具体实现的行为确实会不太一样。 ``` When the names within an object are not unique, the behavior of software that receives such an object is unpredictable. Many implementations report the last...

是否有优势或者是否支持需要先从需求场景做下定义和相关评测，建议可以从你实际的应用场景提炼出一些核心指标，而后看下相关指标的情况

Were these changes made by an AI bot?

There's no rule against using an AI bot, but it does mean we need to review the PR a bit more carefully.

可以看下[4.4 配置获取规则](https://www.apolloconfig.com/#/zh/design/apollo-introduction?id=_44-%e9%85%8d%e7%bd%ae%e8%8e%b7%e5%8f%96%e8%a7%84%e5%88%99)

[spring-cloud-gateway](https://github.com/apolloconfig/apollo-use-cases/tree/master/spring-cloud-gateway) 的效果应该就是吧？