电商系统的审计日志怎么设计？一次讲清谁改了什么、为什么改、出了问题怎么追

电商系统的审计日志怎么设计一次讲清谁改了什么、为什么改、出了问题怎么追大家好我是一名有 4 年工作经验的 Java 后端开发。在电商系统里很多线上问题最后都不是“功能没做”而是“出了问题找不到是谁改的、什么时候改的、改了什么”。这篇文章我想聊一聊电商系统里的审计日志到底怎么设计尤其是订单、商品、售后、价格、库存这些核心场景。个人主页文章目录电商系统的审计日志怎么设计一次讲清谁改了什么、为什么改、出了问题怎么追一、前言二、哪些场景必须做审计日志三、审计日志到底记什么四、数据库怎么设计五、快照到底要不要全量存核心高风险操作普通轻量操作六、落地代码怎么做6.1 最简单的做法业务代码里显式记录6.2 更推荐的做法统一审计服务七、最容易踩的坑7.1 只记“谁操作了”不记前后变化7.2 审计日志和业务事务不一致7.3 敏感字段不脱敏7.4 把普通访问日志和审计日志混在一起八、面试怎么回答九、总结十、结尾一、前言很多团队一开始做日志只关注接口日志异常日志SQL 日志但真正到了线上你会发现还有一类日志特别重要审计日志。比如这些问题谁把商品价格改了谁手工关闭了订单谁审核通过了退款谁把库存从 100 调成了 10平台客服为什么能看到这条订单财务为什么导出了一批敏感数据这些问题如果没有审计日志后面几乎只能靠猜。而电商系统又天然更需要审计因为它涉及钱货状态流转人工介入平台与商家多角色协作所以审计日志真正要解决的问题不是“打印点日志”而是把关键操作的时间、操作人、对象、前后变化、来源入口、理由都沉淀下来。二、哪些场景必须做审计日志我建议电商系统至少这些场景必须做商品价格修改商品上下架库存人工调整订单手工关闭订单发货售后审核人工退款优惠券规则修改角色权限修改导出敏感数据简单来说只要这个操作会影响钱、货、权限、状态、敏感数据就应该有审计日志。三、审计日志到底记什么我更建议按这 8 类信息记谁操作的操作了什么对象执行了什么动作动作前是什么动作后变成什么为什么这么做从哪里做的什么时候做的例如操作人merchant_admin_1001对象order_id90001动作MANUAL_CLOSE前状态PAID后状态CLOSED原因用户申请取消来源merchant后台-订单详情页时间2026-03-31 22:30:00四、数据库怎么设计建议单独建审计日志表而不是把它塞到通用业务表里。CREATETABLEaudit_log(idBIGINTPRIMARYKEYAUTO_INCREMENT,biz_typeVARCHAR(32)NOTNULL,biz_idBIGINTNOTNULL,actionVARCHAR(64)NOTNULL,operator_idBIGINTDEFAULTNULL,operator_typeVARCHAR(32)DEFAULTNULL,operator_nameVARCHAR(64)DEFAULTNULL,before_snapshot JSONDEFAULTNULL,after_snapshot JSONDEFAULTNULL,reasonVARCHAR(255)DEFAULTNULL,sourceVARCHAR(128)DEFAULTNULL,trace_idVARCHAR(64)DEFAULTNULL,created_atDATETIMENOTNULLDEFAULTCURRENT_TIMESTAMP,KEYidx_biz(biz_type,biz_id),KEYidx_operator(operator_id),KEYidx_created_at(created_at));这里的关键字段biz_type订单、商品、库存、售后biz_id业务对象 IDaction动作before_snapshot操作前快照after_snapshot操作后快照五、快照到底要不要全量存我建议这样区分核心高风险操作比如改价格改库存审核退款手工改订单状态建议存前后快照。普通轻量操作比如只是点开页面普通查询不一定要存快照可以只记行为日志。也就是说审计日志不是把一切都记全而是把高风险、高价值操作记清楚。六、落地代码怎么做6.1 最简单的做法业务代码里显式记录publicvoidmanualCloseOrder(LongorderId,LongoperatorId){OrderbeforeorderMapper.selectById(orderId);orderMapper.updateStatus(orderId,CLOSED);OrderafterorderMapper.selectById(orderId);AuditLoglognewAuditLog();log.setBizType(ORDER);log.setBizId(orderId);log.setAction(MANUAL_CLOSE);log.setOperatorId(operatorId);log.setOperatorType(MERCHANT_ADMIN);log.setBeforeSnapshot(JSON.toJSONString(before));log.setAfterSnapshot(JSON.toJSONString(after));log.setReason(用户协商取消);log.setSource(merchant-order-detail);auditLogMapper.insert(log);}优点是直观。缺点是容易散落在各处。6.2 更推荐的做法统一审计服务publicinterfaceAuditLogService{voidrecord(AuditRecordrecord);}然后业务里统一调用auditLogService.record(AuditRecord.builder().bizType(ORDER).bizId(orderId).action(MANUAL_CLOSE).operatorId(operatorId).operatorType(MERCHANT_ADMIN).beforeSnapshot(before).afterSnapshot(after).reason(用户协商取消).build());这样更适合大一点的项目。七、最容易踩的坑7.1 只记“谁操作了”不记前后变化后面排查时还是很痛苦。7.2 审计日志和业务事务不一致如果业务成功了日志没写进去价值会大打折扣。建议尽量和业务一起提交或者至少保证最终可靠落地。7.3 敏感字段不脱敏比如手机号地址身份信息如果直接全量存快照风险很大。7.4 把普通访问日志和审计日志混在一起审计日志更强调关键操作可追责可复盘不要和普通 access log 混着设计。八、面试怎么回答如果面试官问你电商系统的审计日志一般怎么设计你可以这样回答第一审计日志主要不是记录技术异常而是记录关键业务操作尤其是会影响钱、货、权限、状态和敏感数据的操作比如改价格、改库存、退款审核、人工关单、权限修改等。第二我一般会单独建审计日志表至少记录业务类型、业务对象 ID、动作、操作人、操作前后快照、原因、来源和时间。对于高风险操作建议记录前后快照方便后续排查和审计。第三审计日志最好和业务一起可靠落地至少不能出现业务改成功了但审计日志完全没留下的情况。第四敏感信息要考虑脱敏不是所有字段都应该原样记录。九、总结电商系统里的审计日志真正难的不是“记不记日志”而是记哪些操作记到什么粒度如何和业务事务一致如何兼顾排障价值和数据安全如果只记一句结论我觉得可以记住这句审计日志的核心不是打印日志而是把关键业务操作变成可追、可查、可复盘的事实记录。十、结尾如果你觉得这篇文章对你有帮助欢迎点赞、收藏、关注。后面我会继续整理一些更偏实战的 Java 后端和电商系统设计文章。