「提醒」：是付费专栏，但是在知识星球里是免费的。目前星球里已更新了5个专栏：「支撑6000万会员的秒杀系统实战」、「几亿用户,百万并发的C端商品系统实战」、「DDD领域驱动设计三年落地实战」、「应付亿级用户规模的支付系统代码实战」和「应付亿级用户的会员体系代码实战」，后续的订单，结算和购物车以及用户和营销专栏等，星球内也都是免费的。
上一篇说了专栏要讲什么，从这篇开始进入具体需求。写代码之前先搞清楚业务层面的问题：用户会员体系为什么做，覆盖哪些功能，优先级怎么排，业务规则是什么。需求理清楚了，后面的架构设计和代码实现才有依据。
文档概要
| 项目 | 内容 |
|---|---|
| 产品名称 | 用户会员体系 |
| 需求发起方 | 业务侧联合推动（运营、市场、产品） |
| 业务目标 | 建设支撑多端接入、亿级用户规模的会员体系，实现用户身份统一、会员成长可运营、用户资产可管理 |
| 目标用户 | C端用户（核心）、运营团队、管理层 |
| 涉及渠道 | 微信小程序、支付宝小程序、APP、抖音小程序 |
需求背景
业务现状
公司注册用户过亿，覆盖微信小程序、支付宝小程序、APP、抖音小程序四个渠道。产品从单一渠道发展到多渠道，用户数据散落在各个渠道的账号体系里，没有做统一身份。
有统一身份真的非常的重要。公司后续分析用户的各种数据，极度依赖这个统一身份的。相信做过大数据的，深有体会。你肯定会经常听到one id，主账号，统一身份等等名词的。另外就是权益问题，没有统一身份，没法玩的。
当前存在的几个问题：
用户身份不统一。 同一个人从微信进来是一个账号，从抖音进来又是一个账号，积分和优惠券各算各的。用户不理解为什么换了渠道就变了一个人，客服经常收到这类投诉。
会员成长体系缺失。 用户注册后没有明确的成长路径，不知道怎么升级、升级有什么好处。运营想做会员日活动，发现连会员等级和权益的对应关系都没定义清楚。
用户资产分散。 自由卡余额、积分、优惠券这些资产没有统一的管理视图。用户不知道自己有多少可用资产，运营也缺少对用户资产总量的把控手段。
接入新渠道成本高。 每加一个渠道，登录模块就要翻一遍，渠道相关的字段直接加在用户表上。已经接入四个渠道了，用户表上渠道相关的字段有十几个，大部分对任何一个具体用户来说都是空的。
假设你没有统一的身份，当你对接新的抖音小程序后，工作量是很大的，无论是开发或者测试的工作量。你可能会改用户表、改了登录逻辑、改了缓存策略，上线后还得刷数据等等。
再比如说，你们公司做大促，然后进行用户数据复盘。运营发现同一批用户在不同渠道的消费数据是割裂的：用户在微信上买了自由卡，到抖音上消费时识别不出是同一个人，积分和优惠券没法跨渠道使用。数据割裂导致运营无法做跨渠道的用户运营策略。
因此
得赶紧把整个用户会员体系搭建起来。这个绝对是公司的一件大事情来的。
用户规模在增长。 注册用户从几千万到过亿，用户数据割裂的问题在量级小的时候还能忍，量级大了以后每次数据修复和账号合并的成本都在指数级上升。
多渠道是常态不是例外。 最初只有微信一个渠道，现在四个渠道，以后可能还有百度、快手。每加一个渠道的接入成本必须降下来，否则技术团队永远在给渠道接入打工。
会员运营是收入增长的关键杠杆。 自由卡用户的月均消费频次是非自由卡用户的2倍以上，会员的留存率和客单价也远高于普通用户。会员体系的完善程度直接影响用户生命周期价值。
如果不这么玩，用户体验差是一方面，更关键的是公司管理层看数据报表的时候，同一个用户在不同渠道被算成不同的人，用户生命周期价值、会员留存率、跨渠道转化率这些核心指标全是失真的。数据团队想做一个完整的用户画像，发现连「谁是同一个人」这个前提都满足不了。
这也是为什么用户会员体系必须从公司战略层面推动，不能当成一个技术部门的需求来做。
CEO工程的核心逻辑
用户会员体系天然横跨产品、运营、技术、数据四个团队，每个团队都有自己的诉求，但又必须基于同一个用户ID才能协同。产品关心多端体验一致性，运营关心会员分层和差异化运营，技术关心系统稳定性，数据团队关心用户画像的完整性。这几个团队的诉求最终汇聚到一个点上：统一的用户身份和会员体系。
从CEO的视角看，这件事的价值可以归结为三个层面：
用户体验是品牌护城河。 同一个人在微信和抖音上被识别为两个不同的人，积分和优惠券各算各的，用户会直接把这个账算到品牌头上。跨渠道资产不通用、等级权益不透明、换手机号数据丢失，这些问题每一个都在消耗用户对品牌的信任。CEO不会关心某个接口的响应时间，但CEO一定关心用户投诉率。
数据分析是决策基础。 没有统一身份，用户行为数据就是碎片化的。微信上的浏览记录、抖音上的下单记录、APP上的充值记录，分属三个不同的账号ID，拼不出一个完整的用户旅程。运营总监想看会员的跨渠道消费路径，CTO想看高价值用户的设备分布，CEO想看用户生命周期价值的变化趋势——这些需求的前提都是同一个人只有一个主账号ID。
会员运营是收入增长的关键杠杆。 自由卡用户的月均消费频次是非自由卡用户的2倍以上，会员的留存率和客单价也远高于普通用户。会员体系完善到什么程度，直接决定了用户生命周期价值的上限。CEO看季度财报的时候，预付费收入（自由卡充值）和会员消费占比是两条必须关注的曲线。
所以这不是一个「能不能做」的问题，而是一个「必须做、而且必须做对」的问题。技术方案可以讨论、可以迭代，但这件事的战略优先级是不容置疑的。
业务价值分析
用户留存价值
| 维度 | 当前状况 | 期望状况 |
|---|---|---|
| 跨渠道身份 | 同一人在不同渠道是不同账号 | 手机号归一，跨渠道自动识别 |
| 会员成长感 | 注册后没有明确的成长路径 | 等级体系清晰，升级有感知 |
| 资产可用性 | 积分/优惠券/自由卡跨渠道不可用 | 资产跨渠道通用 |
| 账号安全 | 换手机号后旧账号数据丢失 | 手机号换绑，数据不丢失 |
用户留存的核心是让用户觉得「这个账号有价值」。等级越高权益越多、积分越多可用资产越多、换渠道数据不丢失，这三个感知叠加起来，用户离开的成本就在持续增加。
运营效率价值
| 维度 | 当前状况 | 期望状况 |
|---|---|---|
| 会员分层运营 | 无法按等级做差异化运营 | 按等级推送不同活动和权益 |
| 资产发放 | 各渠道独立发放，无法统一管理 | 统一发放和管理，跨渠道可见可用 |
| 用户画像 | 各渠道数据割裂，无法拼出完整用户画像 | 统一用户ID，跨渠道数据打通 |
| 渠道接入 | 每次接入需要2到3周，改动面大 | 策略模式隔离渠道差异，接入1周内完成 |
收入增长价值
会员体系对收入的贡献不是直接卖会员费，而是通过三个路径间接拉动：
提升消费频次。 会员等级越高，到店消费频次越高。等级体系设计得好，用户为了保级或升级会主动增加消费。
提升客单价。 会员专属折扣和权益让用户在消费时更愿意选择高价商品或加购。
锁定预付费收入。 自由卡充值直接带来预付费收入。会员体系让自由卡的获取和使用更便捷，充值转化率会提升。
量化预期
| 指标 | 当前值 | 目标值 |
|---|---|---|
| 跨渠道账号重复率 | 约15%（同一人在多个渠道有独立账号） | 5%以内（绑定手机号后自动合并） |
| 会员升级感知率 | 无法追踪 | 80%以上会员知道自己的等级和权益 |
| 自由卡用户月均消费频次 | 非自由卡用户的2倍 | 非自由卡用户的2.5倍 |
| 新渠道接入周期 | 2到3周 | 1周以内 |
| 会员活动参与率 | 无法按等级统计 | 可按等级统计并差异化运营 |
目标用户
C端用户
| 用户群体 | 特征 | 核心诉求 |
|---|---|---|
| 游客 | 首次从某个渠道进入，未绑定手机号 | 浏览商品，不想一进来就被要求注册 |
| 普通用户 | 已绑定手机号，有消费记录 | 跨渠道数据同步，手机号换绑方便 |
| 付费会员 | 有自由卡或会员卡，消费频次高 | 等级权益清晰，资产跨渠道通用 |
| 价格敏感型用户 | 关注积分和优惠券 | 积分获取和消费规则透明，优惠券不浪费 |
运营人员
| 角色 | 核心诉求 |
|---|---|
| 会员运营 | 按等级做差异化运营，配置权益和活动 |
| 资产运营 | 统一管理积分/优惠券/自由卡的发放和回收 |
| 数据分析 | 跨渠道用户数据打通，可按等级做用户分析 |
管理层
| 角色 | 核心诉求 |
|---|---|
| 运营总监 | 会员留存率、会员消费频次、跨渠道转化率 |
| 技术负责人 | 系统稳定性、渠道接入效率、数据一致性 |
| 高管 | 用户生命周期价值、预付费收入、品牌会员规模 |
核心业务流程
用户注册登录流程
整个流程分三个阶段。
首次进入（游客状态）
用户从任意渠道首次进入，系统自动创建一条主账号记录（手机号为空，标识用临时值）和一条渠道账号记录。此时用户是游客状态，可以浏览商品，但不能下单、没有积分和等级。
绑定手机号（用户状态）
用户在某个渠道触发绑定手机号的操作。微信小程序通过解密获取手机号，支付宝通过授权码换取手机号，抖音通过接口获取手机号，APP通过短信验证码验证手机号。
绑定手机号时系统做一次检测：这个手机号是否已经关联了另一个主账号。如果是，把当前渠道账号迁移到已有的主账号下，删除空主账号，实现账号合并。如果不是，直接把手机号写入当前主账号。
用户状态从游客变为正式用户，可以下单、收货、领券。
成为会员（会员状态）
用户完成首次下单或手动开卡，状态从正式用户变为会员。此时初始化积分、等级等会员属性。
会员成长路径
会员的成长路径围绕两个维度：等级和经验值。
经验值获取。 用户消费、签到、参与活动等行为获取经验值。不同行为对应不同的经验值规则，规则可由运营配置。
等级变更。 经验值达到升级阈值时自动升级。等级有保级周期，在保级周期内经验值不达标则降级。升级时触发权益变更通知，降级时触发权益回收。
等级与权益绑定。 每个等级对应一组权益。权益类型包括折扣比例、专属商品、生日礼、免排队等。运营可以灵活配置各等级的权益内容。
用户资产使用流程
用户在C端有五类资产：自由卡余额、会员卡、积分、优惠券、钱包余额。
资产获取。 自由卡通过充值或活动获得；积分通过消费和行为获得；优惠券通过活动发放或手动领取获得；钱包余额通过充值获得；会员卡通过开卡获得。
资产使用。 自由卡和钱包余额用于支付订单；积分用于兑换商品或抵扣；优惠券在订单结算时核销；会员卡用于享受等级权益。
资产核算。 所有资产变动都有流水记录，支持正向和反向核对。积分有过期回收机制，优惠券有过期作废机制。
功能需求
用户身份域
| 功能 | 描述 | 优先级 |
|---|---|---|
| 主账号与渠道账号分层 | 主账号存核心身份信息，渠道账号存渠道登录凭证 | P0 |
| 游客自动创建 | 首次从任意渠道进入，自动创建游客主账号和渠道账号 | P0 |
| 手机号绑定 | 用户在各渠道绑定手机号，完成身份确认 | P0 |
| 跨渠道账号合并 | 绑定手机号时检测并合并同一人的多个账号 | P0 |
| 手机号换绑 | 用户更换绑定手机号，带并发安全保护 | P0 |
| 用户信息查询 | 按主账号ID查询用户完整信息 | P0 |
| 用户信息更新 | 更新昵称、头像等非身份类信息 | P1 |
| 账号解绑 | 解绑某个渠道的登录关联，不影响主账号 | P1 |
| 账号注销 | 用户注销账号，清除所有数据 | P2 |
登录认证域
| 功能 | 描述 | 优先级 |
|---|---|---|
| 微信小程序登录 | 微信授权+手机号获取 | P0 |
| 支付宝小程序登录 | 支付宝授权+手机号获取 | P0 |
| 抖音小程序登录 | 抖音授权+手机号获取 | P0 |
| APP短信验证码登录 | 手机号+短信验证码 | P0 |
| APP密码登录 | 手机号+密码 | P1 |
| 登录策略路由 | 根据渠道和登录方式自动路由到对应策略 | P0 |
| 登录冲突处理 | 同一渠道同一用户重复登录时的冲突解决 | P0 |
| JWT Token管理 | Token生成、刷新、验证 | P0 |
| 登出 | 清除Token和会话 | P0 |
| 游客静默登录 | 游客无需主动操作即可进入 | P1 |
会员等级域
| 功能 | 描述 | 优先级 |
|---|---|---|
| 等级定义 | 配置各等级的名称、阈值、保级周期 | P0 |
| 经验值获取 | 消费/签到/活动等行为获取经验值 | P0 |
| 经验值计算引擎 | 可配置的经验值计算规则 | P0 |
| 自动升级 | 经验值达到阈值时自动升级 | P0 |
| 保级判定 | 保级周期结束时判定是否保级 | P0 |
| 自动降级 | 未达保级标准时自动降级 | P0 |
| 等级变更补偿 | 升级时补发权益，降级时回收权益 | P1 |
| 等级变更通知 | 等级变化时通知用户 | P1 |
| 等级查询 | 查询用户当前等级、经验值、距下一级进度 | P0 |
积分域
| 功能 | 描述 | 优先级 |
|---|---|---|
| 积分获取 | 消费/行为获取积分 | P0 |
| 积分消费 | 兑换商品或抵扣时消费积分 | P0 |
| 积分核算 | 积分变动的双向校验和对账 | P0 |
| 积分过期回收 | 超过有效期的积分自动回收 | P0 |
| 积分计算器 | 可配置的积分计算规则 | P1 |
| 积分与等级联动 | 积分获取同时触发经验值获取 | P1 |
| 积分流水查询 | 查询积分变动记录 | P0 |
用户资产域
| 功能 | 描述 | 优先级 |
|---|---|---|
| 自由卡管理 | 自由卡的开卡、充值、消费、查询 | P0 |
| 自由卡多卡扣减 | 多张自由卡时的扣减顺序和余额分配 | P0 |
| 会员卡管理 | 会员卡的开卡、续费、状态管理 | P0 |
| 钱包余额管理 | 钱包充值、消费、查询 | P0 |
| 钱包免密扣款 | 小额免密扣款，带安全边界 | P1 |
| 资产核算 | 各类资产变动的双向校验 | P0 |
| 资产对账 | 定时对账，发现差异自动告警 | P1 |
| 资产总览 | 用户查看所有资产的汇总视图 | P1 |
会员权益域
| 功能 | 描述 | 优先级 |
|---|---|---|
| 权益定义 | 配置权益类型、内容和适用等级 | P0 |
| 权益规则引擎 | 按等级和条件匹配权益 | P0 |
| 权益领取 | 会员领取可用权益 | P0 |
| 权益核销 | 使用权益时核销 | P0 |
| VIP专属权益 | 高等级会员的专属权益配置 | P1 |
| 特殊权益策略 | 按条件（生日/首单等）触发的特殊权益 | P1 |
优惠券域
| 功能 | 描述 | 优先级 |
|---|---|---|
| 优惠券发放 | 活动/运营/系统自动发放 | P0 |
| 优惠券核销 | 订单结算时使用优惠券 | P0 |
| 优惠券过期作废 | 超过有效期自动作废 | P0 |
| 优惠券查询 | 查询用户可用和已用优惠券 | P0 |
| 券码策略 | 优惠券的编码规则和验证逻辑 | P1 |
| 优惠券回收 | 未使用且已过期的优惠券批量回收 | P1 |
业务规则
| 规则类别 | 具体规则 | 补充说明 |
|---|---|---|
| 账号分层 | 主账号存跨渠道共享的身份信息，渠道账号存渠道侧登录凭证 | 新增渠道不改主账号表结构 |
| 游客创建 | 游客的标识字段用临时值（不重复），不用空字符串 | 空字符串在唯一索引下会冲突 |
| 跨渠道识别 | 手机号作为全局唯一标识，绑定手机号时触发合并检测 | 手机号字段必须加唯一索引 |
| 账号合并 | 绑定手机号时发现已有同手机号主账号，执行合并 | 合并必须加分布式锁，锁粒度为手机号 |
| 手机号换绑 | 换绑时同时锁旧号和新号，按字典序获取锁避免死锁 | 每月限制换绑次数 |
| 状态流转 | 游客→用户→会员，单向不可逆 | 状态只改主账号表，不改渠道账号表 |
| 登录策略 | 每个渠道+登录方式对应一个策略类，通过Spring Map注入自动路由 | 新增渠道只加策略类和枚举值 |
| 等级保级 | 等级有保级周期，周期内未达保级标准则降级 | 保级周期由运营配置 |
| 经验值计算 | 不同行为对应不同经验值规则，规则可配置 | 消费按金额比例，签到按固定值 |
| 积分过期 | 积分有有效期，过期自动回收 | 过期前7天提醒用户 |
| 自由卡扣减 | 多张自由卡时按到期时间升序扣减（先到期的先用） | 扣减必须走核算校验 |
| 钱包免密 | 单笔100元以下免密扣款，超出需验证 | 免密额度可由用户自主调整 |
| 优惠券核销 | 每张券只能使用一次，核销后状态变为已使用 | 核销和订单创建必须在同一事务 |
状态流转
用户状态机
| 当前状态 | 触发条件 | 目标状态 |
|---|---|---|
| 游客 | 绑定手机号 | 用户 |
| 用户 | 首次下单或手动开卡 | 会员 |
两个要点：
状态流转是单向的。 游客可以变成用户，用户可以变成会员，反过来不行。这意味着user_type字段只会从0变成1再变成2，不存在回退的场景。
状态变更只改主账号。 渠道账号表不存user_type，不参与状态管理。无论用户从哪个渠道触发状态变更，改的都是同一张主账号表的同一个字段。
会员等级状态机
| 当前状态 | 触发条件 | 目标状态 |
|---|---|---|
| 普通会员 | 经验值达到银卡阈值 | 银卡会员 |
| 银卡会员 | 经验值达到金卡阈值 | 金卡会员 |
| 金卡会员 | 经验值达到黑卡阈值 | 黑卡会员 |
| 银卡会员 | 保级周期内未达保级标准 | 普通会员 |
| 金卡会员 | 保级周期内未达保级标准 | 银卡会员 |
| 黑卡会员 | 保级周期内未达保级标准 | 金卡会员 |
等级变更时有两件事必须同步处理：
升级时补发权益。 用户从银卡升到金卡，金卡对应的专属权益需要立即生效。如果用户当天正好有一笔消费，这笔消费应该享受金卡折扣而不是银卡折扣。
降级时回收权益。 用户从金卡降到银卡，金卡专属权益需要失效。已经在使用中的权益（比如本月的生日礼已经领取）不追溯回收，但尚未领取的权益不再可用。
需求优先级
P0：第一期必须上线
P0是用户会员体系能正常运行的最小集合。
| 模块 | P0功能项 |
|---|---|
| 用户身份 | 主账号与渠道账号分层、游客自动创建、手机号绑定、跨渠道账号合并、手机号换绑、用户信息查询 |
| 登录认证 | 四渠道登录（微信/支付宝/抖音/APP短信验证码）、登录策略路由、登录冲突处理、JWT Token管理、登出 |
| 会员等级 | 等级定义、经验值获取、经验值计算引擎、自动升级、保级判定、自动降级、等级查询 |
| 积分 | 积分获取、积分消费、积分核算、积分过期回收、积分流水查询 |
| 用户资产 | 自由卡管理、自由卡多卡扣减、会员卡管理、钱包余额管理、资产核算 |
| 优惠券 | 优惠券发放、优惠券核销、优惠券过期作废、优惠券查询 |
P1：第一期增强
P1在P0稳定运行后尽快补齐。
| 模块 | P1功能项 |
|---|---|
| 用户身份 | 用户信息更新、账号解绑 |
| 登录认证 | APP密码登录、游客静默登录 |
| 会员等级 | 等级变更补偿、等级变更通知 |
| 积分 | 积分计算器、积分与等级联动 |
| 用户资产 | 钱包免密扣款、资产对账、资产总览 |
| 会员权益 | 权益定义、权益规则引擎、权益领取、权益核销、VIP专属权益、特殊权益策略 |
| 优惠券 | 券码策略、优惠券回收 |
P2：后续迭代
| 模块 | P2功能项 |
|---|---|
| 用户身份 | 账号注销 |
验收标准
系统稳定性
| 指标 | 标准 | 验证方式 |
|---|---|---|
| 登录接口可用性 | ≥ 99.9% | 监控数据 |
| 登录响应时间 | P99 < 500ms | APM监控 |
| 账号合并正确率 | 100%（不允许出现同一手机号对应多条主账号） | 数据巡检 |
| 跨渠道数据一致性 | 用户在任意渠道的等级/积分/资产数据完全一致 | 对账脚本 |
业务转化
| 指标 | 标准 | 验证方式 |
|---|---|---|
| 游客→用户转化率 | 绑定手机号引导后 ≥ 60% | 埋点数据 |
| 新渠道接入周期 | 从启动到上线 ≤ 5个工作日 | 实际执行验证 |
| 会员升级感知率 | 升级后24小时内查看过新权益的比例 ≥ 50% | 埋点数据 |
| 积分过期提醒触达率 | 过期前7天提醒触达 ≥ 95% | 消息投递数据 |
数据准确性
| 指标 | 标准 | 验证方式 |
|---|---|---|
| 积分余额准确率 | 100%（积分流水总和必须等于当前余额） | 对账脚本 |
| 自由卡余额准确率 | 100%（出入账流水总和必须等于卡内余额） | 对账脚本 |
| 优惠券状态准确率 | 已核销券不可二次使用 | 压测验证 |
风险评估
| 风险项 | 影响程度 | 发生概率 | 应对措施 |
|---|---|---|---|
| 账号合并并发冲突 | 高 | 中 | 绑定手机号加分布式锁，锁粒度为手机号 |
| 手机号换绑死锁 | 高 | 低 | 双锁按字典序获取 |
| 等级降级引发用户投诉 | 中 | 中 | 降级前7天提醒，降级后保留30天缓冲期 |
| 积分过期用户不知情 | 中 | 中 | 过期前7天推送提醒 |
| 资产核算不一致 | 高 | 低 | 定时对账 + 异常告警 + 人工补录 |
| 新渠道登录接口变更 | 中 | 中 | 策略模式隔离，渠道变更只改对应策略类 |
| 大促登录量激增 | 高 | 低 | 登录接口独立部署，缓存Token减少DB查询 |
术语表
| 术语 | 定义 |
|---|---|
| 主账号 | 一个自然人在系统中的唯一身份记录，跨渠道共享，以手机号为全局标识 |
| 渠道账号 | 用户在某个渠道（微信/支付宝/抖音/APP）的登录凭证记录，关联到主账号 |
| 游客 | 首次从渠道进入、未绑定手机号的用户，有主账号ID但手机号为空 |
| 自由卡 | 公司发行的虚拟预付卡，用户充值后可用卡内余额消费 |
| 会员卡 | 用户的会员身份凭证，关联等级和权益 |
| 经验值 | 用户通过消费/签到/活动等行为获取的成长值，达到阈值触发等级变更 |
| 保级周期 | 等级维持的时间窗口，周期内未达保级标准则降级 |
| 权益 | 会员等级对应的专属优惠和服务，如折扣比例、专属商品、生日礼 |
| 核算 | 对资产变动做双向校验，确保流水和余额一致 |
小结
做需求分析的时候，技术同学最容易忽略的一件事是：需求里的每一条业务规则，后面都会变成代码里的一个约束。账号合并为什么必须加分布式锁，因为手机号唯一索引在并发场景下会冲突。游客的标识字段为什么不能用空字符串，因为MySQL唯一索引对空字符串的处理会导致多条记录冲突。等级降级为什么要有缓冲期，因为用户看到自己权益突然没了会打客服电话。
这些约束不是写代码的时候才冒出来的，它们在需求分析阶段就已经存在了。需求文档的价值不只是告诉开发要做什么，更重要的是把每条规则背后的约束条件讲清楚。约束想明白了，代码写出来就稳了。
所有的代码都可以在知识星球里获取。「应付亿级用户的会员体系代码实战」这个专栏在星球里是免费的，也可以接受无限次的咨询。后续新写的所有付费专栏，在知识星球里都是免费的。我的星球是：
- 老码头的技术浮生录
