我之前做Firebase A/B测试的时候也纠结过这个问题，特意去挖了官方文档还做了小测试验证，现在把这个逻辑给你理清楚：

• 用户分组是一次性静态绑定的：当用户首次满足测试的定向条件（比如你例子里的美国地区）时，Firebase会基于用户的Firebase App Instance ID（或已认证的用户ID）将其分配到测试组或对照组，这个分组关系会被持久化存储——要么存在用户设备本地，要么关联到Firebase的用户记录里。
• 后续属性变化不会触发重新分配：哪怕用户之后的定向属性发生了改变（比如移居到法国，地区变成法国），Firebase也不会把用户从当前所在的组里移除，更不会重新分配组别。这个用户会一直留在初始分配的组中，直到测试结束或者你手动干预。
• 和Remote Config动态条件的区别：这里要注意和Firebase Remote Config的动态配置区分开——Remote Config的条件是实时判断的，但A/B测试的核心是分组对比，所以一旦完成初始分配，分组就固定了，不会随用户属性变化而动态调整。

举个实际的例子：你创建了一个定向美国用户的A/B测试，某个美国用户打开App时触发了测试分配，进入了测试组。后来他搬到法国，App里的地区属性更新为法国，但他依然会继续接收测试组的变量配置，不会被自动踢出测试或者转到其他组。

如果你的业务需求是让用户属性变化后退出当前测试，那需要你自己在代码里实现逻辑：比如监听用户属性的变化事件，当检测到定向条件不再满足时，调用Firebase A/B Testing的相关API手动将用户从测试中移除。

内容的提问来源于stack exchange，提问作者Allen