gdpr-dev

用途：为在欧洲构建符合 GDPR 的 Web 应用提供开发参考。只要涉及个人数据，GDPR 即适用，应在功能设计阶段主动遵循，而非事后补救。

主要能力与要点：

1. 日志中的 PII：console.log(user) 或记录请求体会把个人数据发给错误追踪与日志聚合工具；Sentry 会将 console.log 捕获为 breadcrumb，应视为 PII 风险。应记录 ID 而非对象，例如 logger.info({ userId: user.id })。
2. JWT 中的 PII：若负载含邮箱或姓名，用户请求删除时已签发的令牌无法撤回。建议使用不透明会话令牌，或仅在 JWT 中放用户 ID 并设很短的过期时间，例如 jwt.sign({ userId }, secret, { expiresIn: "15m" })。
3. 软删除不等于删除：deleted_at = now() 会保留全部 PII。删除权要求清空或覆写 PII 字段，同时保留行以维持引用完整性，例如 UPDATE users SET email = null, name = null, erased_at = now() WHERE id = ?。
4. 备份绕过删除：从线上库删除不影响备份。要么让备份保留期与删除 SLA 一致，要么优先采用匿名化而非删除，使备份中不含可识别数据。
5. IP 地址属于 PII：访问日志、限流记录与分析都会采集 IP，须应用与其他 PII 相同的保留与删除策略。
6. 错误信息泄露 PII：堆栈跟踪常包含触发错误的数据，如“User john@example.com not found”，会带 PII 进入 Sentry 与日志聚合器。记录前应净化错误信息，例如抛出 “User not found” 并把 userId 作为内部字段。

使用方式：项目中可参考 references/gotchas.md 获取完整反模式列表，参考 references/schema-patterns.md 了解模式设计。

适用场景：用户注册、资料管理、认证、邮件发送等任何处理个人数据的开发工作。

限制：资料未提供具体安装命令、许可或集成步骤；以上为原则性参考，落地时需结合具体技术与法律要求。