左辰勇
de1fd58749
要守住的不变量:弹窗数字 == 本轮实际到账之和 == 用户看到的余额涨幅。三者对不上, 用户就会认为少发了钱(走查现象:弹窗 240、余额只涨 40)。 - reward-result:按 ad_session_id 查本次实发金币,替代余额差 / coin_per_ad 估算。 S2S 异步未到账返 200+pending 而非 404(404 只表示路由不存在,混在一起客户端没法 区分「后端没部署」和「再等等」);同 session 多条时显式优先 granted——客户端先报 closed_early、S2S 后到时,granted 反而是后写的。 - boost_round_id:客户端经 mediaExtra 透传「这条广告属于哪一轮膨胀」,穿山甲 S2S 原样 带回后随发奖记录落库。**纯标签,不参与发奖判定**。reward-result 新增 round_coin,按 (user_id, boost_round_id) 对 granted 记录求和。之所以由服务端求和而非客户端自己累加 ——客户端进程被杀/重建后本地累计会丢,发奖记录不会。 · 求和恒带 user_id:轮 id 是客户端生成的,不带就等于让任何人拿别人的轮 id 查别人发了多少。 · 本条非 granted(capped 等)时仍返本轮累计、该条按 0 计,让限额 toast 有数可显。 · test-grant 加可选 boost_round_id:它不经 S2S 拿不到 extra,不补则 debug 包验不了累计。 · 客户端复用同一轮 id 只会把展示数字滚大,求和的是已发生的记录,不产生新入账,无资损。 - 下线 signin_boost(签到膨胀):它按固定 3000 金币发、与广告实际收益脱钩,产品确认从来 不是设计内的口径——奖励只有「签到」和「看视频」两种。签到弹窗的「看广告膨胀」改与福利页 看视频同走 reward_video(按 eCPM 公式)。摘除回调分支、POST /signin/boost、 SigninBoostRecord、signin_boost_coin 配置,并 drop signin_boost_record 表。 **coin_transaction.biz_type='signin_boost' 的历史流水保留不动**——钱是真发过的,账必须 留得住;admin 大盘那两项改从金币流水统计(一次膨胀 = 一笔,与原口径等价),继续能查回历史。 Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
41 lines
4.6 KiB
Markdown
41 lines
4.6 KiB
Markdown
# user — 用户(登录主体)
|
|
|
|
> 模型 `app/models/user.py` · 仓库 `app/repositories/user.py` · 接口 [auth-jverify-login](../api/auth-jverify-login.md) / [auth-sms-login](../api/auth-sms-login.md) / [user-profile](../api/user-profile.md) / [user-avatar](../api/user-avatar.md) / [user-delete](../api/user-delete.md) · [← 索引](./README.md) · [总览](./OVERVIEW.md)
|
|
|
|
整个 App 的用户主体,也是几乎所有业务表的外键宿主。极光一键登录与短信登录都映射到同一行、以 `phone` 唯一索引;**注册即登录**(phone 不存在则 insert,存在则更新 `last_login_at`)。后续加微信/Apple 登录会新增 oauth_account 表,本表不动。
|
|
|
|
## 用在哪 / 增删改查
|
|
- **C(插入=注册)**:首次登录 `POST /auth/jverify-login`(极光)或 `/auth/sms/login`(短信)→ `upsert_user_for_login`,phone 不存在则建行(`register_channel='jverify'/'sms'`)。
|
|
- **U(更新)**:① 每次登录刷 `last_login_at`;② 改昵称 `PATCH /user/profile`、传头像 `POST /user/avatar`;③ 绑/解绑微信 `POST /wallet/bind-wechat` / `/unbind-wechat`(写 `wechat_openid/nickname/avatar_url`);④ 注销 `DELETE /user`(软删,见下);⑤ admin 改状态(禁用/启用)。
|
|
- **D(删除)**:无物理删除。注销是软删 = U:`status='deleted'` + `phone='deleted_<id>'`(释放唯一约束,可同号重注册)+ 清 PII。
|
|
- **R(读取)**:每个鉴权请求经 `api/deps.get_current_user` 解 JWT 的 `sub` 查本表(并校验 `status=='active'`);admin 用户管理列表/详情。
|
|
|
|
## 字段
|
|
| 列 | 类型 | 约束 / 默认 | 说明(取值 / join) |
|
|
|---|---|---|---|
|
|
| `id` | Integer | PK, autoincrement | 用户主键;被多张业务表的 `user_id` 外键引用 |
|
|
| `phone` | String(20) | UNIQUE, index, NOT NULL | 手机号(登录主键)。注销后置 `deleted_<id>` 占位释放唯一约束 |
|
|
| `username` | String(11) | UNIQUE, index, NOT NULL | 对外展示账号 ID:11 位纯数字、首位非 1(与手机号天然区分)、全局唯一、创建时随机生成、不可变、**不参与登录**(登录仍走 phone)。生成见 `repositories/user._gen_username` |
|
|
| `register_channel` | String(20) | NOT NULL, default `jverify` | 取值:`jverify`(极光一键)/ `sms`(短信);`savings_record` 的对比人群另有种子用户用 `seed` |
|
|
| `nickname` | String(64) | nullable | 通用昵称(`PATCH /user/profile` 写) |
|
|
| `avatar_url` | String(512) | nullable | 通用头像相对 URL `/media/avatars/...`(`POST /user/avatar` 写) |
|
|
| `invite_code` | String(16) | UNIQUE, index, nullable | 邀请码:每用户一个稳定短码(懒生成,见 `repositories/invite.ensure_code`),分享链接/二维码里带它。UNIQUE 允许多个 NULL(未生成的用户) |
|
|
| `wechat_openid` | String(64) | UNIQUE, index, nullable | 微信 openid(提现转账用);**一微信一账号**,多个 NULL 允许(多个未绑用户) |
|
|
| `wechat_nickname` | String(64) | nullable | 微信昵称(绑定时拉,展示在提现绑定卡;与通用 nickname 分开存) |
|
|
| `wechat_avatar_url` | String(512) | nullable | 微信头像 URL |
|
|
| `status` | String(20) | NOT NULL, default `active` | 取值:`active`(可登录/鉴权)/ `disabled`(admin 禁用)/ `deleted`(已注销);仅 active 能通过鉴权 |
|
|
| `debug_trace_enabled` | Boolean | NOT NULL, default false, server_default false | 调试链接权限:开了的用户在比价完成弹窗 + 比价记录页能看到「复制调试链接」按钮(运营后台按用户配置);`/me` 与登录响应带出给前端做条件渲染 |
|
|
| `created_at` | DateTime(tz) | server_default now() | 注册时间 |
|
|
| `last_login_at` | DateTime(tz) | 应用层 default utcnow | 最近登录时间(每次登录更新) |
|
|
|
|
## 关系 / Join Key
|
|
- **被引用方(本表是 1,对方是 N/1)**:`coin_account`、`coin_transaction`、`cash_transaction`、`withdraw_order`、`wechat_transfer_authorization`、`signin_record`、`user_task`、`comparison_record`、`comparison_milestone_claim`、`savings_record`、`ad_reward_record`、`ad_watch_log`、`ad_ecpm_record`、`ad_feed_reward_record`、`price_report`、`feedback` 的 `user_id` 均 → `user.id`;`invite_relation` 的 `inviter_user_id` / `invitee_user_id` 均 → `user.id`。
|
|
- 与 `admin_user` **无任何关联**(C 端用户 vs 后台管理员,两套体系)。
|
|
|
|
## 索引与约束
|
|
- PK `id`;UNIQUE+index `phone`、`username`、`invite_code`(允许多 NULL)、`wechat_openid`(允许多 NULL)。
|
|
|
|
## 注意
|
|
- `nickname/avatar_url`(通用)与 `wechat_nickname/wechat_avatar_url`(微信)**分开存,不互相覆盖**。
|
|
- 软删后旧 JWT 仍能用到自然过期(无 jti 黑名单,见 `待办与技术债.md`);鉴权查 `status` 拦得住绝大多数路径。
|