风控与反作弊体系：从设备指纹到团伙识别

风控的两个错误方向：
□ 拦得太松：作弊者横行 → 数据失真、生态恶化、商业化受损
  · 刷粉导致「粉丝数」失去意义
  · 刷榜导致热榜被水军占领
  · 薅羊毛导致营销预算被黑产吞掉
□ 拦得太紧：误杀正常用户 → 体验受损、投诉、流失
  · 新用户注册被拦 → 拉新失败
  · 正常用户被误判封号 → 口碑崩塌

平衡的关键指标：
□ 召回率（Recall）：真实作弊中被抓住的比例 → 太低 = 漏放
□ 准确率（Precision）：判为作弊中真是作弊的比例 → 太低 = 误杀
□ 覆盖率：风控覆盖了多少关键场景
□ 决策延迟：不能拖慢主流程

务实原则：
□ 宁可「降权」而非「封禁」——可逆的处置优先
□ 先拦「高确定性的坏」，再逐步扩展边界
□ 给正常用户「快速自证」的通道（验证码、申诉）

事前（Prevention）——把作弊挡在门外：
□ 注册风控：设备指纹、行为验证码、手机号/邮箱验证
□ 实名/活体：高风险场景才要求
□ 设备黑名单：已知作弊设备直接拒绝
□ 成本抬高：让批量注册变贵（验证码、限速、邮箱验证）

事中（Detection & Mitigation）——实时拦截：
□ 实时规则引擎：命中规则立即限流/挑战/降权
□ 实时模型打分：高风险行为即时处置
□ 频控与配额：发帖/关注/点赞的频率上限
□ 挑战升级：可疑时弹验证码，而非直接拒绝

事后（Investigation & Cleanup）——清理与学习：
□ 离线挖掘：批量扫描历史行为找团伙
□ 数据回滚：清理刷出来的粉丝、赞、榜单
□ 封禁与连坐：封禁作弊账号及其关联账号
□ 特征沉淀：把新发现的作弊模式变成规则/特征

身份标识的层级：
□ 账号（Account）：最强但最易变——批量注册绕开
□ 设备（Device）：中等强度——换设备/改机可绕开
□ IP / 网络：弱——代理池、NAT、共享出口易混淆
□ 行为生物特征：最强——打字节奏、操作习惯（隐私敏感）

设备指纹（Device Fingerprint）：
□ 采集维度：UA、屏幕分辨率、时区、语言、字体列表、
  硬件并发数、Canvas/WebGL 渲染哈希、音频指纹等
□ 稳定性：同一设备多次访问应得到相近指纹
□ 唯一性：不同设备应得到不同指纹
□ 局限：可被篡改（改 UA、随机化 Canvas）；移动端受隐私限制

设备 ID 的分层策略（务实做法）：
□ 强 ID：App 内 SDK 生成并持久化（卸载重装可能变）
□ 中 ID：指纹哈希（组合多个维度，容忍抖动）
□ 弱 ID：IP + UA（仅作辅助）

隐私边界（重要）：
□ 采集要透明（隐私政策告知），可被用户关闭
□ 不做「跨站追踪」，只用于站内风控
□ 遵守 GDPR / 个保法：最小必要、目的限定
□ 指纹是「概率标识」，不能当作绝对身份

规则引擎的组成：
□ 特征（Feature）：输入变量，如「1 分钟内注册数」「关注数」
□ 条件（Condition）：阈值与逻辑，如「注册数 > 5」
□ 动作（Action）：命中后的处置，如「挑战验证码」

典型规则示例：
□ 注册：同设备 1 小时注册 > 3 → 要求手机验证
□ 关注：新账号 1 小时关注 > 50 → 限流 + 标记
□ 点赞：同 IP 1 分钟点赞 > 100 → 挑战验证
□ 发帖：同内容 5 分钟内重复 > 3 → 降权 + 审核
□ 登录：异地登录 + 新设备 → 二次验证

行为特征的设计（区分人与机器）：
□ 频率类：单位时间操作次数（机器往往远超人类上限）
□ 规律类：操作间隔的方差（机器过于规律，人类有抖动）
□ 序列类：操作顺序（机器按固定路径，人类随机）
□ 多样性类：内容/目标是否重复（机器爱刷同一个目标）
□ 时间类：活跃时段（凌晨集中注册 = 可疑）

特征要「可解释、可计算、可回溯」：
□ 可解释：能说清为什么判可疑
□ 可计算：实时可算（滑动窗口 / 流式聚合）
□ 可回溯：能复现「当时为什么命中」

规则 vs 模型：
□ 规则：确定、可解释、即时生效；但易被绕过、维护成本高
□ 模型：能发现规则之外的关联；但需要标注、有冷启动、
  可解释性弱、可能被对抗样本欺骗

务实组合：
□ 规则做「硬拦截」：高确定性、高风险的动作直接拦
□ 模型做「风险打分」：给每个动作/账号打 0~1 的分
□ 分层处置：分数越高，处置越重（观察 → 挑战 → 限流 → 封禁）

实时决策的架构：
┌────────────────────────────────────────┐
│ 事件（注册/关注/点赞/发帖/登录）        │
├────────────────────────────────────────┤
│ 特征计算（实时聚合 + 离线画像）          │
│  · 实时：Redis 滑动窗口计数              │
│  · 离线：T+1 画像（历史行为、关联关系）  │
├────────────────────────────────────────┤
│ 决策（规则引擎 + 模型打分）              │
│  · 规则优先（确定性拦截）                │
│  · 模型兜底（概率性处置）                │
├────────────────────────────────────────┤
│ 动作（放行/挑战/限流/降权/封禁/审核）    │
│  · 延迟预算 < 100ms                     │
└────────────────────────────────────────┘

三类名单：
□ 黑名单（Blacklist）：确定作弊 → 直接拒绝
  · 来源：人工确认、模型高置信、用户举报核实
  · 风险：一旦误入，正常用户被永久伤害 → 要可申诉
□ 白名单（Whitelist）：信任 → 跳过部分风控
  · 来源：内部账号、大 V、企业客户、长期正常用户
  · 风险：被攻陷的账号（盗号）→ 白名单也要监控异常
□ 灰名单（Greylist）：可疑 → 加强监控/挑战
  · 来源：模型中等风险、规则软命中
  · 处理：不直接拒绝，而是弹验证码、限制配额

团伙的关联信号：
□ 共享设备：多个账号同一设备指纹
□ 共享 IP / 网段：同一出口、同一代理池
□ 行为同步：一批账号在相近时间做相同操作
□ 关系闭环：互相关注形成紧密子图（互粉团）
□ 内容相似：发布的文本/图片高度相似
□ 注册时序：短时间内批量注册（同批特征）

图分析的思路：
□ 把「账号-设备-IP-行为」建成异构图
□ 用连通分量找「强关联的账号簇」
□ 用社区发现（Louvain）找「行为紧密的群体」
□ 用中心度找「团伙中的关键节点（组织者）」

-- 共享设备找团伙：同一设备指纹关联多个账号
SELECT device_fp, COUNT(DISTINCT user_id) AS accounts,
       array_agg(DISTINCT user_id) AS users
FROM user_devices
GROUP BY device_fp
HAVING COUNT(DISTINCT user_id) > 5;

-- 互粉团：A 关注 B 且 B 关注 A 的密集子图
SELECT LEAST(a.follower, a.followee) AS u1,
       GREATEST(a.follower, a.followee) AS u2
FROM follows a
JOIN follows b
  ON a.follower = b.followee AND a.followee = b.follower
WHERE a.follower < a.followee;

处置阶梯（由轻到重，优先可逆）：
1. 观察（Observe）：只记录不打标，收集证据
2. 挑战（Challenge）：弹验证码、短信验证 → 抬高成本
3. 限流（Throttle）：降低配额、延迟生效
4. 降权（Demote）：内容不进推荐/榜单，但用户无感
5. 标记（Flag）：打上「可疑」标签，供后续处置
6. 封禁（Ban）：禁止登录/发言（可临时可永久）
7. 清理（Cleanup）：回滚刷出来的数据（粉丝、赞、榜单）

处置原则：
□ 可逆优先：能降权就不封禁
□ 比例原则：处置力度与证据强度匹配
□ 告知：处置要让用户知道（否则申诉无门）
□ 留痕：每次处置记录证据、规则、操作人

申诉闭环：
□ 入口：用户能看到「为什么被处置」并提交申诉
□ 时效：明确处理时限（如 24~72 小时）
□ 复核：人工/二次模型复核，避免「机器判了没人管」
□ 反馈：申诉结果要反馈给用户
□ 反哺：申诉中被纠正的误判 → 修规则/调阈值

数据回滚的复杂性：
□ 刷出的粉丝：删除关注关系（注意可能已影响被关注者）
□ 刷出的赞：回滚计数（要用对账任务修正）
□ 刷上的榜单：重算榜单，剔除作弊账号的贡献
□ 回滚要幂等：重复执行不产生副作用

风控的核心指标：
□ 召回率：真实作弊中被识别的比例（怕漏）
□ 准确率：判为作弊中真是作弊的比例（怕误杀）
□ 误杀率：正常用户被错误处置的比例（体验底线）
□ 覆盖场景：注册/关注/点赞/发帖/登录的覆盖率
□ 决策延迟：P99 是否在预算内
□ 申诉率与申诉纠正率

误杀控制：
□ 灰度上线新规则：先「只观察不处置」跑一段时间
□ 影子模式（Shadow Mode）：新模型只打分不生效，对比历史
□ 阈值回测：用历史数据评估新阈值的误杀
□ 兜底通道：被误杀用户有快速自证路径（验证码即可放行）

合规边界（不可逾越）：
□ 数据最小必要：只采集风控必需的数据
□ 目的限定：采集的数据不能挪作他用（如营销）
□ 透明度：隐私政策要说明风控数据的使用
□ 用户权利：可查询、可删除（符合个保法/GDPR）
□ 反歧视：不能基于敏感属性（种族、宗教等）做风控
□ 可解释：对用户的处置决定要有可解释的理由