现在我们在做系统的时候，往往会申请2-3个号，分别用于dev、qa、prd环境，因为对应的后台环境肯定不一样，你不能要求测试在PRD上完成。 所以现在一个痛点是我们在DEV上开发，可能配的后台环境是http://localhost:xxxx/，到QA上就会变成https://qa.xxx.com/，到PRD是https://www.xxx.com。这样我们从DEV发布（promote）到QA的时候要用QA的配置文件覆盖后发布到QA环境上，再promote到PRD的时候得再改配置文件。 理论上说QA到PRD不应该再有任何代码的修改，但这里却做不到。 建议增加系统级别的配置文件，可以将这些关键的key直接配置在平台上，由平台进行各个环境的环境变量的配置管理，这样这些关键信息就可以不用专门管理，甚至代码级别的修改后才能再发布的痛点。

现在的union获取机制会要求小程序一开始就要先进行用户授权，没有一开始就授权会有如下场景:  1. 有一个小程序，一个公众号产品，我先使用小程序，再没有进行用户授权；然后我去使用公众号产品，获取到了union，这样我就有两个账号，然后我就需要非常复杂的用户合并机制. 2. 我有两个小程序，如果都没有一开始就授权，一个微信号在两个小程序里会产生两个用户，然后又开始复杂的用户合并机制. 3. 请问unionId 还有什么用?  能解释一下为什么要这么改嘛？  在没有合理解释之前，我可以抨击这个行为很脑残嘛？

- 需求的场景描述（希望解决的问题） - 希望提供的能力 微信小程序关闭之前自动弹出授权获取用户信息的接口，目的是阻碍了部分客户使用小程序，提升用户体验。然而，目前必须满足两点才能获取客户unionid： 在微信开放平台下存在同主体的App、公众号、小程序。 用户关注了某个相同主体公众号，或曾经在某个相同主体App、公众号上进行过微信登录授权。 请问： 1、为什么必须要第二点？这不是要求用户使用过公众号么，那么小程序根本没有独立性，我们推广小程序，要求客户先关注公众号？搞笑。 2、既然需要这两点才能静默获取unionid，那么作为开发者，有必要用静默授权吗？因为它始终不完善，不能百分之百获取，开发者还是要写其它替代方案保证100% 获取unioid，不然如何判断用户？静默授权有何用，微信要的用户体验何在。 3、不明白为什么需要第二点，既然能获取openid，为何不能直接获取unionid，都是同一个主体的小程序和开放平台账号啊，这个unionid是私有的吧。 4、公众号限制获取unionid可以理解，因为推广我们可以要求用户关注公众号，可是小程序，我们要求客户先关注公众号，岂不是多此一举？小程序就没有解决方案独立吗？之所以需要unionid而不是openid是因为需要将公众号老客户直接和小程序绑定。