Google Firebase Auth模拟器频繁登出用户且未与生产环境隔离的问题

我之前也踩过类似的坑，明明配置了模拟器，但操作却跑到真实控制台，还出现登录后立刻登出的诡异情况，结合你的报错信息，给你总结几个实用的解决技巧：

1. 把模拟器配置放在最最前面 #

这是最容易踩的坑！一定要在任何Auth相关操作（初始化监听、登录调用、状态监听）之前调用useEmulator。很多人会把模拟器配置放在组件挂载后、异步初始化里，这时候可能已经有请求偷偷发到真实服务了。

正确的顺序示例：

// 先初始化Firebase App
const app = initializeApp(firebaseConfig);
// 立刻绑定Auth模拟器
const auth = getAuth(app);
auth.useEmulator('http://localhost:9099');

// 之后再做任何Auth操作
onAuthStateChanged(auth, (user) => {
  // 处理用户状态逻辑
});

2. 修复错误的请求路径 #

你看到的400错误请求路径http://localhost:9099/www.googleapis.com/...明显有问题——正常模拟器的请求应该直接是http://localhost:9099/identitytoolkit/...，不该带www.googleapis.com前缀。这说明你的Auth实例还是在走真实服务的路径规则，只是把域名换成了模拟器，导致路径不匹配。

解决办法：

• 检查项目里有没有其他代码修改过Auth的配置，比如第三方库、旧代码里的auth.settings调整
• 重启开发服务器和Firebase模拟器，缓存有时候会让配置不生效

3. 清空本地Auth缓存 #

真实环境的Auth会话缓存会干扰模拟器，你可以：

• 打开Chrome开发者工具，到Application > Storage > Firebase Auth里删除所有缓存数据，然后刷新页面
• 或者在代码里主动清缓存：

await auth.signOut();
// 部分SDK版本支持直接清会话，或者直接手动清除浏览器localStorage里的Firebase相关键值

4. 验证模拟器是否真的生效 #

加个日志确认配置状态：

console.log('Auth模拟器配置状态:', auth._emulatorConfig);

如果输出里能看到host: 'localhost:9099'，说明配置成功；如果是undefined，那就是配置没执行到，回去检查代码执行顺序。

另外，模拟器控制台显示的Received a signed JWT只是说明有请求过来，但不代表请求路径正确——路径不对的话，模拟器无法处理，最终还是会 fallback 到真实服务（或者直接报错）。

5. 确保CLI和SDK版本匹配 #

新旧版本的Firebase CLI模拟器和JS SDK偶尔会出现兼容问题，试试：

• 更新Firebase CLI到最新版：npm install -g firebase-tools
• 更新项目里的Firebase SDK：npm install firebase@latest

6. 排查代理或CORS干扰 #

如果你的开发服务器有代理配置（比如Vue的vue.config.js、React的setupProxy.js），检查有没有对/www.googleapis.com的代理规则，要是有的话，得排除掉模拟器的域名。

另外，默认模拟器允许所有本地域名的CORS请求，但如果有自定义配置的话，也要确认没限制你的开发域名。

按照这些步骤排查，基本能解决你的问题——核心就是要保证模拟器配置在所有Auth操作之前，并且请求路径完全指向模拟器，而不是带着真实服务的路径前缀。

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