电商项目开发记录：把售后、投诉和商家入驻接进统一待办

今天主要在补电商平台管理端的治理业务。之前不少页面已经能看、能点但部分功能还停留在“展示数据”的阶段缺少后台定时检查、状态联动和数据持久化。所以今天没有继续堆新页面而是把售后、投诉和商家入驻这三块业务往完整流程上推进了一步。一、补全平台售后监管流程首先处理的是管理端售后监管。原来的售后业务主要集中在买家申请和商家处理平台端能够看到的数据比较有限。今天补上了平台售后列表、详情、处理记录和审计时间线并增加了几个实际操作平台介入售后催促商家处理关注重点售后查看售后状态变化查看管理员操作记录业务完成后自动关闭平台待办这些操作不再只是修改页面状态而是会把结果写入 Redis。管理员刷新页面或者重新登录后之前的操作记录仍然存在。售后审计记录按售后单独保存后续查看详情时可以按时间顺序还原整笔售后的处理过程。二、增加售后 SLA 超时预警平台能够查看售后还不够还需要主动发现长时间没人处理的售后。今天增加了一个后台 Worker每隔 5 分钟扫描一次售后数据并按照处理时间生成平台待办。目前使用的规则是待商家处理超过 24 小时生成超时待办待商家处理超过 48 小时升级为严重超时售后退款、拒绝或者处理完成自动关闭待办管理员可以在待办中心认领任务也可以释放自己认领的任务。认领之后页面会显示当前负责人和认领时间避免多名管理员重复处理同一笔售后。系统在生成或者升级预警时还会自动向管理员发送通知。三、投诉业务改成分阶段计时投诉和售后不太一样不能只从投诉创建时间开始一直计算。一笔投诉可能经历买家提交投诉平台受理商家提交说明和凭证平台作出裁决买家再次申诉如果所有阶段都按照同一个时间计算很容易出现误判。因此今天把投诉 SLA 改成了分阶段计时。目前的时间规则如下投诉阶段普通预警严重预警待平台受理4 小时12 小时再次申诉复核4 小时12 小时等待商家举证24 小时48 小时等待平台裁决12 小时24 小时投诉进入新阶段后会重新计算该阶段的处理时间。例如投诉已经被平台受理接下来应该等待商家举证那么系统就不会继续使用投诉提交时间而是从进入“等待商家举证”阶段的时间重新开始计算。等待商家举证超时后除了通知管理员也会通知对应商家及时处理。四、解决商家入驻审核时间不增长的问题商家入驻审核接入统一待办时遇到了一个比较隐蔽的问题。项目目前有一部分演示申请数据提交时间是这样生成的SubmittedUnix: time.Now().Add(-7 * time.Hour).Unix()这种写法在页面展示时看不出问题但后台每次重新扫描提交时间都会重新变成“当前时间减去 7 小时”。结果就是这条申请永远只提交了 7 小时无论系统运行多久都不会自然超过 8 小时的预警线。最后的处理方式是第一次扫描到未完成申请时把它的计时基准保存下来。ReferenceAt int64后续扫描即使演示数据重新生成也继续使用第一次保存的ReferenceAt不再覆盖。这样申请时间才能正常累计SLA 预警也能真正触发。商家入驻目前的规则是待初审超过 8 小时生成审核预警资质复核超过 12 小时生成审核预警任一阶段超过 24 小时升级为严重超时审核通过或者驳回立即关闭对应待办如果申请从待初审进入资质复核会重新开始计算新阶段的时间同时清除上一个阶段的认领人避免审核责任混乱。五、统一平台待办中心完成三类 SLA 后把它们统一接入了平台待办中心。目前待办中心包含售后时效投诉纠纷商家入驻管理员可以按照以下条件筛选处理中已认领待认领已自动关闭普通超时严重超时也可以搜索业务编号、订单号、商家名称、经营类目和投诉原因。每种待办都可以直接跳转到对应业务页面。例如商家入驻待办点击“前往审核”后会自动打开相应申请而不是让管理员再去申请列表里重新查找。这次也顺便调整了空状态判断。选择“商家入驻”标签时只判断当前入驻待办是否为空不会因为售后还有数据就导致当前页面的空状态不显示。六、数据持久化和运行验证这次新增的待办不是只保存在内存里而是统一写入 Redis。主要保存了业务编号当前处理阶段SLA 计时基准预警等级是否已经生成过预警首次发现时间关闭时间认领管理员认领时间这样服务重启后待办状态、认领关系和计时基准都不会丢失。为了避免重复生成待办后台每次扫描都会对比已有记录。状态和预警等级没有变化时不会重复写入通知。今天还补了相关测试主要检查了未超时申请只追踪、不生成预警动态演示时间不会覆盖固定计时基准达到预警时间后正常生成待办重复扫描不会重复生成升级严重超时时保留认领人审核完成后自动关闭进入新审核阶段后重新计时最后重新启动了前端服务并读取 Redis 检查 Worker 的真实运行情况。系统已经成功写入巡检时间也实际生成了一条商家入驻审核超时待办。七、今天的收获今天做的内容看起来主要是“待办”和“超时提醒”但真正麻烦的地方不是页面而是不同业务状态之间的联动。如果只做一个待办列表并不难难的是保证待办不会重复生成服务重启后计时不会丢失业务进入新阶段后重新计时处理完成后自动关闭严重等级升级时保留负责人前端展示和后端状态保持一致特别是商家入驻的动态时间问题如果只看页面很难发现。只有让 Worker 实际运行一段时间再检查 Redis 中的计时数据才能确认它真的在增长。下一步准备继续补充待办优先级、SLA 规则配置和管理员处理量统计让统一待办不仅能够提醒问题还能更合理地分配平台审核任务。