## 结论与遗漏点 - 当前事务级联已覆盖核心链路,但仍有以下遗漏按业务应清理: - 删除用户: - 订单子表:`order_items.order_id IN(用户订单ID)`(模型:`internal/repository/mysql/model/order_items.gen.go:17`) - 支付流水:`payment_preorders/order_id`、`payment_transactions/order_id`、`payment_refunds/order_id`(模型:`payment_preorders.gen.go:16`、`payment_transactions.gen.go:16`、`payment_refunds.gen.go:16`) - 邀请关系:`user_invites.inviter_id = 用户ID OR invitee_id = 用户ID`(模型:`user_invites.gen.go:18,19`) - 资产转赠流水:`user_inventory_transfers.from_user_id = 用户ID OR to_user_id = 用户ID`,以及通过 `inventory_id` 引用用户资产(模型:`user_inventory_transfers.gen.go:17-19`) - 删除活动: - 发货记录(与资产关联):`shipping_records.inventory_id IN(活动产生的 user_inventory.id)`(模型:`shipping_records.gen.go:21`) - 资产转赠流水:`user_inventory_transfers.inventory_id IN(活动产生的 user_inventory.id)` - 删除期: - 可选(视运营策略):删除与该期绑定的系统道具模板 `system_item_cards.issue_id = 期ID`(模型:`system_item_cards.gen.go:24`)。若模板为系统公共配置且希望保留,请跳过。 ## 改造方案 - 用户级联(`internal/service/user/batch_user.go:32`) 1) 查出该用户的订单ID集合 → 删除 `order_items` 按 `order_id IN (...)` 2) 按订单ID集合删除:`payment_preorders`、`payment_transactions`、`payment_refunds` 3) 删除邀请关系:`user_invites` 按 `inviter_id = userID OR invitee_id = userID` 4) 删除资产转赠:`user_inventory_transfers` 按 `from_user_id = userID OR to_user_id = userID`;并按用户资产ID集合删除 `inventory_id IN (...)` - 活动级联(`internal/service/activity/activity_delete.go:8-106`) 1) 查出活动对应 `user_inventory.id` 集合 2) 删除发货记录:`shipping_records.inventory_id IN (...)` 3) 删除资产转赠流水:`user_inventory_transfers.inventory_id IN (...)` - 期级联(`internal/service/activity/issue_delete.go:8-55`) - 可选:删除 `system_item_cards` 按 `issue_id = 期ID`(若模板为期专用且不保留) ## 技术细节 - 顺序:先删子表(items、支付、转赠、发货)→ 再删主表(orders/users/activities/issues) - 性能:大表采用分批删除(如 5000/批);所有条件列均为主/索引列(`user_id`、`order_id`、`inventory_id`)以保证扫描性能 - 幂等:条件删除无记录时不报错;重复执行安全 ## 验收标准 - 删除用户后,不残留该用户的订单行、支付流水、邀请关系、资产转赠流水、发货及统计(统计表可保留) - 删除活动后,不残留与该活动资产相关的发货记录与资产转赠流水 - 删除期后(若启用模板清理),不残留该期范围的系统卡模板 - 编译通过,现有接口行为不变(仅增强删除逻辑);事务全链路失败回滚 ## 执行计划 - 补充三处服务方法的事务删除步骤,并针对大数据量路径加分批删除;完成后编译验证和快速自测(构造少量数据路径)。 请确认是否按上述方案继续,我将直接补齐代码并完成验证。