一句话导读
我们的站点涉及两类「个人信息处理」：私区认证（账号标识、会话令牌）与访问日志（IP、UA）。对照 PIPL 落地清单做一次自查，结论：核心合规已具备，三处细节待补。
我们的站点涉及两类「个人信息处理」：私区认证（账号标识、会话令牌）与访问日志（IP、UA）。对照 PIPL 落地清单做一次自查，结论：核心合规已具备，三处细节待补。
一、现状盘点（🟢 本机实测）
| 个人信息处理活动 | 现状 | 对照 PIPL 要求 |
|---|---|---|
| 私区认证（priv_token Cookie / auth_check） | 令牌认证 + 登录/注销/会话过期 | ✅ 告知 + 同意（登录行为本身即授权）+ 最小必要 |
| 访问日志（IP / UA / 请求） | Nginx access.log 留存 | 🟡 已收集但「留存期限 + 清理策略」未文档化 |
| homeZone Cookie | 记录公区/私区偏好 | 🟡 功能必要 Cookie，但未见明确告知 |
| 第三方服务（MCP / 搜索 API / 一次性分享外部域） | 接入多个外部服务 | 🟡 第三方清单未整理（处理什么、存哪） |
| 数据跨境 | 服务器在境内（轻量云），无境外传输声明 | ✅ 默认合规（若第三方 API 在境外需评估） |
二、经验教训
教训 1：合规不是「做到完美」，是「知道 + 告知 + 能响应」
早期觉得「小站没人看，不用管合规」。但 PIPL 不问大小，只问是否处理个人信息。正确姿势是：先盘点自己处理了什么（数据地图），再对照要求补齐。
早期觉得「小站没人看，不用管合规」。但 PIPL 不问大小，只问是否处理个人信息。正确姿势是：先盘点自己处理了什么（数据地图），再对照要求补齐。
教训 2：日志是「隐性个人信息」，最容易被忽略
IP/UA 也属于个人信息（可识别设备）。我们的 access.log 和 dsh 任务日志都含 IP——留存期限要定、定期清理要执行，这是当前最大缺口。
IP/UA 也属于个人信息（可识别设备）。我们的 access.log 和 dsh 任务日志都含 IP——留存期限要定、定期清理要执行，这是当前最大缺口。
教训 3：第三方依赖要「清单化」
接入越多外部服务，越容易失控。PIPL 要求对委托处理/第三方提供签协议并负责。我们的 MCP 服务、搜索 API 应该有一张「第三方清单」：谁、处理什么、数据流向哪。
接入越多外部服务，越容易失控。PIPL 要求对委托处理/第三方提供签协议并负责。我们的 MCP 服务、搜索 API 应该有一张「第三方清单」：谁、处理什么、数据流向哪。
三、行业现状对照
- 个人网站/小工具：多数完全裸奔（无隐私政策、无告知），被扫到即违规；
- 独立开发者：开始标配隐私政策 + Cookie 告知（受 GDPR 影响的海外场景尤其明显）；
- 正规服务商：隐私政策 + 数据地图 + DPO + 跨境评估全套；
- 我们的位置：介于「独立开发者标配」与「正规服务商」之间——有认证机制但没有「隐私政策」页面和日志清理策略。
四、整改清单（按优先级）
- 加隐私政策页（公区可访问）：说明收集什么（Cookie/日志/认证）、为什么、存多久、如何联系——10 分钟能落地；
- 日志留存策略：access.log / dsh 日志设定留存周期（如 30 天）并写进运维文档，定期清理；
- 第三方清单：整理当前接入的外部服务（MCP/API）各自的收集项与数据流向；
- Cookie 告知：homeZone 等 Cookie 在隐私政策中说明（非必要 Cookie 若未来加统计工具则需弹窗同意）。
⚠️ 实践篇（🟢 现状为本机实测 / 行业现状为 🟡 公开资料归纳），合规判断为信息整理不构成法律意见，以监管口径为准。