内容摘要：上周三凌晨两点，我盯着后台一条日志发愣。那条记录写着：“商品ID 88423，审核驳回，原因：主图含违禁词，执行操作：上架记录删除。”操作人是我自己。可我完全想不起来什么时候点过这个按钮。 这不是灵异

上周三凌晨两点，审核上架删除我盯着后台一条日志发愣。日志那条记录写着：“商品ID 88423，审核上架删除审核驳回，日志原因：主图含违禁词，审核上架删除执行操作：上架记录删除。日志”操作人是审核上架删除我自己。可我完全想不起来什么时候点过这个按钮。日志

这不是审核上架删除灵异事件。我们团队做电商中台，日志每天有近万条商品上下架。审核上架删除审核驳回后自动删除上架日志，日志是审核上架删除两年前为了“减轻数据库压力”加的逻辑。当时觉得挺聪明——驳回的日志商品本来就不该出现在前台，留着日志占空间。审核上架删除现在看，这逻辑埋了个雷。

被删掉的不是日志，是证据链

商家老周上个月找过来，说他的一款儿童保温杯被下架了，理由是“材质描述涉嫌虚假宣传”。他要求看审核记录。我查了后台，上架日志被删了，只剩一条孤零零的驳回通知。老周问：“谁审的？什么时候审的？之前上架时提交的质检报告还在不在？”我答不上来。日志删除后，审核人ID、时间戳、原始提交材料，全没了。

按说审核系统该留全量记录。但当初设计时，开发图省事，把“驳回”和“删除上架日志”绑成了一个事务。驳回即删除，删除即不可逆。数据库里连个软删除标记都没打。老周这事最后靠翻企业微信聊天记录才勉强还原，但那个月他店铺的流量已经掉了一半。

为什么当初会这么设计

我翻过旧文档。2021年那次改版，产品经理写了一句：“驳回商品无上架价值，日志同步清理可降低存储成本约12%。”12%这个数字怎么算出来的？没人知道。但存储成本真的那么要紧吗？我查了现在的数据量：上架日志表一共4.7亿行，每天新增30万行。就算不删，一年也就多1亿行。用云数据库，这点存储费不到两千块。

为了省两千块，把审核过程的完整轨迹抹掉了。这账算得不对。

更麻烦的是审核驳回本身可能出错

上个月有个案例。一款陶瓷刀被驳回，理由是“刀具类目需特殊资质”。商家申诉说这是厨房用具不是管制刀具。复核时发现，审核员把“陶瓷刀”误判成了“陶瓷工艺刀剑”。如果上架日志还在，能直接看到审核员当时勾选的类目路径。但日志删了，只能靠审核员回忆。他回忆了三天，才想起来是选错了二级类目。

这不是个例。我们内部统计过，审核驳回的申诉成功率大约7.3%。也就是说，每100个被驳回的商品里，有7个是误判。误判需要追溯，追溯需要日志。日志被删了，误判就变成了死案。

我现在改成了什么样

上个月我推了一个改动：驳回不再删除上架日志，改为标记状态为“已驳回-待归档”。归档周期设为180天。180天内，审核员、商家、平台运营都能查。180天后，日志转入冷存储，保留字段包括商品ID、审核人、驳回原因码、原始提交快照的哈希值。存储成本每月增加不到300块。

有人问，那旧日志呢？已经删了的找不回来。但新产生的日志从改动上线那天起，全留着了。老周那款保温杯的日志是去年删的，我帮他恢复了部分数据——从备份磁带里翻出来的，花了四天。他收到恢复文件时说了句：“早该这样。”

凌晨两点那条日志，后来查清楚了。是另一个同事用我的账号做了批量操作测试，测试完忘了退出。但这件事让我更确定：删除日志的按钮，不该和审核驳回绑在一起。审核驳回是业务动作，日志删除是数据管理动作。两个动作混在一起，出事只是时间问题。

现在后台的驳回按钮旁边，多了一行小字：“本次操作不会删除上架日志。”就这一行字，省了我很多半夜爬起来查日志的麻烦。