召回演练里最容易被问住的环节，往往不是找不到批次，而是找到了却说不清它为什么变成现在这个状态。批次记录显示已冻结，系统里却只留下最后一次修改时间；监管数据上传失败过几轮，也没人记得是谁重试的。追溯链在这里断掉的不是数据本身，而是数据背后的操作责任。审计日志在医疗器械追溯系统里承担的正是这件事：它不是运维附属品，而是追溯闭环的一部分。
先想清楚要回答什么问题
审计日志的设计起点不该是“能记多少”，而是“出了事要查清什么”。典型的追问有三类：谁改动过这条与特定 DI/PI 关联的记录；扫码核验时系统给出了什么判断，通过、拦截还是异常提示；监管数据上传失败后重试了几次、由谁处理。
这决定了记录的最小单元。每一次批次状态流转、多级经销商收货确认、权限变更，都应留下操作主体、时间、操作类型和变更前后的值。只保留登录日志和访问地址，形式上有了日志，实际核查时仍然一片空白。
不可篡改与查询性能的取舍
日志要能作为核查依据，前提是业务账号改不动它。通常的做法是只追加、不提供编辑入口，并对关键操作记录做校验或定期归档。
代价是日志体量增长很快。扫码核验属于高频动作，如果每次都写入完整快照，追溯主链路的查询会明显变慢。比较务实的做法是分级：涉及批次状态、权限、监管上传的关键操作记录完整的变更前后值，纯查询类操作只留摘要。这个分级规则本身也要写进设计文档，否则后期没人敢动。
几个常见的设计缺口
- 日志与权限模型脱节。记录了操作人，却没有记录其角色和当时的数据范围，出问题时无法判断这次操作是否越权。
- 没有为对账留字段。监管上传的重试记录如果只写“成功/失败”，后续无法定位是哪批数据需要重新核对。
- 把合规当成前端页面。隐私声明替代不了操作留痕，权限隔离和日志必须在底层设计，上线后再补等于二次改造。
从预算结构看也印证了这一点：审计日志通常被归入基础底座，小型轻量版本往往只做到登录留痕，要覆盖多角色权限与完整操作审计，基本要到标准追溯档位。这个分界并非报价话术，而是工作量真实分布的结果。
判断一个方案是否认真处理过审计日志，有个简单的问法：请对方说明某个批次被冻结过几次、每次由谁操作、依据是什么。能立刻给出字段结构和查询路径的，通常是从底层设计过的；只能描述界面上有个“操作记录”页签的，大概率和合规要求还有距离。
