2026年8月20日，《网络数据安全风险评估办法》将正式施行。新规要求重要数据处理者每年开展风险评估，一般数据处理者至少每3年评估一次。IP地址早已被纳入个人信息保护法的监管范围。为了做地域分析而长期存储用户原始IP，这条路在现在的合规框架下已经行不通了。IP数据云离线库支持私有化部署，查询在本地完成，原始IP解析出归属地后立即丢弃，不留存、不落库。

一、合规红线：为什么“存IP做分析”行不通了？

1.1 个人信息保护法的“最小必要”原则

《个人信息保护法》明确要求，处理个人信息应当有明确、合理的目的，并且与处理目的直接相关，采取对个人权益影响最小的方式。收集个人信息也要限于实现处理目的的最小范围，不能过度收集。

“为了拿到国家码而长期存IP”是明显不必要的。如果业务只需要知道用户所在省份或城市来做地域分析，就没有理由存储完整的原始IP地址。

1.2 数据安全新规强化合规要求

2026年6月公布的数据安全新规要求，重要数据处理者须每年开展风险评估。到了实际审计阶段，IP查询日志的完整性、可追溯性和闭环性， 都会成为检查重点。

如果系统里保留了大量用户原始IP，却说不清楚存储目的、使用边界和合法性基础，这在合规审计里通常会被归到高风险项。

1.3 监管趋势：从“能存就存”到“能不留就不留”

这两年，监管关注点明显不只是“你存了什么”，而是“你为什么要存”“存多久”“有没有别的替代方式”。 能不留存的尽量不留存，能脱敏的尽量脱敏，这已经不是口号，而是在越来越多场景里变成默认要求。

二、技术方案：IP离线库实现“用完即弃”

2.1 核心思路

原始IP仅作为瞬时输入，解析出归属地后立即丢弃，不写入数据库、不进入日志。 整个过程在本地完成，不经过外部网络，不调用第三方在线API。

用户请求 → 获取IP → 本地离线库解析 → 输出省份/城市 → 存储脱敏结果 → 原始IP丢弃

2.2 为什么选离线库而不是在线API？

如果使用在线API，本质上意味着将用户IP数据传递给第三方，需要额外签署数据处理协议，合规评估复杂度直线上升。而离线库运行在自有环境中，数据控制边界非常清晰。

2.3 数据最小化的落地方式

在实际业务系统中，只保留业务必要的字段：

如果只是做IP属地展示，展示到省份或城市级别一般就够了，没有必要保留更细的信息。IP离线库方案正好适合这种做法：在本地把IP解析成国家、省份、城市，不存储原始IP，只存储脱敏后的属地信息。

三、实操落地：三步实现“存归属地、不留原始IP”

第一步：部署IP离线库

下载IP离线库文件（.mmdb格式），部署在应用服务器本地，启动时加载至内存。

import ipdatacloud# 加载IP数据云离线库（应用启动时加载一次，常驻内存）ip_db = ipdatacloud.OfflineIPLib('/data/ipdb/ip_data_cloud.mmdb')

第二步：封装查询函数——只输出归属地，不落库原始IP

def get_ip_location_only(ip: str) -> dict:"""获取IP归属地（仅返回省份/城市级别）不记录原始IP，只返回脱敏结果"""info = ip_db.query(ip)return {'province': info.get('province'),'city': info.get('city')}# 业务调用user_ip = request.remote_addrlocation = get_ip_location_only(user_ip)# 只存储脱敏后的归属地，原始IP不落库save_to_database({'user_id': user_id,'province': location['province'],'city': location['city']# 注意：没有存储原始IP})

关键点：原始IP只在请求生命周期内存在，解析完成后立即丢弃。

第三步：审计日志脱敏处理

如果因为合规审计需要记录查询行为，日志里也尽量只保留“查询时间、查询结果（省份/城市）”这类信息，而不是直接记录原始IP。确实需要保留识别能力时，也应优先考虑哈希处理后的结果，而不是明文留存。

四、总结

做地域分析不想存用户IP，这件事可以做到。IP离线库方案的核心价值在于：原始IP只作为瞬时输入，在本地解析出归属地后立即丢弃，不落库、不留痕。 业务系统只存储脱敏后的省份/城市信息，既满足了地域分析的需求，又符合“最小必要”的合规原则。

随着数据安全评估新规的实施，IP查询日志的合规审计将更加严格。与其被动应对，不如提前把“存什么、不存什么”的边界划清楚。