lijianfei.com

在当下的 X（原 Twitter）生态中，垃圾内容治理正演变为一场极端不对称的攻防战。

从推文评论区铺天盖地的黄推引流、冒充官方的加密货币 Giveaway 假抽奖，到自动化矩阵批量生产的垃圾回复，信噪比的急剧恶化让原本优质的社交信息流沦为信息沼泽。面对这一顽疾，市面上大多数清理工具要么采用前端 CSS 的 display: none 掩耳盗铃，要么陷入 DOM 菜单高频点击被 X 官方风控封号的泥潭，要么要求用户授予昂贵且危险的官方 API 权限。

开源项目 FeedSieve（官网 feedsieve.win，GitHub：realchendahuang/feedsieve）交出了一份令人耳目一新的工程答卷。它没有走传统爬虫或暴力自动化的老路，而是将自身定位为运行在浏览器内的原生阻断引擎：通过 MAIN / ISOLATED 双世界 XHR 逆向拦截、64 位 SimHash 话术指纹模糊匹配、响应式 24 小时滚动安全账本，以及阳光透明的社区“净票制”治理闭环，实现了“黄框透明预警、同源接口秒级拉黑、全端设备同步消失”。

本文将从现代 Web 扩展架构、逆向数据管线、抗风控状态机与社区共识网络四大维度，对 FeedSieve 的完整技术体系展开立体全景剖析。

1. 社交网络的“暗色地狱”与传统清理工具的三大死穴

在切入 FeedSieve 的内部架构之前，我们首先需要搞清楚：为什么在过去数年里，市面上的 X 清理工具普遍“短命且难用”？

flowchart TD
    subgraph TraditionalPains ["传统 Twitter/X 清理方案的三大死穴"]
        direction TB
        Pain1["死穴一：纯前端 CSS 隐藏 (display: none)<br/>• 仅本地浏览器视口看不见<br/>• 移动端/iPad 依然铺天盖地<br/>• 社交双向关系链未断开"]
        Pain2["死穴二：官方 API / OAuth 授权<br/>• API 商业化后企业级门槛极高<br/>• 个人开发者基础配额严苛 (50次/15min)<br/>• 要求账号高危权限，隐私不可控"]
        Pain3["死穴三：DOM 模拟点击 (for click)<br/>• 混淆类名与异步懒加载导致极易失效<br/>• 固定间隔节拍器极易触发 Arkose 人机验证<br/>• 批量拉黑导致 HTTP 429 与账号临时锁定"]
    end

死穴一：纯前端 CSS 隐藏（掩耳盗铃）

大量轻量级油猴脚本或扩展仅通过 CSS 选择器将垃圾推文容器设置为 display: none。这种“眼不见为净”的思路存在致命硬伤：

• 跨端彻底失效：推文在桌面端浏览器被隐藏，但当用户打开 iPhone、Android 客户端或平板时，垃圾账号依然活跃在时间线首屏；
• 社交图谱未断开：垃圾账号依然可以抓取你的推文、在评论区肆意回复并向你推送私信，黑产矩阵对你的骚扰依然在服务端持续发生。

死穴二：官方 API / OAuth 客户端（门槛与隐私壁垒）

自 2023 年 X 调整开发者政策以来，官方 API 成为奢侈品。企业级访问费用高昂，基础免费配额（如 50 次/15 分钟）连一个百人名单都无法在短时间内拉黑。更为致命的是，第三方应用要求用户授予读写权限，不仅存在凭证泄露隐患，还会将用户的社交关系暴露给外部服务器。

死穴三：暴力 DOM 模拟点击（脆弱且高危）

另一类工具通过脚本在页面上自动寻找推文右上角的 ... 菜单，展开下拉列表，查找包含“屏蔽/Block”字样的选项并点击确认（即典型的 for (...) click()）。

• DOM 契约极度脆弱：X 采用 React Native for Web 架构，CSS 类名全面哈希混淆（如 css-175oi2r r-1iusvr4），且国际化多语言文案频繁改版，任何细微的 DOM 调整都会导致点击脚本彻底死锁；
• 风控行为特征明显：固定节拍的连续微小位移与模拟点击，会立刻被 X 的前端行为监控捕获，瞬间触发 429 限流、强制退出登录、Arkose 验证码挑战，乃至触发“检测到自动化行为”的账号临时冻结。

2. FeedSieve 的底层设计哲学：可见优先，同源原生拉黑

面对上述困境，FeedSieve 在立项之初就确立了核心架构底线：

“可见优先，拉黑唯一。Read the page. Filter locally. Act through the page.”

flowchart LR
    subgraph CorePhilosophy ["FeedSieve 核心运转机制"]
        direction TB
        Step1["1. 扫描与感知<br/>(XHR 逆向桥获取结构化数据)"]
        Step2["2. 本地决策中心<br/>(白名单 + 社区快照 + SimHash + 弱信号)"]
        Step3["3. 页面黄框标注<br/>(透明高亮 + 显式理由，绝不隐藏)"]
        Step4["4. 待拉黑队列<br/>(持久化状态机 + 响应式风控预算)"]
        Step5["5. 同源 Web API 执行<br/>(blocks/create.json 原生拉黑)"]

        Step1 --> Step2 --> Step3 --> Step4 --> Step5
    end

这一哲学在实际工程中沉淀为三个关键实践：

1. 黄框标注（带理由，绝不折叠或隐藏）：
   Detector 仅对判定为高置信的垃圾账号打上明显的金黄色边框，并在推文下方渲染出结构化的证据徽章（如“名单命中 · adult_gray_traffic”或“模板化引流：加密货币 Giveaway 假抽奖”）。它绝不隐藏、折叠或替换页面的任何原始信息。用户拥有绝对的知情权与决策权，彻底消除了“误杀导致错失重要信息”的恐慌感。
2. 同源 Web API 原生阻断：
   FeedSieve 运行在当前已登录的 x.com 标签页内，直接复用浏览器现有的会话凭证，通过同源 fetch 直接调用 X 网页端自身的内部拉黑接口。拉黑指令直接送达 X 服务端，从而在数据库层面斩断关系链——移动端、网页端与第三方客户端全端同步净化。
3. “放回来”（Unblock）作为一等公民：
   误伤兜底与拉黑执行具有完全对等的工程优先级。被误标或误拉黑的账号，用户可以一键撤销（调用 blocks/destroy.json），并在本地立即加入永久白名单，同时向社区提交“抢救票（Rescue Vote）”以修复全网信誉。

3. 架构拆解一：双世界通信与 XHR/fetch 逆向桥

现代 Chrome 扩展基于 Manifest V3（MV3）规范，其 Content Script 默认运行在与页面 JavaScript 完全隔离的独立运行环境（ISOLATED World）中。这虽然保证了扩展自身的安全性，却导致扩展无法直接拦截页面宿主 React 代码发起的异步网络请求。

如果仅在 ISOLATED World 中刮取 DOM，会面临三大难以逾越的障碍：

1. 数字 ID（xUserId / rest_id）不可得：X 的页面 DOM 绝大多数时候只展示 @handle（用户名），但 X 的底层拉黑接口 1.1/blocks/create.json 强依赖 Snowflake 数字 ID（如 166703864...）；
2. 个人简介（bio）在时间线不可见：大量黑产账号为了躲避时间线文本审查，将“TG私聊 / 约V”等核心引流引子藏在个人资料的 bio 中。DOM 时间线根本不渲染这部分文本；
3. 文本与表情断裂：X 会将 emoji 渲染为 <img alt="🍉">，纯 DOM 文本刮取常出现整段丢失或断词。

FeedSieve 的解决之道，是在架构中引入了一个轻量级且高度克制的主世界网络桥（MAIN World Bridge）：

sequenceDiagram
    autonumber
    participant XPage as X 前端应用 (React)
    participant Bridge as xhr-bridge.content.ts (MAIN World)
    participant Doc as 共享 DOM (document)
    participant Content as content.ts (ISOLATED World)
    participant Storage as chrome.storage.local
    participant XApi as X 服务端 (blocks/create.json)

    XPage->>Bridge: 发起 GraphQL 请求 (HomeTimeline / TweetDetail)
    Note over Bridge: 拦截 window.fetch & XHR.send<br/>匹配 MayMatchEndpoint，clone() 异步读取
    Bridge->>Doc: dispatchEvent(CustomEvent "feedsieve:xhr-items", JSON Payload)
    Doc->>Content: 监听并捕获 CustomEvent
    Note over Content: 解析 rest_id、handle、bio、full_text<br/>缓存至 user-ids 与 bioCache
    Content->>Content: 执行本地分层检测流水线
    alt 命中垃圾规则
        Content->>Doc: 给推文外部容器添加黄框与理由徽章
        Content->>Storage: 加入待拉黑列表 (持久化)
    end
    Note over Content: 用户触发「一键拉黑」或「顺手拉黑」
    Content->>XApi: POST /i/api/1.1/blocks/create.json<br/>(带 ct0 CSRF Cookie + X_WEB_BEARER)
    XApi-->>Content: HTTP 200 OK (拉黑成功，全端同步)

1. MAIN World 注入与无损拦截

在扩展配置 wxt.config.ts 中，FeedSieve 注册了在 document_start 时刻执行的主世界脚本：

// apps/extension/entrypoints/xhr-bridge.content.ts
export default defineContentScript({
  matches: ['https://x.com/*'],
  world: 'MAIN',
  runAt: 'document_start',
  main() {
    // 拦截 window.fetch
    const origFetch = window.fetch;
    window.fetch = async function patchedFetch(this: unknown, ...args: Parameters<typeof fetch>) {
      const response = await origFetch.apply(this ?? window, args);
      try {
        const url = typeof args[0] === 'string' ? args[0] : (args[0] instanceof Request ? args[0].url : response.url);
        if (mayMatchEndpoint(url)) {
          // clone 后异步读取，绝对不阻断页面原有响应流
          void response.clone().json().then((body) => inspect(url, body)).catch(() => {});
        }
      } catch {}
      return response;
    } as typeof fetch;

    // 拦截 XMLHttpRequest (覆盖仍走 XHR 的端点)
    // 监听 load 事件并解析 responseText ...
  }
});

2. 跨世界原子通信与安全防御

主世界与隔离世界虽然 JavaScript 堆内存完全隔离，但共享同一个底层 document。FeedSieve 利用 document.dispatchEvent(new CustomEvent('feedsieve:xhr-items', { detail: JSON.stringify(payload) })) 实现单向数据投递。

• 防污染设计：传递的数据被强制序列化为 JSON 纯文本字符串，彻底切断了原型链污染（Prototype Pollution）的潜在通道；
• 自适应节流门禁：通过 createParseThrottle()，对滚动加载时的高频被动轮询实施节流，忽略私信、通知等大体积无关响应，将 CPU 反序列化开销降至极限。

3. 同源拉黑执行器（Zero OAuth）

在拿到了用户的 rest_id 之后，真正的拉黑执行变得极其优雅。代码直接封装在 packages/x-adapter/src/actions/block.ts 中：

export const X_WEB_BEARER =
  'Bearer AAAAAAAAAAAAAAAAAAAAANRILgAAAAAAnNwIzUejRCOuH5E6I8xnZz4puTs%3D1Zv7ttfk8LF81IUq16cHjhLTvJu4FA33AGWWjCpTnA';

export async function runNativeAction(
  type: 'block' | 'unblock',
  xUserId: string,
  fetchImpl: typeof fetch = fetch,
): Promise<NativeActionResult> {
  const csrf = readCsrfToken(); // 从 document.cookie 读取非 httpOnly 的 ct0
  if (!csrf) return { ok: false, code: 'missing_csrf' };

  const endpoint = type === 'block'
    ? 'https://x.com/i/api/1.1/blocks/create.json'
    : 'https://x.com/i/api/1.1/blocks/destroy.json';

  const response = await fetchImpl(endpoint, {
    method: 'POST',
    credentials: 'include',
    headers: {
      'content-type': 'application/x-www-form-urlencoded',
      Authorization: X_WEB_BEARER,
      'X-Twitter-Auth-Type': 'OAuth2Session',
      'X-Twitter-Active-User': 'yes',
      'X-Csrf-Token': csrf,
    },
    body: `user_id=${encodeURIComponent(xUserId)}`,
  });

  if (response.ok) return { ok: true };
  if (response.status === 429) {
    const retryAfter = Number(response.headers.get('retry-after'));
    return { ok: false, code: 'rate_limited', statusCode: 429, retryAfterMs: retryAfter * 1000 };
  }
  // 结构化返回 401/403 会话过期等，绝不假装成功
}

[!NOTE]
缓存 Miss 时的优雅降级（On-demand GraphQL Resolution）：
若某条被标注的推文由于网络延迟尚未在 XHR 缓存中生成 rest_id，FeedSieve 会在用户点击拉黑的瞬间，利用相同的会话凭证静默发起一次 UserByScreenName 的 GraphQL 点对点查询（resolveUserIdByHandle），动态补齐 rest_id，而无需强迫用户刷新页面。

4. 架构拆解二：分层判决流水线与 SimHash 话术指纹

检测引擎的核心位于独立逻辑包 packages/detector。它完全脱离浏览器与 DOM 依赖，只输入一个纯粹的 DetectInput（包含 handle、displayName、text、bio、links），并遵循极其严格的自顶向下确定性瀑布流：

flowchart TD
    Start(["输入 DetectInput (handle, text, bio, links)"]) --> L0{"Layer 0: 本地保护白名单<br/>selfHandle / Following / 个人白名单"}
    L0 -- "命中" --> Clean(["100% 豁免，直接放行 (null)"])
    
    L0 -- "未命中" --> L1{"Layer 1: 社区共识名单<br/>official.json (Ed25519 验签快照)"}
    L1 -- "命中" --> M1["黄框标注: 名单命中<br/>(标记来源: community-list)"]
    
    L1 -- "未命中" --> L2{"Layer 2: 内容模板与指纹匹配<br/>Exact Fingerprint / 64-bit SimHash"}
    L2 -- "精准命中 / 汉明距离 ≤ 10" --> M2["黄框标注: 垃圾模板/话术变体<br/>(标记来源: fingerprint)"]
    
    L2 -- "未命中" --> L3{"Layer 3: 域名与弱信号复合矩阵<br/>恶意推广域名 / 乱码号 + 诱导词"}
    L3 -- "复合证据链成立" --> M3["黄框标注: 弱信号复合/推广域名<br/>(标记来源: heuristic)"]
    
    L3 -- "全部通过" --> Pass(["判定干净 (null)"])

4.1 Layer 0：零泄露的本地终极豁免

在执行任何识别前，FeedSieve 首先进行三道零妥协的私密放行校验：

1. 当前登录账号（selfHandle）：自动从 settings.json 提取，自己发的任何推文绝不被标记，也绝不被折叠；
2. 关注列表（Following Allowlist）：本地私有保护。插件可一键将用户关注的全部好友同步到本机 chrome.storage，这些数据 100% 留存在本地，绝不上报社区，形成绝对免死金牌；
3. 用户本地白名单：用户手动点击“放回来”或“误标”的账号直接入库，一票否决后续所有规则。

4.2 Layer 2：话术指纹与 64 位 SimHash 变体聚类

黑产引流矩阵最擅长利用同音字、全角字符、随机插入标点符号或在末尾附加无意义随机字符串，来逃避传统关键词正则检测。FeedSieve 在此演进出了两代指纹算法：

1. 指纹 v1 的归一化清洗

在生成指纹前，原始文本必须经过严苛的归一化通道：

• NFKC 全角折叠：自动将全角英文字符及空格（如 ｄｍ　ｍｅ）折叠为半角标准字串 dm me；
• 标点与 Emoji 剥离：过滤掉用于干扰视线的杂质符号；
• 停用词过滤：移除中英文高频停用词，大幅降低正常交流与引流模板之间的伪相似度；
• 短文本门槛下调：将模板特征提取长度收缩至 8 个字符，使类似“我福不黑不信你看”这类典型黄推黑话能被精准捕获。

2. SimHash 算法重铸与汉明距离

为了识别同一黑产团伙（Campaign）派生出的数千种变体话术，系统引入了局部敏感哈希（Locality-Sensitive Hashing）——SimHash。

早期的简单哈希由于在 64 位空间中位分布退化（曾出现 64 位中有 21 位恒定的严重 Bug），极易导致误判。在 packages/detector/src/simhash.ts 中，作者引入了 FNV-1a 结合 SplitMix64 终化器 对每个分词特征进行高雪崩效应哈希，最终生成 64 位指纹：

// packages/detector/src/simhash.ts
export const SIMHASH_HAMMING_THRESHOLD = 10;

export function hammingDistance(a: bigint, b: bigint): number {
  let x = a ^ b;
  let count = 0;
  while (x > 0n) {
    x &= x - 1n; // Brian Kernighan 快速置位计数
    count++;
  }
  return count;
}

当一条推文的内容与社区下发的已知黑产模板指纹相比，汉明距离（Hamming Distance）小于等于 10 时，即可判定为同一引流家族的衍生变体！即使黑产团队在句子末尾塞入不同的随机单词沙拉（Word Salad），依然难逃指纹网罗。

4.3 Layer 3：复合弱信号矩阵（拒绝单信号误判）

在规则工程中，“宁可漏报，绝不误标”是维持用户信任的核心基石。FeedSieve 明确禁止单信号盲判：

• 乱码注册号锚点：检测形如 mhmsezruwzxjwl 这类机器生成的无规律英文字符 handle，或长数字默认名；
• 内容佐证联动：单凭账号名奇怪绝不标注（因 X 的 DOM 异步懒加载经常导致昵称临时丢失）。必须同时捕获到“擦边引流隐语”、“纯 Emoji 占位”、“外链可疑推广域名”等至少一项内容层佐证，弱信号复合链条才告闭环，方才触发人工确认黄框。

5. 架构拆解三：三层安全阀与响应式风控预算引擎

对于一款批量拉黑工具而言，“能拉黑”只是初级水平，“在极其严苛的平台反自动化对抗中保护用户账号安全”才是最高工程境界。

X 官方从未公开拉黑的硬性速率限制。社区实测表明：短时间内高频调用会导致 HTTP 429；单日累积超过 400 ~ 500 次拉黑容易引发强制登出重登；若连续触发 429 依然硬打，则极易招致 Arkose 人机验证或账号临时冻结。

FeedSieve 在 packages/block-queue 与 apps/extension/src/lib/block-safety.ts 中构建了一套极具工业级参考价值的 三层安全阀（Three Safety Valves） 体系：

flowchart TD
    subgraph SafetyArchitecture ["FeedSieve 批量拉黑三层安全阀体系"]
        direction TB
        
        subgraph LayerA ["Layer A: 节奏阀 (Pace Valve)"]
            Jitter["非规律节奏: base (800ms) + random(0, 1000ms)<br/>彻底粉碎固定节拍器特征"]
            Cooldown["长程降温: 每成功 80 次插入 45~75 秒深度冷却"]
        end

        subgraph LayerB ["Layer B: 额度阀 (Responsive Budget Valve)"]
            RollingLedger["24小时滚动安全账本 (默认起点 400 次)"]
            SignalShrink{"风控信号反馈"}
            RollingLedger --> SignalShrink
            SignalShrink -- "连续 3 次 429" --> Half["当日预算砍半 (400 → 200) + 队列整队暂停"]
            SignalShrink -- "401/403 会话失效" --> Zero["当日预算立即清零 + 队列整队暂停"]
            SignalShrink -- "连续 3 个干净无信号日" --> Bonus["逐日回补 +50 (上限封顶 800)"]
        end

        subgraph LayerC ["Layer C: 异常与状态机阀 (Exception & State Valve)"]
            QueueRunner["持久化 QueueRunner (适配 MV3 Service Worker 重启)"]
            Classification{"失败类型分类"}
            QueueRunner --> Classification
            Classification -- "transient (429/网络/5xx)" --> Retry["单任务指数退避 (尊重 Retry-After + 抖动)"]
            Classification -- "pause (额度耗尽/会话失效/KillSwitch)" --> Pause["整队暂停，保留现场，等次日手动继续"]
            Classification -- "permanent (账号注销/形状漂移)" --> Drop["单任务直接置 failed，不卡死队列"]
        end

        LayerA --> LayerB --> LayerC
    end

1. 节奏阀（粉碎固定节拍器特征）

固定间隔是自动化机器人最明显的指纹特征。FeedSieve 严格禁止并行操作，每次拉黑成功后强制注入动态抖动休眠：

$\text{SleepTime} = \text{baseMs} + \text{random}(0, \text{jitterMs})$

在默认的 Balanced 档位下，基准耗时为 800ms，抖动上限为 1000ms，相邻请求间隔在 0.8 秒至 1.8 秒之间无序浮动。此外，每累计拉黑 80 个账号，系统会自动强制插入一段 45 至 75 秒的长程冷却。

2. 额度阀（响应式预算账本）

FeedSieve 抛弃了静态硬编码限制，设计了名为 blockSafetyLedgerV1 的账号级响应式账本：

• 按登录账号分槽管理：切换 X 账号时自动隔离账本，互不串扰；
• 24 小时滚动窗口：统计过去 24 小时内的实际成功写操作，而非机械的自然日截断（防范 23:50 打满、次日 00:05 再次突发的连续脉冲）；
• 自适应弹性收缩与回补：
  • 若连续遭遇 3 次 429（定义为限流风暴 rate_limit_storm），当日生效预算立刻砍半（如 400 骤降为 200），队列暂停并如实弹窗提示；
  • 若遭遇 401/403 或 ct0 失效，判定会话受损，当日预算瞬间清零并整队暂停；
  • 若账号保持健康，在连续 3 个无异常信号的自然日后，系统每天自动回补 +50 额度，允许最高弹性扩展至 800。

3. 持久化状态机与 MV3 休眠防线

在 Manifest V3 规范下，后台 Service Worker 随时可能被 Chrome 系统休眠。如果拉黑任务维护在内存变量中，会导致任务丢失或重复执行。

• 任务分片与原子写前复核：QueueRunner 将所有等待切片为 ≤ 250ms 的微小片段，使得用户在任何时刻点击“暂停”或“取消”，都能在一片时间内迅速响应；
• 孤儿任务自愈（queue-supervisor）：引入心跳机制（Heartbeat）。当执行批量拉黑的浏览器标签页被用户意外关闭时，新激活的页面能够在心跳停摆后自动接管并安全挂起队列，杜绝双进程并发执行（Split-Brain）引发的风控灾难。

6. 架构拆解四：阳光下的社区净票共治与隐私无感同步

垃圾账号库如果依赖某个单一中心化机构维护，必然会陷入“更新滞后”、“寻租腐败”或“误伤政治/争议性观点账号”的信任危机。FeedSieve 在 community-api（基于 Cloudflare Workers + Hono + D1 数据库）中落地了一套公开透明的开源治理模型。

flowchart LR
    subgraph CommunityConsensus ["社区名单净票治理模型"]
        direction TB
        subgraph Voting ["分布式客户端 (零敏感数据上传)"]
            V1["用户 A: 标记拉黑 (+1 票)"]
            V2["用户 B: 标记拉黑 (+1 票)"]
            V3["用户 C: 误标/抢救 (-1 票)"]
            V4["用户 D: 标记拉黑 (+1 票)"]
        end

        subgraph Calculation ["Cloudflare D1 边缘计算"]
            Formula["净票数 (Net Votes) = 拉黑票数 - 抢救票数"]
            Threshold{"Net Votes ≥ 3 ?"}
        end

        subgraph Publishing ["自动化发布流水线"]
            Blocklist["正式社区黑名单<br/>(纳入 official.json)"]
            Drop["自动剔除候选池"]
            Verified["抢救净票 ≥ 3 ?<br/>→ 晋级社区白名单 (verified)"]
        end

        Voting --> Formula --> Threshold
        Threshold -- "是 (高置信共识)" --> Blocklist
        Threshold -- "否" --> Drop
        Formula -.-> Verified
    end

1. 唯一入榜门槛：抵消制“净票公式”

为了防范黑客小号批量恶意刷票（Brigading）抹黑无辜博主，FeedSieve 的规则极其简单明了：

$\text{Net Votes} = \text{Block Votes} - \text{False-Positive (Rescue) Votes}$

• 每个匿名客户端对每个账号有且仅有一票；
• 只有当净票数严格达到 3 票 时，该账号才会正式进入社区黑名单；
• 一旦后续出现异议，抢救票增加导致净票数跌破 3 票，该账号将秒级自动从社区黑名单中除名；
• 反之，如果一个正常账号被误标，且抢救净票数达到 3 票，它将直接进入 社区白名单（Verified List），获得全社区全局豁免权。

2. 抑制正反馈的“防自我放大”防线

在很多社区风控系统中，往往存在一个致命的逻辑死循环：一个账号一旦进入黑名单被推给大众，成千上万的用户就会盲目点击拉黑，导致该账号的“举报数”指数级虚高，彻底失去纠错可能。

FeedSieve 从代码设计上物理斩断了这一循环：

// apps/extension/entrypoints/content.ts
function communityVoteForDetection(detectionSource: string | undefined, ruleId?: string): boolean {
  // 核心红线：若拉黑是由于「社区名单命中」或「用户自定义关键词/行业包」触发的，
  // 严禁向后端回传投票！只有客户端通过指纹/域名/独立弱信号原创发现的垃圾账号，才具备投票资格。
  return detectionSource !== 'community-list' && !ruleId?.startsWith('keyword:');
}

这一机制确保了进入黑名单的账号，其候选票数永远代表全网真实独立发现的有效人次，杜绝了回音壁效应。

3. 隐私与离线零开销

• 绝不搜集浏览痕迹：上报数据仅包含目标 handle、识别分类与 64 位 SimHash 模板哈希，用户正在看什么推文、谁的个人主页，原文连同 URL 绝不离开设备；
• 静态快照本地验证：Cloudflare 定时构建签名的 official.json 与 manifest.json（带有 Ed25519 密码学签名），客户端离线下载并在本地内存建索引。用户在刷 X 时，时间线滚动不会向 FeedSieve 服务器发送任何探测请求，既保护了用户的浏览隐私，也让扩展在弱网或离线环境下依然稳定生效。

7. 启示与思考：现代 Web 插件工程学的范式转移

剖析完 FeedSieve 的完整代码全景，我们可以清晰地提炼出新一代浏览器端安全工程的三条演进范式：

FeedSieve 的工程价值不仅在于它让 X 的用户重获清爽的时间线，更在于它向开发者展示了：在中心化社交平台收紧 API、前端代码深度混淆的今天，如何通过严谨的逆向桥接、优雅的状态机设计与去中心化的开源共识，构建出一套兼顾高阻断力、低侵入性与极致账号安全的高可用工具矩阵。

这种把技术攻防逻辑藏在冰山之下、把确定性与控制权交还给用户的设计哲学，正是每一个追求卓越的技术团队应当秉持的工程底色。

🔗 权威官方信息与参考链接

• FeedSieve 官方网站: feedsieve.win
• GitHub 官方源码仓库: realchendahuang/feedsieve
• Chrome 应用商店地址: FeedSieve on Chrome Web Store
• Twitter-Block-With-Love 机制参考: GitHub - E011011101/Twitter-Block-With-Love
• WXT 新一代扩展开发框架: wxt.dev