智能锁的开锁日志能保存多久，没有统一的年限答案，它取决于记录实际存在哪一侧——锁体本地、本地控制器，还是管理平台。可操作的做法是：日常查询走平台侧的集中记录，锁端只作断网期间的临时缓存；出问题时按「时间点 → 点位 → 人 → 交叉核对」的顺序回查，比盯着一个年限数字更有效。
记录存在哪里，直接决定能留多久
同一把锁的记录，可能落在三个不同位置，能力边界差别很大：
| 存储位置 | 留存特征 | 主要受什么限制 | 断网时 | 怎么查 |
|---|---|---|---|---|
| 锁体本地 | 只保留近期若干条，新的覆盖旧的 | 锁体存储空间与功耗预算 | 仍会记录 | 就近读取或联网后上传 |
| 本地控制器 / 网关 | 容量大于锁体，可按区域归集 | 设备存储与备份策略 | 区域内可查 | 管理端按区域查询 |
| 管理平台 | 集中保存，可跨点位检索 | 服务器存储与留存策略 | 期间存在数据缺口，恢复后补传 | 后台按条件筛选 |
结论：想知道「能存多久」，先问清记录落在哪一侧、有没有集中保存，比问一个年限数字更有意义。
留存周期由三个变量决定，不是一个固定年限
存储介质与容量。 平台侧磁盘、本地控制器闪存、锁体内部存储，容量差距明显，能容纳的记录条数自然不同。锁体一侧受功耗与空间约束，通常只做短期滚动记录。
记录粒度。 只记「开锁成功／失败」，还是把凭证类型、授权来源、连续失败尝试一起记下来。记得越细，单条占用越大，同样容量能留的时间越短。
管理与合规要求。 有的场景按内部管理需要留一个季度即可，有的要满足审计口径。留存周期一般在部署时按需求配置，不是出厂就写死的参数。
因此，「记录保存位置、留存周期、能否导出」这三项应当在采购与验收阶段就写进技术要求，而不是等出了问题再临时问。具体可保存周期以所选方案与实际部署配置为准。
出问题时的四步排查
先定时间窗。 明确是哪一天、哪个时间段发现异常，把范围收窄到小时级。范围越窄，越容易在大量记录里定位到目标条目。
再定点位。 同一栋楼门点很多，先锁定具体门点，避免跨点位混查。
再定人。 按账号或凭证筛选。这里要区分「授权给谁」与「实际谁在用」——卡片、钥匙扣可能被转借，记录只能指向凭证。
交叉核对。 把开锁记录与门状态、异常告警、临时授权的生效时间放在一起看。若某条记录正好落在授权到期前后，要重点核对时间基准是否准确。
查不到记录，通常是这四种情况
- 断网期间的记录还没回传。 开锁在本地完成，断网时记录先在本地留存，网络恢复后补传。刚发生的开门立刻去平台查，可能查不到。
- 已被新记录覆盖。 锁端本地存储是滚动写入的，超出容量后旧记录被顶掉。这是「锁端查不到、平台查得到」的常见原因。
- 查的是人，记的是凭证。 多人共用一张卡时，记录只能定位到凭证，定位不到具体的人。这也是建议一人一凭证的实际理由。
- 时间基准有偏差。 锁端与平台时钟不一致时，按时间筛选会漏掉目标记录，定期校时属于基础运维动作。
结论：日志的价值不在「有没有记」，而在「能不能对应到具体的人和时间」。前者是产品功能，后者靠授权设计与运维习惯。
常见问题
Q：NFC 无源锁没有电池，日志存在哪里？ A：锁体不内置电池，但开锁时由 NFC 设备反向供电，认证与开锁过程可以在这一次供电窗口内写入记录，联网或就近读取时上传到管理端。断网期间本地能留多少条，取决于具体型号与管理方案，以实际配置为准。
Q：日志能不能导出，给审计或物业对账用？ A：平台侧一般支持按条件筛选后导出，导出格式与权限分级由方案配置决定。建议在选型阶段就明确「谁能导出、导出包含哪些字段」。
Q：日志会不会被删改？ A：记录归属到账号、集中保存在平台侧，比人工登记本更难在事后修改；防篡改的实际强度取决于平台设计与权限管理，建议按方案确认是否具备操作留痕与权限分级。