# 会员档案（GetTenantMemberList）

> 自动生成于 2026-02-13 | 数据来源：本地 JSON 样本

## 基本信息

| 属性 | 值 |
|------|-----|
| 接口路径 | `MemberProfile/GetTenantMemberList` |
| 完整 URL | `https://pc.ficoo.vip/apiprod/admin/v1/MemberProfile/GetTenantMemberList` |
| 请求方法 | `POST` |
| Content-Type | `application/json` |
| 鉴权方式 | Bearer Token（`Authorization` 头） |
| ODS 对应表 | `member_profiles` |
| 分页方式 | `page` + `limit`（最大 100） |
| 时间范围 | 不需要 |

## 请求参数

| 参数名 | 类型 | 示例值 | 说明 |
|--------|------|--------|------|
| `isMemberInBlackList` | int | `0` | 是否黑名单（0=全部） |
| `status_Revoked` | int | `0` | 是否已注销（0=全部） |
| `isBindOrg` | int | `0` | 是否绑定组织（0=全部） |
| `registerSource` | int | `0` | 注册来源（0=全部） |
| `page` | int | `1` | 页码（从 1 开始） |
| `limit` | int | `100` | 每页条数（最大 100） |

## 响应字段（共 15 个）

| # | 字段名 | 类型 | 示例值 |
|---|--------|------|--------|
| 1 | `id` | int | 2955204541320325 |
| 2 | `create_time` | string | '2025-11-08 01:29:33' |
| 3 | `member_card_grade_code` | int | 2790683528022853 |
| 4 | `mobile` | string | '18620043391' |
| 5 | `nickname` | string | '胡先生' |
| 6 | `register_site_id` | int | 2790685415443269 |
| 7 | `site_name` | string | '朗朗桌球' |
| 8 | `member_card_grade_name` | string | '储值卡' |
| 9 | `system_member_id` | int | 2955204540009605 |
| 10 | `tenant_id` | int | 2790683160709957 |
| 11 | `referrer_member_id` | int | 0 |
| 12 | `point` | float | 0.0 |
| 13 | `user_status` | int | 1 |
| 14 | `status` | int | 1 |
| 15 | `growth_value` | float | 0.0 |

## 新增字段（相对本地 JSON 样本）

以下字段在最新 API 响应中出现，但本地 JSON 样本中不存在：

| 字段名 | 类型 |
|--------|------|
| `pay_money_sum` | float |
| `person_tenant_org_id` | int |
| `person_tenant_org_name` | string |
| `recharge_money_sum` | float |
| `register_source` | int |

## 详细字段分析

> 以下内容迁移自旧版 `member_profiles-Analysis.md`，包含字段的业务含义、枚举值、跨表关联等详细说明。

三、主键 / 会员标识类字段
1. id

类型：int

非空：200 条

唯一值个数：199（有 1 个 ID 出现了 2 次，完全重复记录）

含义：

这是“租户内会员账户”的主键 ID。

对应一个 会员在当前租户下的一条账户档案（通常是一张卡/一个账户）。

和其它表的关系（从字段命名推断）：

在余额变更、储值卡列表等表中，通常会有 member_card_id 或类似字段，按系统习惯，这类字段一般就对应这里的 id。

重复记录说明：

id=2799212615616261 的记录在文件中出现了两次，所有字段完全相同，明显是导出过程重复，不是设计层面的问题。

2. system_member_id

类型：int

唯一值个数：199（同样有一个值出现了 2 次，对应上面的重复记录）

含义（结合其它文件）：

这是“系统级会员 ID”，在全平台唯一，用来把一个会员在不同门店/不同卡类型下的账户统一到一个“人”的维度上。

在其它 JSON（例如助教流水）里也出现了 system_member_id，用来标识消费对应哪个会员。

结构关系：

在“会员档案”这张表里，system_member_id 与 id 是一对多的关系（理论上：一人可有多张卡），只是本次截取的数据里恰好只有一人一条记录（除那条导出重复）。

3. member_card_grade_code / member_card_grade_name

这两个字段是成对出现的：一个数值码，一个中文名称。

member_card_grade_code

类型：int

唯一值个数：4

member_card_grade_name

类型：string

唯一值个数：4

从数据可得对应关系：

member_card_grade_code -> member_card_grade_name
2790683528022853       -> "储值卡"
2790683528022855       -> "台费卡"
2790683528022856       -> "活动抵用券"
2790683528022857       -> "月卡"


含义：

这是“会员卡种类/等级”的定义字段。

member_card_grade_code 是内部编码（枚举 ID），member_card_grade_name 是展示用名称。

统计分布（只是为了说明结构，不做盈利分析）：

储值卡：112 条

台费卡：82 条

活动抵用券：4 条

月卡：2 条

结构上的意义：

从设计上看，这张“会员档案”实际上是 “会员 × 卡种” 级别的账户记录：

system_member_id 表示“谁”；

member_card_grade_code/name 表示“哪种卡”；

id 则是这张卡在当前租户下的账号 ID。

四、联系方式与会员展示信息
4. mobile

类型：string

唯一值个数：199（1 个号码重复，对应重复记录）

特征：

全部是 11 位手机号字符串，未发现空字符串或明显无效值。

含义：

会员绑定的手机号码。

结构意义：

在普通业务里，“手机号 + tenant_id”通常具备“会员唯一性”的作用（禁止同租户重复注册同一个手机号）。

在本数据中，手机号重复仅出现在那条重复的会员记录上，可以判断是导出重复，而非同一手机号注册多个账户。

5. nickname

类型：string

唯一值个数：200（每条记录昵称都不同）

含义：

会员在当前租户下的显示名称（可以是姓名，也可以是昵称）。

与助教流水里的 nickname 区分：

助教流水中的 nickname 是“助教昵称”（服务人员），这里的 nickname 是“会员昵称”，虽然字段名相同，但含义不同，关联时要注意表的上下文。

五、注册门店 / 租户维度
6. register_site_id

类型：int

唯一值个数：1

所有记录都是同一个值：2790685415443269

含义：

会员的注册门店 ID。

结构关系：

与其它 JSON 中普遍存在的 site_id 相同（都是“朗朗桌球”这家店的 ID）。

说明本文件的 200 条会员账户，全部是在这家门店注册的。

7. site_name

类型：string

唯一值个数：1

全部为 "朗朗桌球"

含义：

注册门店名称，属于冗余字段，用于直接展示。

与 register_site_id 关系：

register_site_id → 逻辑外键

site_name → 冗余的门店名称快照

8. tenant_id

类型：int

唯一值个数：1

全部为 2790683160709957

含义：

租户/品牌 ID。

确认这批会员都是属于同一个租户“朗朗桌球”（而非连锁多店场景）。

六、推荐关系与成长值字段
9. referrer_member_id

类型：int

唯一值个数：1

全部为 0

含义（按命名推断）：

推荐人会员 ID，用于记录该会员是由哪位老会员推荐。

目前数据的状态：

本批数据中全部为 0，意味着在导出时间范围内，这些会员账户没有记录任何推荐关系（或该功能未使用）。

10. point

类型：float

唯一值个数：1

全部为 0.0

含义：

当前积分余额（这条会员账户的积分值）。

当前状态：

所有账户积分为 0，说明要么积分体系刚启用，要么此数据截取点时，积分未开始累积或未导出非零记录。

11. growth_value

类型：float

唯一值个数：1

全部为 0.0

含义（按常见会员体系设计）：

成长值 / 经验值，用于会员等级晋升的累计指标。

当前状态：

与 point 一样，全部为 0，说明成长体系虽然有字段，但目前没有实际使用或数据尚在初期。

从这三个字段可以看出：
系统预留了“推荐关系 + 积分 + 成长值”的完整会员运营链路，但这家门店在当前截取时间点上基本还处于“只建档案、不玩复杂运营”的状态。结构上功能完备，只是业务上尚未填充数据。

七、状态 / 启用标志相关字段
12. user_status

类型：int，枚举

唯一值个数：1

全部为 1

含义（结合行业惯例）：

用户账号状态（偏“用户逻辑”层面的状态）。

典型枚举可能为：

1：正常启用

0：禁用 / 冻结

其他值：例如已注销等（本数据尚未出现）

当前数据：

全为 1，说明导出的都是正常有效的会员账户。

13. status

类型：int，枚举

唯一值个数：1

全部为 1

含义（按命名推断）：

帐户状态（偏“卡状态/档案状态”）。

在你之前的其它 JSON 里，“status = 1”通常也是“正常”，4 等值用来表示删除/失效等。

当前数据：

同样全部为 1，表示这些档案都是有效的卡档案，没有注销/停用记录被导出。

这里有一个设计上的细节：

user_status 和 status 都是状态字段，属于“业务状态 + 系统状态”并存的设计。

很多系统会用：

user_status 管用户层面（是否允许登录、是否冻结等）；

status 管卡账户本身（卡是否作废、是否挂失）。

在你这份数据里，两者当前值完全一致（都是 1），但从结构上可以看出未来可以出现两者不一致的场景（例如用户已注销但卡余额仍在清算中等）。

八、时间字段
14. create_time

类型：string

格式：YYYY-MM-DD HH:MM:SS

唯一值个数：86

典型样例：

'2025-07-20 20:46:38'（出现 5 次）

'2025-07-20 20:46:36'（5 次）

…

含义：

会员账户的创建时间（即这条档案/这张卡在系统中被创建的时间）。

数据特征：

很多时间戳成批出现（同一时间出现 5 条），高度怀疑是“批量导入/老系统迁移”或“批量开卡”的结果，而不是一条条手动录入。

和其它业务数据（例如消费流水）相比，时间集中在 2025-07-20 晚间，说明这批会员是某个时间点一次性导入的。

九、综合结构判断与和其它 JSON 的关系

从字段设计可以得出以下结构层面的结论（仅从结构出发，不做任何盈利/行为分析）：

记录粒度

每一条 tenantMemberInfos 记录，是一个“会员在当前租户下某个卡种/账户”的档案。

关键组合键可以理解为：

(tenant_id, system_member_id, member_card_grade_code)

或更加具体的主键 id。

与其它表的关联键

与消费流水（台费、助教、商品等）

通过 system_member_id 把会员消费流水与会员档案关联起来。

一些表里还会出现 member_card_id 或类似字段，对应这里的 id。

与储值卡/余额变更/充值等表：

这些表的 member_card_id / system_member_id / tenant_member_id（在不同表叫法略有差异）会与这里的 id 和 system_member_id 做主外键关系。

与门店（site）：

register_site_id 与其他表的 site_id 援用同一门店 ID；site_name 是冗余名称。

枚举字段总结

卡种枚举（明确）：

member_card_grade_code / member_card_grade_name 四种：

储值卡 / 台费卡 / 活动抵用券 / 月卡

状态枚举（当前只见到一种值，但显然是枚举型设计）：

user_status：1（正常）

status：1（正常）

其它预留枚举（当前值全部为单一值）：

referrer_member_id：目前全为 0（“无推荐人”状态）

字段使用状态

已投入使用的字段：

id, system_member_id, member_card_grade_*, mobile, nickname, register_site_id, site_name, tenant_id, create_time, user_status, status。

这些字段组合起来，足以支持基本的会员识别、卡种区分和简单状态管理。

结构上预留但目前几乎未被使用的字段：

referrer_member_id（推荐体系）

point（积分体系）

growth_value（成长值/等级成长体系）

这些字段从结构上完整存在，但在当前数据截面上全部为默认值 0，说明门店尚未使用这些高级运营功能。

分页与导出行为的结构线索

data.total = 438，而本次两个 page 合并只有 200 条，说明：

该接口是典型的分页接口（每页 100 条）；

当前只导出了前两页（或者是时间/条件过滤导致只取到部分）。

id 和 system_member_id 各有一个值重复了两次，且所有字段完全相同：

很可能是分页处理时边界重叠导致的重复（比如页 1 末尾的记录又出现在页 2 的开头），不是数据设计错误。

十、小结：会员档案.json 的角色

从纯字段与结构角度，可以把 20251110_043209_会员档案.json 概括为：

它不是“纯粹的人头表”，而是“会员 × 卡种 的账户档案表”，一条记录既包含“谁”（system_member_id / mobile / nickname），也包含“是什么卡”（member_card_grade_xxx）。

它作为 会员维度的核心参照表，被其它业务表通过 system_member_id 和 id 广泛引用：

消费流水中的会员消费，回来可以通过这些键指向这一表；

储值余额变动、充值、退款等资金类流水，最终也会落到某个 id 所代表的“会员账户/卡”上。

从字段现状可见：门店目前主要使用的是“储值卡 + 台费卡 + 少量月卡/抵用券”的基本功能，重点在“建档与卡种区分”，尚未真正利用积分、成长值、推荐等高级字段。这是“结构完备、业务使用部分开启”的典型状态。