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