数据生命周期管理，就是把数据从“出生到销毁”全程管起来：该收才收、该用才用、该留多久留多久、到期必须删干净。 在 Hyperf 里，最佳做法是做成一条标准流水线，而不是靠人记。 ---1)生命周期8个阶段（先统一口径）1. 采集：收什么、为什么收、有没有同意2. 传输：怎么安全传（加密、签名、防重放）3. 存储：存哪、分级、加密、权限4. 使用：谁能看、谁能改、有没有审计5. 共享：跨服务/跨系统怎么共享（契约+脱敏）6. 归档：低频数据转低成本存储7. 保留：按法规和业务规则保留多久8. 销毁：到期自动删，主库/缓存/索引/备份都删 ---2)Hyperf 最小落地模型（先把这4件事做实）1. 字段分级（L1-L4） - L1公开，L2内部，L3敏感，L4高敏2. 保留策略表（Retention Policy） - 每类数据明确保留时长，如30天/180天/3年3. 数据目录（Data Catalog） - 记录“字段含义、来源、去向、负责人”4. 删除编排任务 - 定时任务统一执行“软删 ->延迟硬删 ->清理衍生副本” ---3)数据分级 + 保留策略（核心） 每张业务表都要有： - 数据级别（L1-L4） - 合规依据（业务必要/法定义务/用户同意） - 保留时长 - 到期动作（删除/匿名化/归档） - 数据 owner（业务负责人 + 技术负责人） 例子： - 订单主数据：保留3年（审计需求） - 登录日志：保留180天 - 营销埋点原始明细：保留30-90 天后聚合留存 - 高敏凭证：短期存储+强加密 ---4)Hyperf 代码层怎么做 A. 采集阶段（入口中间件） - 统一校验采集最小化（多余字段不入库） - 写入 trace_id、tenant_id、data_classification - 敏感字段入站即脱敏日志（日志不打明文） B. 存储阶段（Repository层） - L3/L4 字段应用层加密（不仅靠磁盘加密） - 禁止跨域直连他人数据主表 - 默认字段级访问控制（不是“有库权限就全看”） C. 使用阶段（Application/Service层） - 读取高敏字段要走授权检查 - 高敏查询必须审计（谁、何时、目的、结果） - 导出接口默认脱敏 + 限速 + 审批 D. 删除阶段（Job/Consumer） - 统一删除任务（幂等） - 删除顺序：主库 ->缓存 ->搜索索引 ->数据副本 ->备份过期标记 - 删除结果写审计日志，可追踪可复核 ---5)数据血缘（防“删不干净”的关键） 至少维护三条关系： - 来源：数据从哪来（API、回调、导入） - 流向：去过哪些系统（DB、Redis、ES、MQ、BI） - 派生：有哪些衍生表、聚合表、报表快照 没有血缘图，删除请求和合规审计一定会出问题。 ---6)合规动作工程化（PIPL/GDPR思路） 必须产品化这3类请求：1. 访问/导出请求：导出本人数据2. 更正请求：修正错误信息3. 删除请求：触发完整删除流水线 实现建议： - 建 privacy_request 工单表 - 用异步任务处理，状态机推进 - 每步留审计证据（时间、操作者、对象、结果） ---7)CI/CD 门禁（不自动化就会失效） 上线前自动检查： - 新增字段是否标记分级 - 是否声明保留时长 - 是否配置脱敏与审计 - 是否触发明文密钥/敏感日志扫描 - 是否补齐删除任务映射 任一缺失，直接阻断合并或发布。 ---8)成本联动（生命周期不只是合规，也为省钱） - 热数据（高频查询）放高性能存储 - 温数据归档到低成本存储 - 冷数据到期清理 - 减少无效日志和重复副本 核心指标： - 单位请求存储成本 - 冷数据占比 - 到期数据清理完成率 - 无主数据（没人负责）占比 ---9)Hyperf 高频坑位（提前避开）1. 只删主库，不删缓存/ES/报表副本2. 只做软删，长期不硬删3. 高敏字段写进日志4. 删除任务不幂等，失败重试把数据删乱5. 备份永不过期，导致“逻辑删了但实际还在”6. 没有数据 owner，最后谁都不负责 ---10)90天落地路线（最实用）0-30天 - 完成核心表字段分级 - 建 retention policy 台账 - 上线敏感日志扫描和审计基础31-60天 - 打通数据删除流水线（含缓存/索引） - 建隐私请求处理流程 - 发布 CI 合规门禁61-90天 - 血缘覆盖核心链路 - 归档与清理自动化 - 每月出生命周期治理报告 --- 一句话收尾： Hyperf 数据生命周期管理的最佳方式，是把“分级、保留、删除、审计”做成默认流程和自动门禁。 做到后你会同时拿到三件事：合规更稳、事故更少、存储成本更低。
