如何通过代码生成带自定义基础URL的Firebase邮箱验证链接

动态修改动作URL的支持边界 #

Firebase Admin SDK 不支持在调用generateEmailVerificationLink接口时，动态覆盖控制台配置的默认动作URL基础路径。
你遇到的基础路径始终为localhost:3100/welcome的问题，是接口本身的逻辑导致：当你设置setHandleCodeInApp(true)时，SDK会强制读取Firebase控制台「Authentication-邮件模板-操作链接」中配置的默认URL作为链接基础路径，你在ActionCodeSettings中通过setUrl()传入的地址，只会被作为continueUrl参数拼接到链接末尾，不会替换基础路径，这也是你之前配置不生效的根本原因。

规范实现方案 #

目前有两种无兼容风险的正规实现方式：

• 统一跳转入口方案
  首先把Firebase控制台的默认动作URL修改为你自有域名下的统一验证入口（比如auth.myapp.com/welcome），不要保留localhost测试配置。生成链接时不需要修改基础路径，只需要在ActionCodeSettings.setUrl()中传入对应端的目标地址：乘客端传https://passenger.myapp.com，司机端传https://driver.myapp.com。用户点击验证链接后会先跳转到统一入口，你的服务端完成oobCode有效性校验后，再根据链接中的continueUrl参数做302跳转，唤起对应端的Android/iOS应用即可。该方案完全匹配Firebase的接口设计逻辑，后续升级SDK也不会出现兼容问题。
• 多Firebase项目隔离方案
  为乘客端、司机端分别创建独立的Firebase项目，每个项目的控制台单独配置对应端的动作URL，服务端同时初始化两个Firebase Admin实例，生成对应端的验证链接时调用对应实例的接口即可。该方案不需要做中间跳转，但需要你自行打通两个项目间的用户体系，适配成本更高。

字符串替换方案的潜在风险 #

你当前使用的硬编码字符串替换方案不属于官方支持的用法，存在三类明确风险：

• 配置变更失效风险：如果后续有人修改Firebase控制台的默认动作URL（比如切换测试/生产环境域名、调整路径），replace逻辑会直接失效，生成错误链接，且这类问题很容易被常规测试遗漏。
• 链接结构兼容风险：Firebase如果后续调整验证链接的生成规则（比如增加区域路径前缀、调整本地测试地址的协议/端口、修改参数顺序），硬编码替换可能破坏链接结构，导致用户点击后提示oobCode无效。
• 多环境适配风险：如果你的测试、预发、生产环境使用不同的Firebase配置，硬编码的替换规则需要在每个环境单独维护，很容易出现环境配置错配的问题。

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