这问题我之前帮不少开发者排查过，核心原因出在动态端口分配和Google OAuth的严格校验规则上，咱们一步步拆解：

问题根源 #

• 你在API控制台注册的是localhost（不带端口），但出问题的那3台设备上，你的应用启动时自动分配了随机本地端口（比如49328、49254这类），导致实际跳转的redirect_uri变成了http://127.0.0.1:xxxx。Google OAuth对redirect_uri的校验是精确匹配——哪怕只是端口不一样，都会判定为不合法，直接抛出redirect_uri_mismatch错误。
• 那为啥另外3台正常？大概率是这几台设备上你的应用用了固定端口启动，或者开发环境配置里指定了固定端口，刚好和你注册的redirect_uri（如果是带固定端口的localhost）完全匹配。

解决步骤 #

1. 优先用固定端口（最稳定方案） #

修改你的应用配置，强制启动时使用固定端口（比如localhost:8080），然后到Google API控制台的OAuth 2.0客户端ID设置里，把完整的http://localhost:8080（如果是HTTPS就用https://localhost:8080）添加到已授权的重定向URI列表里。

小提醒：如果你的应用是桌面/移动端本地应用，也可以直接注册http://localhost（不带端口），不过固定端口能避免很多意外问题。

2. 动态端口场景的特殊处理 #

如果你的应用必须用动态端口（比如某些框架默认随机分配），那要注意客户端类型：

• 确保你在Google控制台创建的是桌面应用类型的OAuth客户端ID，而不是Web应用。桌面应用的redirect_uri默认允许http://localhost任意端口的回调，Google会自动识别这类本地请求的合法性。
• 如果之前注册的是Web应用类型，建议重新创建一个桌面应用客户端ID，替换到你的应用里再测试。

3. 检查设备的环境配置差异 #

出问题的设备可能开启了自动端口分配的设置，比如启动命令或配置文件里把port参数设为了0（0表示随机分配端口）。找到这个配置，改成固定数值就能解决。

快速验证小技巧 #

测试前可以在出问题的设备上，先打印出应用实际生成的redirect_uri，确认是不是带了随机端口，再对比Google控制台的授权列表，就能快速定位问题。

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