邹方成
45815bfb7d
refactor(utils): 修复密码哈希比较逻辑错误 feat(user): 新增按状态筛选优惠券接口 docs: 添加虚拟发货与任务中心相关文档 fix(wechat): 修正Code2Session上下文传递问题 test: 补充订单折扣与积分转换测试用例 build: 更新配置文件与构建脚本 style: 清理多余的空行与注释
43 lines
2.7 KiB
Markdown
43 lines
2.7 KiB
Markdown
## 结论
|
||
- 维度划分合理：订单（交易）、资产（所有权/履约对象）、发货（履约动作）三层分离是正确的。
|
||
- 现有实现可用：以`shipping_records`为事实表、按`express_no`聚合视图满足“合并/单独发货”两种场景，无需新增表即可运营落地。
|
||
- 建议的优化为“增强清晰度与可观测性”，而非重构模型。
|
||
|
||
## 建议优化（增量）
|
||
1) 状态清晰化
|
||
- 资产侧：保留`status=1/2/3`，但增加标准枚举映射，前端显示区分“已申请发货”与“已发货/已签收”：
|
||
- 用`shipping_records`最新状态驱动用户展示，不再仅依赖`user_inventory.status=3`。
|
||
- 代码层增加统一函数：`getAssetShippingState(inventoryID)` 返回`pending/created/shipped/received/error`。
|
||
|
||
2) 聚合与索引
|
||
- 为`shipping_records`增加索引：`(user_id, express_no, updated_at)`，提高“我的包裹”列表性能。
|
||
- 用服务层统一聚合（已实现），前端仅透传即可。
|
||
|
||
3) 幂等与风控
|
||
- 批量申请：用户重复点击同一资产时，严格走“幂等跳过”，并返回`already_requested`原因（已实现）。
|
||
- 运营合单：以`express_no`为聚合键，禁止重复写同资产的多条“已发货”记录（服务层加轻量幂等校验）。
|
||
|
||
4) 可观测性
|
||
- 增加“发货事件”审计（可选）：在`shipping_records`写入时同步写一条事件日志（表或消息），便于监控到`status`变更。
|
||
- 统一状态过渡校验：禁止从`已签收`回退到`已发货`。
|
||
|
||
5) 接口一致性
|
||
- 用户侧视图：
|
||
- “按资产看”：`GET /users/{user_id}/inventory`（已有）
|
||
- “按包裹看”：`GET /users/{user_id}/shipments`（已加）
|
||
- 管理侧：订单详情已有`shipments`；如需批量落库合单，可新增“批量创建发货记录”接口（运营入口）。
|
||
|
||
6) 文档与约定
|
||
- 约定`express_no`为空表示未生成运单（待发货/自提）；聚合视图展示为独立项或标记“无运单”。
|
||
- 统一状态语义：
|
||
- `shipping_records.status`：1待发、2已发、3已签收、4异常（唯一事实源）
|
||
- `user_inventory.status`：1持有、3已使用/发货（生命周期标识），界面展示由`shipping_records`驱动。
|
||
|
||
## 是否需要重构
|
||
- 不需要新增“发货组表”，当前以`express_no`聚合足够（若后续需要更强约束可增加`shipment_group_id`，但先不做）。
|
||
- 重点是“统一从`shipping_records`取展示状态”，避免误用`user_inventory.status`作为最终发货状态。
|
||
|
||
## 交付建议（后续）
|
||
- 加索引与状态转换校验的增量 PR（无接口变化）。
|
||
- 可选新增运营批量发货落库接口（提升作业效率）。
|
||
- 补充用户侧包裹视图的文档与示例。 |