All checks were successful
构建并部署到测试环境(无 SSH) / build-and-deploy (push) Successful in 4m39s
2.5 KiB
2.5 KiB
Context
/api/admin/shops/fund-summary 通过 GetPrimaryAccountsByShopIDs 查询 is_primary = true 的账号来获取店铺主账号信息(用户名、手机号)。
问题根因:shop/service.go 创建店铺初始账号时从未设置 IsPrimary: true,导致所有账号的 is_primary 均为默认值 false。数据库验证确认:系统中唯一一个店铺账号(id=128)的 is_primary = false。
Goals / Non-Goals
Goals:
- 修复店铺创建逻辑,初始账号设
IsPrimary: true - 数据迁移修复存量数据(每个店铺选最早创建的代理账号设为主账号)
- fund-summary 接口返回正确的用户名和手机号
Non-Goals:
- 不修改
GetPrimaryAccountsByShopIDs查询逻辑(查询本身是正确的) - 不实现"切换主账号"功能(超出范围)
- 不修改 fund-summary 的其他字段
Decisions
决策1:修代码,不改查询
选择:在 shop/service.go 创建账号时加 IsPrimary: true,而非修改 GetPrimaryAccountsByShopIDs 为"查最早账号"。
理由:is_primary 字段本身语义明确("是否为主账号"),查询逻辑是正确的。改查询是绕过问题而非解决问题,且未来如果引入"多账号切换主账号"功能会与改查询的方式冲突。
决策2:历史数据修复策略
选择:迁移 SQL 对每个 shop 取 created_at 最早的代理账号(user_type = 3)设为 is_primary = true。
理由:最早创建的账号最可能是初始主账号。这个规则简单确定,无歧义。
SQL:
UPDATE tb_account a
SET is_primary = true
FROM (
SELECT DISTINCT ON (shop_id) id
FROM tb_account
WHERE shop_id IS NOT NULL
AND user_type = 3
AND deleted_at IS NULL
ORDER BY shop_id, created_at ASC
) earliest
WHERE a.id = earliest.id
AND a.is_primary = false;
Risks / Trade-offs
[风险] 一个店铺有多个账号时选错主账号 → 当前系统只有 1 个店铺且 1 个账号,风险极低。取最早账号的策略合理。 → 如有异议,超级管理员可手动修正(未来可开放"设置主账号"接口)。
[风险] 迁移 SQL 误更新已手动设置的 is_primary = true 记录
→ SQL 加了 AND a.is_primary = false 条件,不会覆盖已正确的数据。
Migration Plan
- 执行代码变更(shop/service.go 加
IsPrimary: true) - 执行数据库迁移文件(UPDATE SQL)
- 验证:调用 fund-summary 接口,确认返回正确用户名和手机号