原型链接

• [用户端原型]https://modao.cc/board/share/K7moOWiMt4f6k7nbp9ETBf
• [商家端原型]https://modao.cc/board/share/fy0ULarzt4f6lfosJmn6tW

演示站：

https://fast.qqss.net

总后台

• https://fast.qqss.net/qs

用户端/商户端

• 通过首页注册

演示站用途

1. 测试功能、性能、bug、使用流程、数据准确性。
2. 线上开发：测试数据不清空。
3. 可对接口进行调试，引用，前端页面开发。

待办（新提问题做特级待办项，优先处理）

1. 总后台部分页面交互，比如类似功能没有在一个大菜单下、缺少行详情-小屏列表看不全、抽屉没有关闭按钮、对接商户后台快捷登录、列表需要显示直观性文字等细节问题。
2. [延期项]店铺装修。
3. [延期项]货源名片风格。

开发日志 大约用时

2025-11-21 4H 周 6

1. 修复部分错误，优化部分代码。后面不在记录微刀开发日志，所有操作动作都已被提交至 git 记录

2. 开始正式整理 api 手册

2025-11-21 0H 周 5

2025-11-20 4H 周 4

1. 项目分析与优化：漏洞分析（代码漏洞）和性能分析（redis 队列、协程、thinkorm 缓存）-只分析，并不进行优化(数据量太小，且增删改查微秒级别或多关联自定义查询无必要)

2. 构建手册 vitepress 项目

3. 移除性能不佳且不正确的自定义定时任务集合文件

4. 商品统计:商品销售额-当前店铺订单量排行的商品。分销商品收益-我的商品被分销的收益排行榜 2H

2025-11-19 7.5H 周 3

1. 分销为当日新增数

2. 代理等级编辑变更、上传配置变更

3. push 推送

4. 商户消息外放：每日报表更新，售出通知,结算通知测试通过 待测试 库存预警通知 售后通知

5. [安全] 接口请求频率限制。

6. 信誉分：取消低于 60 分禁止销售功能，取消月评分，周扣分如果上个周期被扣分则固定扣 2。

2025-11-15->18 44+

1. 安装手册、常见问题、模版渲染机制修改。

2. 后台/商户日志记录插入数据使用 Redis 队列。

3. 大厅邀请码功能变更：商户自发购买。

4. 平台后台：信誉分管理、推广记录、大厅名片管理。

5. 信誉分记录时间搜索、签到日志时间搜索。信誉分日志类型字段。

6. [安全] 跨域设置。

7. 消息通知检测完成。

8. 销售分润检测完成。

9. 售后检测完成。

10. 销售统计-商品统计：应是统计的 自己的商品收益前 5，和自己代理别人的商品收益前 5[⭐ 功能再次沟通待办]

11. 移除不在使用的扩展配置项，避免 composer 后的启动错误。

12. 重构 公告发送，支持发送给所有商户或按角色发送。

13. 完善用户注销功能，只检测是否有店铺和账户余额，不满足则不可注销。

14. 重构店铺收藏和商品收藏接口，不在使用关联查询。

15. 订单查询时，如果商品已经被删除，则显示商品快照信息。

16. 完善商品详情页和详情页面接口，路由。

17. 完善定时任务多，手工配置繁琐，配置 workerman/crontab 定时任务组件使用的方法。

18. jwt 密钥配置及账号等基础。

19. 统一开店流程。

20. 风控管理 - 代理近期销售：接口同 下级代理订单（区别是 在我的订单页面是展示我的收益。在这里应该展示用户付款金额。含 23 级别代理）

21. 风控管理 - 查询用户近期消费：应该是只统计用户在自己店铺里的消费，不统计下级分销的。（根据历史使用此功能一般是为了统计用户在自己店铺消费情况，然后做私域活动）

22. 上级价格改动后，下级商品下架，直接上架时也更新成本价；+ 分销黑名单检测。

23. 分销黑名单：关联位置

    a. 商品上架

    b. 我的上级-商品列表

    c. 货源大厅-商品列表

    d. 对接商品时，检查是否在黑名单中(一般来说 b c 的操作按钮应该已经是无权限)

    e. 添加时，按需下架（不发通知）

    d. 商户注销时，不清理该模型。持久保存。

24. 所有表清理关系统计。

25. 定时任务：清理 40 天以上数据。

26. 总后台 删除用户功能表结构所有统计。

27. 总后台注销记录。

28. 总后台改用户店铺号。

29. 总后台签到日志记录。

30. 总后台信誉分日志记录。

31. 用户注销账号的功能 、 注销次数关键性信息统计：注销检测通过后立即注销，数据删除将在队列中执行，所以设置 1 小时内无法重新注册商户。

32. 消息通知外放 库存预警 交易通知 售后通知 提现通知 每日报表：使用推送队列，避免影响阻塞主流程。完善商户通知设置。

33. 扩容已售库存模型：记录售出者及所属关系、购买者、创建时间(为 40 天清理使用)。也用于可能后期需要扩展成单独展示赠送的和购买的区分开（可前端自行判断）。

34. 搜索限流：按需求做（渐进式累计封禁机制，非窗口）。

35. sql 表规范注释和字段规范注释。

36. 用户端数据时效性。

37. 更新资金模型操作字典，新增管理员对用户余额的操作，更新用户端资金明细列表。

38. 商品新功能：

    a. 售完下架-出货后如果库存为 0，使用异步队列下架自己和可能被代理的商品-不影响主体下单流程；

    b. 发货方式 （风险项： 手动出货 有超售风险 及 售出后商品源被删\下架等 无法查询问题，暂时使用无论自动 手动 都自动出货）；

    c. 店铺中显示是否

2025-11-12->14 32H 周三->周五

@ 时效性: 以当前时间往前推n天，并不在从n天前的凌晨计时。比如此时 2025-11-24 1:36 往前推 7 天，则从 2025-11-17 1:36 开始计时。

1. 快捷操作 api 确认；平台消息 确认

2. 商品管理 确认

3. 店铺管理 确认（店铺装修除外）

   a. 移除店铺链接关闭功能（功能梳理：系统是使用以店铺号搜索店铺属于自带流量平台，所以只有唯一的店铺入口链接，所以不应该关闭此链接，此处功能应该独属于店铺状态功能）

   b. 确定使用 shop_status 作为店铺状态，表示为平台允许的店铺状态，并在我的店铺页面做显示。close_status 为商户自由控制开关打样状态。

   c. 信誉分：信誉分日志列表 增加时效性（⭐ 待办记录：因为要计算上个月记录，此模型不遵守用户设置的清理周期，而固定为平台的设计项：40 天）

4. 风控管理

   a. 区分是自己直属代理（只可拒绝直属代理）还是三级代理

5. 销售统计 完成

   a. 利润统计 ，应使用同一接口：展示最近 7 或 14 日(应遵循数据周期)数据：自己商品收（含下级分销商品收益）、自己代理别人的收益、推广收益。及对应当日的综合收益（自己的商品 或许 有成本价 考虑需要多一个参数）

   b. 商品统计 ，应使用同一接口：展示最近 7 或 14 日(应遵循数据周期)数据：自己商品的收益排行前 5，代理商品的收益排行前 5。推理：存在分销关系 无法在收益表中查询每一笔交易，应该扩容自动解冻模型。

   c. 销售走势

6. 商家助手 a. 推广 完成

   b. 推送 待办 移除待办

   c. 数据时效性 完成

7. 我的订单 确认

   a. 订单完成方法 用户余额扣款前加锁，防止并发未减余额。

   b. 我的订单 按用户名搜索用户购买信息；增加买家用户 ID。移除不必要的关联模型展示；增加时效性

   c. 推广：返佣明细从资金日志中获取并增加时效性；邀请记录列表不在使用时效性(永久关系，除非上级账号删除)；推广统计数据使用资金冻结模型记录并增加时效性

8. 货源分销

   a. soure（source）拼写错误造成的 bug->代理价格变动时未及时下架->用户下单提交 45->代理分佣 5->上级分佣 50->源分佣->25,45 < 15+50+25 严重漏洞修复。（梳理：只要变动价格，下级必然下架。用户确认支付时，必检查商品状态）

9. 货源大厅

   a. 货源名片签到日志数据->日历展示;取消名片与系统名片关联，使用 card_level 表示当前名片等级用于快速排序(梳理:后台增加名片等级后-一旦被使用，不可更改与删除。建议提前做好规划)

   b. 货源名片排序功能更新,准确的信誉分值, 货源名片是否为优质商家标识

   c. 拆分购买邀请码功能，更新邀请码功能列表（添加状态 0:可售 1:已售 2:已使用 用于各种记录计算）；增加我已经购买过的接口。更新总后台邀请码页面。

10. 钱包 整理完成

    a. 缺失补全：运营钱包支出明细，可使用 merchantapi/wallet/platform/log ( business_type = 'deposit_money'，signed = 0) ，signed 含义 - 0 为负数 1 为正数

    b. 功能补全： 待解冻订单 -> 使用待解冻列表（功能梳理：剖析商户可能需要知道这笔订单是否已经解冻，订单因被投诉被冻结等）

    c. 提现记录 增加时效性

    d. 充值记录 增加时效性

    e. 资金日志列表 增加时效性

    f. 冻结资金列表 增加时效性

11. 售后 更新中

    a. 并放到订单菜单中查看 （功能梳理：仅商品源用户和商品直售用户显示，如果存在中间层代理 不扣分 也 不记录在下级投诉中，因为中间层不参与扣分和投诉问答及投诉处理）

    b. 增加列表数据 时效性

    c. 合并自己的订单投诉和下级代理的订单投诉为统一接口 统一列表。

    d. 增加 平台判定时 买家责任逻辑；商户责任时的 信誉分扣除逻辑

12. 个人中心

    a. 注册时间，使用开通店铺的时间

    b. 二级密码：首次设置时不需要邮箱验证。更改时需要邮箱验证码的验证，并判断是否已经绑定了邮箱

    c. 消息列表 增加时效性

13. 用户下单确认

    a. 检查商品状态（检查商品状态、店铺、卖家状态）

14. 总后台 a. 订单列表：展示平台收益 变更为 减去被推广分走的平台收益后的最终利润

15. 全部检查：商品删除时，影响到的列表的调用情况，并使用 null 合并运算，及模型默认值处理。

16. 用户端

a. 更新店铺演示页面, 为手机端

b. 添加收藏店铺和收藏商品的原始属性数据

c. 显示下单的手续费

d. 完善资金账单：资金日志、 用户充值记录列表、

e. 订单投诉页面：参考淘宝投诉设计，平台 24 小时后按需介入。增加 投诉时展示卡密信息。

f. 订单撤诉时，资金冻结时间恢复至冻结时间+24 小时；接口返回数据字段处理，隐藏不必要的字段

2025-11-11 9H 周二

1. 售后二版
2. 开始按原型脑图制定菜单及整理代码
3. 数据概览、交易概览、增长概览
4. 待解冻列表
5. 代码整理。。。

2025-11-9 10H 周一

1. 商品订单退款时的各种计算 验证通过 = 销售统计通过。移除待办项 商品订单退款。只需展示即得收益

2. 检查修正 拒绝下级代理的逻辑不通过。原因： 三级可能还正常代理了上级的自有商品 应该查所有代理商品 然后从商品循环下架

3. 完成 买家黑名单功能

4. 生成店铺时 自动生成信誉分资料

5. merchantapi/distribution/agentrelation/myagentlist 不可操作三级代理 应该给出标识 ✔

6. ⭐ 待办 探查后期是否需要直接在商品代理关系表中记录相关的销售记录 2025-11-13 取消待办：我代理的商品中，不在显示出售的卡密数量(没有啥意义，收益才是要关心的)；订单量按订单模型走；收益按冻结模型走；粗略整体销售收益按商户收益分析模型走。

7. 梳理功能：商户店铺信誉分 周 月 重计加分项 - 如果订单评优已经够 10 分了，然后如果在历史周期内（比如上周不达标，周不达标 月必然不达标）存在扣分，则把 10 分额外分 2/5 分，直至扣完这 10 分(其中订单量不够，不扣分) ⭐ 但是逻辑依旧不太对，比如月不够 2 周为 4，月扣 5 则又没了 thinking

8. 所有解冻流程：自动解冻表数据 状态更新为 2 表示已经解冻操作过。此数据表不在做删除行处理，只在平台定时（⭐ 待办 40 天）清理数据时清理2025-11-13 后要求不删除，用于记录订单收益关系

2025-11-9 9H 周日

1. 代码整理。。。
2. 收益统计；订单删除时删除对应的用户收益统计（注意，不删除资金冻结关系）
3. 商品订单退款时的各种计算，最终目的结果：商家余额已扣除,买家退款已原路退回
4. 取消待办 分销黑名单 -》它的功能指向 拒绝直属下级代理 - 2025-11-21 功能变更 支持加分销黑名单

2025-11-8 6H 周六

1. 增加 用户扩展配置模型 用于存储用户可自由修改的项目 用于数据外放 数据时效性 等不需要随用户生成的信息
2. 代理商品编辑中，检测是否是三级代理，是则需要不可被继续设置代理 can_proxy = 0
3. ⭐ 待办项 考虑一种逻辑，当一个商家 从不同的上家代理了同一个源头商品，那么查询关系，必须携带上级代理用户关系（功能梳理：找上级商品时，必须携带上级用户 id,上级商品 ID）
4. 店铺详情增加信誉分过低店铺不可用逻辑
5. 确认： 库存量 商品列表中库存使用同步库存（用于告警查询）；代理商品列表中库存剩余量 使用库存表计算库存（准确库存）、已售出库存使用订单中售出量（此数据需要受时效性影响 商户 最大 14 天）。代理商品一旦被删除到回收站，则不可被恢复，因为一旦删除，商品的代理关系将需要被删除，这样才可以允许重新接入。但是要保留回收数据，用于订单等关联查询。
6. 移除 商品的 inventory_notify_type 库存预警通知方式选项，梳理要求：站内信必开，然后还要发送商户可能设置的 webhook 通知 ⭐ 待办项 通知

2025-11-7 9H

1. 为商品编辑中 代理等级价格可单独关闭 功能梳理：图要求，先对接，上级设置价格后在来编辑代理商品 -> 新需求 -> 添加 代理等级价格可自由在商品中开关。 变动：当代理等级删除时，删除代理等级时会自动下架所有下级商品，代理商品下架（不移除代理关系，方便变更转换） 当代理等级变动时，变更每个直属代理商品的代理关系，下架三级代理的商品
2. 三级代理部分功能重构；部分敏感数据使用事务；三级商品数据查询部分更新，如列表从订单表查销售卡密量；功能梳理：
3. 代理分销-我的上级列表 -新增 按上级用户 id 查看可被代理的商品方法以及在抽屉列表的快捷对接
4. 移除 对接码对接时必须使用对接码：逻辑更改为 先成为其代理，在通过商品 ID 对接；抽离代理商品价格方法;可对接商品列表功能变更

2025-11-6 14H

1. 制作 thinkorm SQL 监听 为 sql 索引做准备 （⭐ 售后阶段待办项：数据表索引）

2. 商户提现、用户提现 、后台提现用户类型 提现类型、定额提现任务（备注：php webman auto:cash_ration 每隔 10 分钟执行一次，每日不限制次数、提现手续费跟随手动提现手续费设置；）；绑定收款/提现 二级密码是否存在及是否正确的验证；商户默认手动提现；

3. 标准确认：后端关于资金类的计算统一使用 小数点后三位。前端展示时请使用四舍五入取小数点后两位（即用户看到的是精确到分）

4. jwt 加密方式确定为双向对称加密：传客户的 token 过来后解析验证，成为商户后，获取新的商户 token（另外设计要求 playload 中 使用 sub 作为用户 id，username 作为商户名）

5. 信誉分使用规则 扣分至低于 80 关闭货源大厅且下架货源大厅商品 功能梳理：信誉分 >= 80 且 开通货源大厅，才显示货源大厅（核销邀请码时 符合的开通） 信誉分 低于 70 ，货源名片配置 代理等级和代理等级对接码功能列表不可用 及取消其货源对接功能（扣分至低于 70 时自动下架其所有下级商品 - 需要关联变动项 商品上架 版本 4） 信誉分 低于 60， 下单时 无法被下单

   ⭐ 待办项： 周 月 重计加分项 - 如果满足条件会一直加下去 - 需要梳理逻辑做成：上个周期内如果有扣分，则做减法运算？有没有最高分 100，会超过 100

6. 信誉分日志记录接口

7. 重新规划总后台 用户列表 商户和用户放在统一列表中使用

8. 下级代理订单

9. 风控 买家黑名单

10. 风控管理功能梳理： 查询代理近期销售 -> 下级代理订单 ✔ 查询用户最近消费 统计搜索时的总消费 ✔ 待办项 分销黑名单管理 -> 分销代理-我的代理 拒绝 （但只能拒绝直属代理）（✔） 用户黑名单管理 -> 下单黑名单 ✔

2025-11-5 12H

1. 投诉与售后功能 版 1
2. 设计思路出错，多级代理时 无法准确定位下级代理订单列表。开始重构
3. 用户端 收款方式设置
4. 用户端和商户端 cash 所有方法抽离合并
5. 重构对接，梳理商品表 订单表 投诉表 使用三级代理
6. 制作交易概览看板数据接口，增长概览数据看板
7. 后台 买家列表管理
8. 店铺收藏和商品收藏用户端演示（暂不具备点击跳转，仅支持查看收藏信息）

2025-11-4 9H

1. 商户推广 商户推广注册店铺，返佣逻辑，推广关系，返佣日志（使用资金明细中关于返佣的标识），功能梳理，此功能自己开关，并关联到推广页面，友好的展示可能受益的资金。
2. 开通店铺时 允许传入店铺名+推广 ID（演示站使用本地存入推广 id），功能梳理，应该根据后台设置 自由的显示是否有邀请框/使用静默的本地缓存仓。
3. 商家推广功能 佣金从交易手续费里抽成，后台可控功能开关（每笔交易 永久分成）
4. 冻结商品订单时 冻结所有层级及推广收益

2025-11-3 11H

1. 商品编辑功能：货源大厅价格变动、代理状态变动、代理等级价格变动等所有受到影响的 对下级的商品进行下架，并支持精准的某个代理等级的价格变动且下级上架的商品通知和对其下架
2. 商品删除功能：Redis 队列下架所有被代理的状态可用的商品链路
3. 商品上下架：检测是否绑定了分类，成本价对比，代理关系对比，商品被冻结检测，链路下架
4. 库存同步，添加、删除、出货、批量导出时删除。【※售后时库存同步待办】
5. 库存告警商品列表
6. 货源名片所有逻辑二次确认，新增刷新点购买价格，完成每日刷新计算
7. 商品上架时，如果是对接码代理，需要检测上级的设置的代理等级是否还存在以及是否已经被关闭
8. 代理商品 同步限购 内容 售卡顺序逻辑；代理商品的代理逻辑与自有商品的上下架 价格逻辑抽里，严格区分代理商品类型是大厅还是对接码；代理商品严格检测货源大厅价格 和每一项代理等级的价格、双向计算新旧价格组
9. 强制删除代理等级（会删除 代理等级对应的对接码、删除商品对接关系，删除代理等级设置过的商品价格，设置代理关系为拒绝-因为此时已经不存在这个代理等级）
10. api 请求域名 及 静态资源绝对路径返回
11. 查询订单使用订单号查询当前用户订单（功能梳理，下单产生时输出的是订单号，用户订单中心中继续用订单号查询，保持一致性）
12. 充值订单超时配置 超时逻辑;
13. 对接订单不支持查看卡密
14. 万能第三方短网址功能，使用 json 配置

2025-11-1 -> 2 2H

统计所有 sql

私事休息

2025-10-31 6H

• 2025-10-31 周五

  • 需要提交 git
  • ⭐ 核心 分佣
    1. 上级的收益即本级的成本价
    2. 源商品的成本价是为了方便统计，真实收益是给下级的成本价
    3. 每层的收益都应该被冻结
    4. 每层的收益都应该有日志
    5. 每层的收益都应该有被统计
    6. 每层商品代理的关系 应统计（给上级的） 卡密销售总数 总销售额 利润
    7. 每层的代理关系 应统计订单数（其余的资金类的可以用 6 相加）

• sql 表及含义统计，为资料定时清理准备

admin_log 系统操作日志表

admin_menu 用户快捷菜单

admin_roles 管理员角色

admin_role_relation 管理员角色表

admin_user 管理员表

agent_bind_code 对接码表（对应代理等级）

agent_level 代理等级表（会员等级）

agent_relation 代理关系表（无限层级）

article 文章表

article_category 文章栏目表

auto_unfreeze 订单金额 T+1 日自动解冻表

channel 支付网关

channel_account

email_accounts

email_logs

goods 商品表

goods_agent_price 商品代理价格表

goods_agent_relation 代理商品对接关系表

goods_card 商品卡号卡密表

goods_category 商品栏目表

link 产品相关短链接关系表

order 订单表

order_blacklist

order_card 订单取卡表

order_complaint 订单投诉表

order_complaint_message 投诉会话信息

order_master 订单网关表

pay_type 支付类型表

shop_extension 店铺扩展配置表

shop_list 商户资料表

shop_sales_statistics 销量统计表

suggest 意见反馈表

system_config 系统参数配置

system_diy 自定义模板配置表

system_hall_card 系统货源名片配置

system_hall_code 货源大厅邀请码

system_menu

system_uploads 预留·附件表

user

user_analysis 商户资金分析表

user_cash 用户提现表

user_collect 商户结算信息表

user_favorite 买家收藏关注表

user_hall 货源大厅商家名片表

user_log 商户操作日志表

user_login_log 登录日志

user_menu 用户快捷菜单

user_message 站内消息表

user_money_log 资金日志

user_recharge_order 商户充值订单表

user_risk 商户风控记录表

user_role 商户角色表

user_role_relation 商户角色关联表

2025-10-30 12

• 重构商品变更状态流程

  • 当上级商品未上架时，下级一定不可自己上架。只要保障下架的时候 整个链路下架即可。可大幅度降低逻辑。
  • 商品通过链路下架后，购买商品时只需要检测自己的商品状态即可。
  • 对接商品时 拿货价统一从（货源对接关系表 goods_agent_relation）中获取，不再经过代理等级（货源价格表 goods_agent_price）。
    • 前提：要保障（以后的 goods_agent_relation 总是最新）-制作中
  • 风险点-买家-下货-价格已经计算完毕-此时商品更新了价格-价格统计各种链路将有被攻破风险 🙅‍（需要只要一旦更改了代理关系 商品代理关系变更，就让商品下架 不可继续余额支付 √）

• 商户充值、用户充值

• 商户提现、用户提现

• 提现任务

• 前台页面（所有）基础版本

• 时间字段创建统一到各个模型

  ====== 要求标识统一 user_type 1 商户 2 买家

2025-10-29 13

• 检测商品链路状态（防止中间代理层不存在）✔

• 商品变更状态时 ✔

• 测试环境部署，演示账号到商户账号的申请页面（需要关联角色、自动生成店铺）

• 测试下单，制作分佣流程，制作资金日志

• 功能梳理：用户账号到商户账号属于同一个账号，相关记录应该关联，并使用 user_type 做区分（从 20251026 日已确定此开发思路）。所有相同功能应做统一抽离【重点】

---

⭐ 核心 下单流程梳理：

1. 用户输入数量 和 商品 id 下单
2. 检测用户下单权限
   • 2.1 检测黑名单配置
   • 2.2 检测商家状态
   • 2.3 检测商家店铺歇业 冻结状态
3. 检测商品源库存
   • 3.1 检测下单库存
4. 检测商品链路状态（防止中间代理层不存在）【todo 集成】【x 取消】
5. 检测买家余额
6. 统计原始单价 最终单价 最终成交价 购买数量 下单时间 手续费 订单自动关闭时间

---

⭐ 核心 商品下架功能

1. 商品修改价格时
2. 商品变更状态时
3. 商品代理价格修改时
4. 已存在的代理 代理状态被拒绝时
5. 应该会被应该当前商品下的所有的无限级代理的商品

---

2025-10-28 12

• 货源大厅：后台大厅邀请码 商户货源大厅 商户大厅名片 名片分类 购买 刷新等 所有内容

• 清理原始数据，植入演示测试账号环境。制作清理数据脚本

• 开始下单流程
  ===== 已完成：货源大厅、代理关系、代理等级、商品代理关系、商品代理价格关系、对接码、对接名片 我的代理 我代理的商品 我的上级代理等功能已完成 ======

  c. 待办

7. 我的订单 确认

   a. 订单完成方法 用户余额扣款前加锁，防止并发未减余额。

   b. 我的订单 按用户名搜索用户购买信息；增加买家用户 ID。移除不必要的关联模型展示；增加时效性

   c. 推广：返佣明细从资金日志中获取并增加时效性；邀请记录列表不在使用时效性(永久关系，除非上级账号删除)；推广统计数据使用资金冻结模型记录并增加时效性

8. 货源分销

   a. soure（source）拼写错误造成的 bug->代理价格变动时未及时下架->用户下单提交 45->代理分佣 5->上级分佣 50->源分佣->25,45 < 15+50+25 严重漏洞修复。（梳理：只要变动价格，下级必然下架。用户确认支付时，必检查商品状态）

9. 货源大厅

   a. 货源名片签到日志数据->日历展示;取消名片与系统名片关联，使用 card_level 表示当前名片等级用于快速排序(梳理:后台增加名片等级后-一旦被使用，不可更改与删除。建议提前做好规划)

   b. 货源名片排序功能更新,准确的信誉分值, 货源名片是否为优质商家标识

   c. 拆分购买邀请码功能，更新邀请码功能列表（添加状态 0:可售 1:已售 2:已使用 用于各种记录计算）；增加我已经购买过的接口。更新总后台邀请码页面。

10. 钱包 整理完成

    a. 缺失补全：运营钱包支出明细，可使用 merchantapi/wallet/platform/log ( business_type = 'deposit_money'，signed = 0) ，signed 含义 - 0 为负数 1 为正数

    b. 功能补全： 待解冻订单 -> 使用待解冻列表（功能梳理：剖析商户可能需要知道这笔订单是否已经解冻，订单因被投诉被冻结等）

    c. 提现记录 增加时效性

    d. 充值记录 增加时效性

    e. 资金日志列表 增加时效性

    f. 冻结资金列表 增加时效性

11. 售后 更新中

    a. 并放到订单菜单中查看 （功能梳理：仅商品源用户和商品直售用户显示，如果存在中间层代理 不扣分 也 不记录在下级投诉中，因为中间层不参与扣分和投诉问答及投诉处理）

    b. 增加列表数据 时效性

    c. 合并自己的订单投诉和下级代理的订单投诉为统一接口 统一列表。

    d. 增加 平台判定时 买家责任逻辑；商户责任时的 信誉分扣除逻辑

12. 个人中心

    a. 注册时间，使用开通店铺的时间

    b. 二级密码：首次设置时不需要邮箱验证。更改时需要邮箱验证码的验证，并判断是否已经绑定了邮箱

    c. 消息列表 增加时效性

13. 用户下单确认

    a. 检查商品状态（检查商品状态、店铺、卖家状态）

14. 总后台 a. 订单列表：展示平台收益 变更为 减去被推广分走的平台收益后的最终利润

15. 全部检查：商品删除时，影响到的列表的调用情况，并使用 null 合并运算，及模型默认值处理。

16. 用户端

a. 更新店铺演示页面, 为手机端

b. 添加收藏店铺和收藏商品的原始属性数据

c. 显示下单的手续费

d. 完善资金账单：资金日志、 用户充值记录列表、

e. 订单投诉页面：参考淘宝投诉设计，平台 24 小时后按需介入。增加 投诉时展示卡密信息。

f. 订单撤诉时，资金冻结时间恢复至冻结时间+24 小时；接口返回数据字段处理，隐藏不必要的字段

2025-11-11 9H 周二

1. 售后二版
2. 开始按原型脑图制定菜单及整理代码
3. 数据概览、交易概览、增长概览
4. 待解冻列表
5. 代码整理。。。

2025-11-9 10H 周一

1. 商品订单退款时的各种计算 验证通过 = 销售统计通过。移除待办项 商品订单退款。只需展示即得收益

2. 检查修正 拒绝下级代理的逻辑不通过。原因： 三级可能还正常代理了上级的自有商品 应该查所有代理商品 然后从商品循环下架

3. 完成 买家黑名单功能

4. 生成店铺时 自动生成信誉分资料

5. merchantapi/distribution/agentrelation/myagentlist 不可操作三级代理 应该给出标识 ✔

6. ⭐ 待办 探查后期是否需要直接在商品代理关系表中记录相关的销售记录 2025-11-13 取消待办：我代理的商品中，不在显示出售的卡密数量(没有啥意义，收益才是要关心的)；订单量按订单模型走；收益按冻结模型走；粗略整体销售收益按商户收益分析模型走。

7. 梳理功能：商户店铺信誉分 周 月 重计加分项 - 如果订单评优已经够 10 分了，然后如果在历史周期内（比如上周不达标，周不达标 月必然不达标）存在扣分，则把 10 分额外分 2/5 分，直至扣完这 10 分(其中订单量不够，不扣分) ⭐ 但是逻辑依旧不太对，比如月不够 2 周为 4，月扣 5 则又没了 thinking

8. 所有解冻流程：自动解冻表数据 状态更新为 2 表示已经解冻操作过。此数据表不在做删除行处理，只在平台定时（⭐ 待办 40 天）清理数据时清理2025-11-13 后要求不删除，用于记录订单收益关系

2025-11-9 9H 周日

1. 代码整理。。。
2. 收益统计；订单删除时删除对应的用户收益统计（注意，不删除资金冻结关系）
3. 商品订单退款时的各种计算，最终目的结果：商家余额已扣除,买家退款已原路退回
4. 取消待办 分销黑名单 -》它的功能指向 拒绝直属下级代理

2025-11-8 6H 周六

1. 增加 用户扩展配置模型 用于存储用户可自由修改的项目 用于数据外放 数据时效性 等不需要随用户生成的信息
2. 代理商品编辑中，检测是否是三级代理，是则需要不可被继续设置代理 can_proxy = 0
3. ⭐ 待办项 考虑一种逻辑，当一个商家 从不同的上家代理了同一个源头商品，那么查询关系，必须携带上级代理用户关系（功能梳理：找上级商品时，必须携带上级用户 id,上级商品 ID）
4. 店铺详情增加信誉分过低店铺不可用逻辑
5. 确认： 库存量 商品列表中库存使用同步库存（用于告警查询）；代理商品列表中库存剩余量 使用库存表计算库存（准确库存）、已售出库存使用订单中售出量（此数据需要受时效性影响 商户 最大 14 天）。代理商品一旦被删除到回收站，则不可被恢复，因为一旦删除，商品的代理关系将需要被删除，这样才可以允许重新接入。但是要保留回收数据，用于订单等关联查询。
6. 移除 商品的 inventory_notify_type 库存预警通知方式选项，梳理要求：站内信必开，然后还要发送商户可能设置的 webhook 通知 ⭐ 待办项 通知

2025-11-7 9H

1. 为商品编辑中 代理等级价格可单独关闭 功能梳理：图要求，先对接，上级设置价格后在来编辑代理商品 -> 新需求 -> 添加 代理等级价格可自由在商品中开关。 变动：当代理等级删除时，删除代理等级时会自动下架所有下级商品，代理商品下架（不移除代理关系，方便变更转换） 当代理等级变动时，变更每个直属代理商品的代理关系，下架三级代理的商品
2. 三级代理部分功能重构；部分敏感数据使用事务；三级商品数据查询部分更新，如列表从订单表查销售卡密量；功能梳理：
3. 代理分销-我的上级列表 -新增 按上级用户 id 查看可被代理的商品方法以及在抽屉列表的快捷对接
4. 移除 对接码对接时必须使用对接码：逻辑更改为 先成为其代理，在通过商品 ID 对接；抽离代理商品价格方法;可对接商品列表功能变更

2025-11-6 14H

1. 制作 thinkorm SQL 监听 为 sql 索引做准备 （⭐ 售后阶段待办项：数据表索引）

2. 商户提现、用户提现 、后台提现用户类型 提现类型、定额提现任务（备注：php webman auto:cash_ration 每隔 10 分钟执行一次，每日不限制次数、提现手续费跟随手动提现手续费设置；）；绑定收款/提现 二级密码是否存在及是否正确的验证；商户默认手动提现；

3. 标准确认：后端关于资金类的计算统一使用 小数点后三位。前端展示时请使用四舍五入取小数点后两位（即用户看到的是精确到分）

4. jwt 加密方式确定为双向对称加密：传客户的 token 过来后解析验证，成为商户后，获取新的商户 token（另外设计要求 playload 中 使用 sub 作为用户 id，username 作为商户名）

5. 信誉分使用规则 扣分至低于 80 关闭货源大厅且下架货源大厅商品 功能梳理：信誉分 >= 80 且 开通货源大厅，才显示货源大厅（核销邀请码时 符合的开通） 信誉分 低于 70 ，货源名片配置 代理等级和代理等级对接码功能列表不可用 及取消其货源对接功能（扣分至低于 70 时自动下架其所有下级商品 - 需要关联变动项 商品上架 版本 4） 信誉分 低于 60， 下单时 无法被下单

   ⭐ 待办项： 周 月 重计加分项 - 如果满足条件会一直加下去 - 需要梳理逻辑做成：上个周期内如果有扣分，则做减法运算？有没有最高分 100，会超过 100

6. 信誉分日志记录接口

7. 重新规划总后台 用户列表 商户和用户放在统一列表中使用

8. 下级代理订单

9. 风控 买家黑名单

10. 风控管理功能梳理： 查询代理近期销售 -> 下级代理订单 ✔ 查询用户最近消费 统计搜索时的总消费 ✔ 待办项 分销黑名单管理 -> 分销代理-我的代理 拒绝 （但只能拒绝直属代理）（✔） 用户黑名单管理 -> 下单黑名单 ✔

2025-11-5 12H

1. 投诉与售后功能 版 1
2. 设计思路出错，多级代理时 无法准确定位下级代理订单列表。开始重构
3. 用户端 收款方式设置
4. 用户端和商户端 cash 所有方法抽离合并
5. 重构对接，梳理商品表 订单表 投诉表 使用三级代理
6. 制作交易概览看板数据接口，增长概览数据看板
7. 后台 买家列表管理
8. 店铺收藏和商品收藏用户端演示（暂不具备点击跳转，仅支持查看收藏信息）

2025-11-4 9H

1. 商户推广 商户推广注册店铺，返佣逻辑，推广关系，返佣日志（使用资金明细中关于返佣的标识），功能梳理，此功能自己开关，并关联到推广页面，友好的展示可能受益的资金。
2. 开通店铺时 允许传入店铺名+推广 ID（演示站使用本地存入推广 id），功能梳理，应该根据后台设置 自由的显示是否有邀请框/使用静默的本地缓存仓。
3. 商家推广功能 佣金从交易手续费里抽成，后台可控功能开关（每笔交易 永久分成）
4. 冻结商品订单时 冻结所有层级及推广收益

2025-11-3 11H

1. 商品编辑功能：货源大厅价格变动、代理状态变动、代理等级价格变动等所有受到影响的 对下级的商品进行下架，并支持精准的某个代理等级的价格变动且下级上架的商品通知和对其下架
2. 商品删除功能：Redis 队列下架所有被代理的状态可用的商品链路
3. 商品上下架：检测是否绑定了分类，成本价对比，代理关系对比，商品被冻结检测，链路下架
4. 库存同步，添加、删除、出货、批量导出时删除。【※售后时库存同步待办】
5. 库存告警商品列表
6. 货源名片所有逻辑二次确认，新增刷新点购买价格，完成每日刷新计算
7. 商品上架时，如果是对接码代理，需要检测上级的设置的代理等级是否还存在以及是否已经被关闭
8. 代理商品 同步限购 内容 售卡顺序逻辑；代理商品的代理逻辑与自有商品的上下架 价格逻辑抽里，严格区分代理商品类型是大厅还是对接码；代理商品严格检测货源大厅价格 和每一项代理等级的价格、双向计算新旧价格组
9. 强制删除代理等级（会删除 代理等级对应的对接码、删除商品对接关系，删除代理等级设置过的商品价格，设置代理关系为拒绝-因为此时已经不存在这个代理等级）
10. api 请求域名 及 静态资源绝对路径返回
11. 查询订单使用订单号查询当前用户订单（功能梳理，下单产生时输出的是订单号，用户订单中心中继续用订单号查询，保持一致性）
12. 充值订单超时配置 超时逻辑;
13. 对接订单不支持查看卡密
14. 万能第三方短网址功能，使用 json 配置

2025-11-1 -> 2 2H

统计所有 sql

私事休息

2025-10-31 6H

• 2025-10-31 周五

  • 需要提交 git
  • ⭐ 核心 分佣
    1. 上级的收益即本级的成本价
    2. 源商品的成本价是为了方便统计，真实收益是给下级的成本价
    3. 每层的收益都应该被冻结
    4. 每层的收益都应该有日志
    5. 每层的收益都应该有被统计
    6. 每层商品代理的关系 应统计（给上级的） 卡密销售总数 总销售额 利润
    7. 每层的代理关系 应统计订单数（其余的资金类的可以用 6 相加）

• sql 表及含义统计，为资料定时清理准备

2025-10-30 12

• 重构商品变更状态流程

  • 当上级商品未上架时，下级一定不可自己上架。只要保障下架的时候 整个链路下架即可。可大幅度降低逻辑。
  • 商品通过链路下架后，购买商品时只需要检测自己的商品状态即可。
  • 对接商品时 拿货价统一从（货源对接关系表 goods_agent_relation）中获取，不再经过代理等级（货源价格表 goods_agent_price）。
    • 前提：要保障（以后的 goods_agent_relation 总是最新）-制作中
  • 风险点-买家-下货-价格已经计算完毕-此时商品更新了价格-价格统计各种链路将有被攻破风险 🙅‍（需要只要一旦更改了代理关系 商品代理关系变更，就让商品下架 不可继续余额支付 √）

• 商户充值、用户充值

• 商户提现、用户提现

• 提现任务

• 前台页面（所有）基础版本

• 时间字段创建统一到各个模型

  ====== 要求标识统一 user_type 1 商户 2 买家

2025-10-29 13

• 检测商品链路状态（防止中间代理层不存在）✔

• 商品变更状态时 ✔

• 测试环境部署，演示账号到商户账号的申请页面（需要关联角色、自动生成店铺）

• 测试下单，制作分佣流程，制作资金日志

• 功能梳理：用户账号到商户账号属于同一个账号，相关记录应该关联，并使用 user_type 做区分（从 20251026 日已确定此开发思路）。所有相同功能应做统一抽离【重点】

---

⭐ 核心 下单流程梳理：

1. 用户输入数量 和 商品 id 下单
2. 检测用户下单权限
   • 2.1 检测黑名单配置
   • 2.2 检测商家状态
   • 2.3 检测商家店铺歇业 冻结状态
3. 检测商品源库存
   • 3.1 检测下单库存
4. 检测商品链路状态（防止中间代理层不存在）【todo 集成】【x 取消】
5. 检测买家余额
6. 统计原始单价 最终单价 最终成交价 购买数量 下单时间 手续费 订单自动关闭时间

---

⭐ 核心 商品下架功能

1. 商品修改价格时
2. 商品变更状态时
3. 商品代理价格修改时
4. 已存在的代理 代理状态被拒绝时
5. 应该会被应该当前商品下的所有的无限级代理的商品

---

2025-10-28 12

• 货源大厅：后台大厅邀请码 商户货源大厅 商户大厅名片 名片分类 购买 刷新等 所有内容
• 清理原始数据，植入演示测试账号环境。制作清理数据脚本
• 开始下单流程
  ===== 已完成：货源大厅、代理关系、代理等级、商品代理关系、商品代理价格关系、对接码、对接名片 我的代理 我代理的商品 我的上级代理等功能已完成 ======
  ===== 未完成：货源大厅、代理关系、代理等级、商品代理关系、商品代理价格关系、对接码 功能校验，1. 被删除时后续链路的关键问题 2.销售数据统计到代理关系中（需 下单 分佣功能完善后 来做此未完成内容）======

---

2025-10-27 10

• 代理关系表 agent_relation
  • 新增字段 can_proxy 是否允许下级代理 1 允许 0 不允许（代理关系不存对接码，与对接码解耦，需要存 can_proxy）
  • 商品服务类
  • 库存服务类
  • 货源大厅后端

---

2025-10-26 8

• 代理等级、对接
• 重构 搜索码 三级代理
• 我的上级列表
• 功能继续梳理
  • 通过对接码搜索 上级，搜到后
  • 可能已经对接 但对接码跟已经对接的对接码等级不同 需要一个更换等级的功能
  • 如果上级操作过这个代理成了 状态-1 还得提示友好
  • 还有可能没有对接关系 需要申请，申请的方法 becomeAgentByBindCode 方法
  • 上级可用的商品列表 goodsListByBindCode

---

2025-10-25 10

• 库存查询，商户自定义快捷菜单
• 搜索码 三级代理基础构架
• 核心表及核心字段
• 关键表结构

1. 代理等级表: agent_level ✔
2. 对接码表: agent_bind_code
   • agent_level_id 对应代理等级 id
   • can_proxy 是否允许下级代理 1 允许 0 不允许
3. 代理关系表: agent_relation
   • parent_id 上级用户 id
   • user_id 代理用户 id
   • top_user_id 总属于用户 id
   • agent_level_id 对应代理等级 id
   • status 状态：0=待审核，1=已通过，-1=已拒绝
   • apply_time 申请时间
   • audit_time 审核时间
   • source 代理类型 代理类型：1 对接码代理，2 货源大厅代理
   • can_proxy 是否允许下级代理 1 允许 0 不允许（代理关系不存对接码，与对接码解耦，需要存 can_proxy）
4. 货源价格表: goods_agent_price
   • user_id 商家 id
   • goods_id 商品 id
   • agent_level_id 对应代理等级 id
   • agent_price 价格
5. 货源对接关系表: goods_agent_relation
   • relation_id 代理关系表 ID
   • source_user_id 顶级商家 id
   • parent_user_id 对接上家商家 id
   • agent_user_id 对接者商家 id
   • source_goods_id 顶级货源商品 id
   • parent_goods_id 上家商家商品 id
   • agent_goods_id 对接者商品 id
   • source 代理类型 代理类型：1 对接码代理，2 货源大厅代理 20251030 增加
   • status 对接状态 20251030 移除

---

2025-10-24 11

• 基础架构：选型确认，表结构，基础模型
• 功能：消息通知分类，商品相关，用户相关，店铺相关，充值，前端基础演示，库存监控(数据版)
• todo 多级商品收益，库存获取
  （所有功能可能会被推倒重构，请暂时不要使用目前接口和演示站做页面）

---