日志留多久，是一个你早就默认做完的隐私决定

去问一个小团队日志留多久，通常会得到两种回答之一：「平台默认」或者「一直留着，反正不大」。两个都是决定，而第二个是多数项目拥有过的、规模最大的一份未声明的个人数据收集。

一、一行日志里到底有什么

一条标准的访问日志包含：客户端 IP、时间戳、方法与路径、响应状态、字节数、referer，以及 User-Agent。这些在很多情况下足以定位到一个人，尤其是配合一个访客很少的站点：一个 IP 加一个时间点加一条路径，比一个名字更有识别力。

二、三个正当的保留理由

• 排查故障。14:32 出了事，你想看那条请求。这需要的是几天，不是几年，而且有用的部分通常是状态码、路径和时序，不是完整 IP。
• 滥用与容量。流量突增、抓站、撞库。多数情况下需要的是几周，因为模式只有拉长时间才显现。
• 法律义务。某些法域要求为特定目的保留连接数据一段最短时间。这是唯一能支撑一个固定下限的理由，而且它有附加条件。

这三个理由，没有一个需要你永久保留完整 IP。如果截断地址或者加盐哈希就能达到目的，那保留原始值是一个选择，不是必需。

三、在写入时最小化，而不是在删除时

任何日志管道里性价比最高的隐私改进都在入口处。去掉 IPv4 的最后一段、IPv6 的最后 80 位——城市级的排查能力保留，个体可识别性基本消失。如果确实需要串联会话，就用每月轮换一次的盐做哈希：当天的关联仍然成立，跨月就断了，而盐本身从不进入日志库。

不需要的查询串直接丢掉。典型访问日志里有一半个人数据在查询串里：URL 中的令牌、重置链接里的邮箱、搜索词。只记录路径模板而不是完整 URL，能去掉其中大部分，同时不失去排查路由的能力。

四、删除比看上去难

一个写着「保留 30 天」、但备份留了一年的策略，等于没有策略。如果日志落进了开了版本控制的对象存储，删除意味着连版本一起删。如果它们被导出到一张表里做面板，那份副本有自己的保留期。派生出来的聚合数据通常可以放心保留——每小时每路由的计数不是个人数据——这本身就是「建聚合，而不是留原始行」的好理由。

五、你到底能承诺什么

除非你亲眼看着一行数据消失，别写「我们保留 30 天日志」。挑一个你能用生命周期规则强制执行的窗口，查一次旧数据验证它确实没了，再把这个数字写进隐私政策。验证过的 14 天，好过一个美好愿望的 90 天。

同一套逻辑也适用于第三方：你的 CDN 和错误追踪服务也各留一份，按它们自己的周期。把「哪些服务商看到什么、看多久」写下来，因为那才是用户实际面对的保留期。

ipbox.one 不保留任何按访客归档的记录：唯一被存下来的值是一个约九十秒过期的限流计数器，隐私政策里也是这么写的——因为它可以被验证。