如何连接Firebase与SQL数据库 实现Firebase Auth用户与MySQL关联

核心关联键直接用 Firebase Auth 为每个用户生成的全局唯一 uid 即可，这个字段是用户身份的永久标识，不会随用户修改绑定邮箱、切换/绑定第三方登录渠道变更，比邮箱、第三方平台返回的openid稳定性高几个量级，完全可以支撑你替代自建用户表的需求，不需要在MySQL侧维护密码、登录凭证这类Auth托管数据。

落地步骤 #

• MySQL侧建极简用户映射表，不要做完整账号体系
  这张表只存业务需要的用户基础属性和关联id，不存任何登录校验相关的敏感数据，参考建表语句：

  CREATE TABLE `user_profiles` (
    `firebase_uid` VARCHAR(128) NOT NULL PRIMARY KEY COMMENT 'Firebase生成的用户唯一id，作为全库用户关联主键',
    `email` VARCHAR(255) DEFAULT NULL COMMENT '用户绑定邮箱，可同步更新',
    `nickname` VARCHAR(100) DEFAULT NULL COMMENT '用户昵称',
    `avatar` VARCHAR(512) DEFAULT NULL COMMENT '用户头像地址',
    `created_at` DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP,
    `last_login_at` DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP
  ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;
  

  所有业务表（订单、购物车、收货地址、商品收藏等）全部添加firebase_uid字段作为外键关联这张表的主键，以订单表为例：

  ALTER TABLE `orders` 
    ADD COLUMN `firebase_uid` VARCHAR(128) NOT NULL,
    ADD INDEX `idx_orders_uid` (`firebase_uid`),
    ADD FOREIGN KEY (`firebase_uid`) REFERENCES `user_profiles`(`firebase_uid`) ON DELETE CASCADE;
  

  开了外键级联删除之后，后续注销用户只要删掉user_profiles里的对应记录，关联的业务脏数据会自动清理，不用写多表删除逻辑。
• 做自动用户同步逻辑，不用手动触发用户建档
  两种实现选一种就行：
  • 前端拿到Firebase登录返回的idToken后，将token放到请求头传给业务后端，后端先校验token合法性，解析出其中的uid、邮箱、昵称、头像字段，查询user_profiles中是否存在对应uid的记录，不存在就自动插入新记录，存在就更新最近登录时间、有变动的基础属性即可
  • 不想在每次登录请求里做查库判断，可以直接配置Firebase Auth的创建用户触发器，用户首次完成注册时自动触发逻辑，调用业务后端接口写入用户初始数据，注意给这个接口加单独的鉴权校验，避免被恶意刷写入
• 统一所有业务接口的鉴权逻辑
  所有需要登录态的接口，统一在拦截层做三件事：
  1. 校验请求携带的Firebase idToken的签名、有效期是否合法，解析得到对应用户的firebase_uid
  2. 确认该uid在user_profiles表中存在，拦截掉异常请求
  3. 后续所有业务的查询、写入操作，默认带上这个uid作为数据过滤条件，比如查询用户购物车直接执行SELECT * FROM shopping_cart WHERE firebase_uid = ?，完全不需要自己维护session、密码校验逻辑。

避坑提醒 #

• 绝对不要用邮箱、第三方平台的openid作为关联键：邮箱支持用户修改，同一个用户如果先后用邮箱、Google、Facebook登录，未做账号合并时会生成多个身份标识，但只要在Firebase侧做了账号合并，最终只会对应一个固定的uid，不会出现数据错绑
• 不要在MySQL侧存储Firebase的敏感凭证，比如refreshToken、密码哈希这类数据，全部交给Firebase托管即可，自行存储反而会增加数据泄露风险
• 多渠道登录的账号合并逻辑直接在Firebase侧完成即可，不需要在业务库做额外处理，合并后用户uid不变，业务侧完全无感知

不要陷入“用了第三方Auth就不能在业务库存用户数据”的误区：Firebase只负责身份校验环节，你在MySQL存的只是业务关联用的用户id和基础展示属性，不属于重复造轮子，是跨服务身份映射的标准做法。

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