看起来你遇到的是Edge浏览器使用chrome.identity.launchWebAuthFlow时典型的重定向URI不匹配问题，我来逐一解答你的疑问，并给出实际的排查和解决方向：

Q1. Google Cloud Console是否需要特定配置支持Edge等Chromium浏览器？ #

是的，必须进行针对性配置，这里有几个容易踩坑的核心点：

• Chrome扩展的重定向URI格式是https://<你的扩展ID>.chromiumapp.org/，但Edge有专属的重定向域名：https://<你的扩展ID>.microsoftedgeextension.net/。哪怕你的扩展ID和Chrome完全一致，这两个URI也是独立的，必须都添加到Google Cloud Console对应OAuth 2.0客户端ID的「已授权重定向URI」列表里。
• 一定要保证URI的精确匹配：包括扩展ID的正确性、域名拼写（别把microsoftedgeextension.net写成chromiumapp.org）、甚至结尾的斜杠都不能出错。
• 另外，确认你在Cloud Console中创建的是「Chrome应用」类型的OAuth客户端ID——这是适配浏览器扩展的专属类型，能确保重定向URI格式被正确识别。

Q2. Edge是否对chrome.identity.launchWebAuthFlow的处理有差异？ #

确实有差异，这也是导致重定向不匹配的核心原因：

• 虽然Edge基于Chromium内核，但它会为扩展生成专属的重定向域名（microsoftedgeextension.net），而非沿用Chrome的chromiumapp.org。当你在Edge中调用chrome.identity.launchWebAuthFlow时，API会自动使用Edge的专属域名构建重定向URI，如果Cloud Console里只配置了Chrome的URI，Google就会判定为不匹配，返回redirect_uri_mismatch错误。
• 此外，Edge对扩展权限的校验更严格：务必确保你的扩展manifest.json中已经正确声明了"identity"权限；如果有oauth2配置区块，里面的client_id必须和Cloud Console中的完全一致，scopes也要覆盖你需要的所有权限。

已知限制与可行的Workaround #

除了上述配置问题，还有一些容易被忽略的排查点：

1. 确认Edge扩展ID的正确性：侧加载扩展或打包方式不同时，Edge的扩展ID可能和Chrome不一致。你可以在Edge的「扩展管理页面」（edge://extensions/）开启「开发者模式」，查看当前扩展的真实ID，再用这个ID构建Edge的重定向URI添加到Cloud Console。
2. 避免显式指定重定向URI：如果你在调用launchWebAuthFlow时手动指定了redirectUri为Chrome的URI，Edge会直接拒绝请求。建议不要显式指定，让API根据当前浏览器自动生成对应的重定向URI。
3. 等待配置生效：Google Cloud Console的OAuth配置有时候需要5-10分钟才能全局生效，刚修改完就测试可能会遇到配置未同步的问题，可以稍等片刻再重试。
4. 直接复制错误页的预期URI：当出现redirect_uri_mismatch错误时，Google的错误页面会明确列出「预期的重定向URI」，把这个URI完整复制下来添加到Cloud Console，这是最准确的方式，能避免手动输入的细微错误。

结合你提到的已经添加Edge URI但问题仍存在的情况，优先建议你去错误页面复制Google提示的预期重定向URI，和Cloud Console中已添加的URI做精确对比——很多时候都是手动输入时的拼写错误（比如少了斜杠、ID输错）导致的问题。

备注：内容来源于stack exchange，提问作者ArindamMaiti