别关遥测：Claude Code 源码泄露后，你可能正在做最危险的操作

昨天 Claude Code 源码泄露，中文社区最热门的操作就是照着教程关闭遥测。请不要这样做。 这篇文章解释为什么。

昨天发生了什么

Claude Code 的当前版本源码（cli.js.map）被逆向泄露了。泄露内容里包括遥测上报的全部逻辑——上报了哪些字段、走了几条链路、以及怎样通过环境变量把遥测关掉。

很快，中文社区开始疯传一份"遥测拆解文档"，有一个建议是：设置几个环境变量，把遥测关掉，这样 Anthropic 就看不到你的信息了，账号就安全了。

恐怕有非常多人照做了。

我写这篇文章，是因为我认为这个建议不仅没用，而且有害。它会让你的账号更危险，而不是更安全。

在开始之前：两个共识

第一，所有风控策略都是黑盒。 除了 Anthropic 内部的风控团队，没有人知道确切的规则和权重。我们能做的，只是根据现象反推逻辑，结合经验做出判断。包括这篇文章本身，也是我的推测和分析，不是内部信息。

第二，风控是概率题，不是是非题。 风控系统做的事情，是给每个用户打一个"风险分"，综合多个信号交叉判断。这就导致了一个现象：同样的操作，A 做了没事，B 做了被封。不是因为规则不一致，而是两个人的其他信号组合不同，最终得分不同。

记住这两点，后面的分析会更好理解。

一个重要背景：Claude Code 深度参与 Anthropic 的运作

在聊风控之前，有一个背景值得单独拿出来说。

Anthropic 已经多次公开表示，他们公司内部大量的工作——包括代码开发、内部工具搭建——都是由 Claude Code 自己来完成的。换句话说，Claude Code 不只是他们卖给用户的产品，也是他们自己每天在用的生产工具。

那么我们就有理由做一个合理推测：Claude Code 的风控策略设计、信号分析、甚至判定逻辑，很可能也有 Claude 自身的深度参与。

这意味着什么？意味着你面对的风控系统，不太可能是一堆写死的 if-else 规则。它更可能具备大模型的分析能力——能理解上下文、能做多信号交叉推理、能识别行为模式。

用人话说：你面对的"审查官"，可能就是 Claude 本人。 而你觉得自己很聪明地关掉了遥测，在它看来，可能只是一个非常显眼的异常信号。

Claude Code 风控的两个目的

在分析具体行为之前，先理解风控在防什么。Claude Code 的风控主要针对两类人：

1. 反逆向 / 反自动化

有人通过逆向 Claude Code 的客户端，对外暴露 API 接口来倒卖。Claude Code 是按月订阅的（Max 套餐 $200/月），但如果逆向后当 API 用，可以跑出远超订阅价的调用量。这中间的利润空间非常大，所以有很强的经济动机。

2. 反不合规地区使用

由于美国出口管制和制裁合规要求，Anthropic 需要禁止特定地区的用户使用其产品。这些地区包括中国大陆、朝鲜、伊朗、古巴等。

这两个目的有时候会交叉——比如不合规地区的用户逆向客户端来用，同时触犯了两条线。但本文主要聊第二个：作为中国大陆用户，怎样降低被风控命中的概率。

核心论点：为什么关闭遥测反而更危险

这是全文最重要的部分。

比喻一：班级点名

想象一个 50 人的班级，老师怀疑有一个人感冒了，要把他找出来。

如果这个人只是轻微咳嗽，混在人群里，其实不太容易被发现——毕竟很多人都会偶尔咳两声。

但如果这个人干脆没来上课，座位是空的——老师甚至不需要观察，一眼就知道谁缺席了。

关闭遥测就相当于不来上课。 你以为自己躲起来了，但实际上，你是全班最显眼的那个人。

比喻二：体检报告

每年公司体检，每个人都会交一份报告。报告里有高有低——有人血压偏高，有人尿酸偏高，这都很正常。

但有一个人交了一张白纸，说"我没做体检"。

你觉得 HR 会认为这个人身体最健康？还是会觉得这个人有事要隐瞒？

正常的遥测数据就是你的体检报告。报告里的数据有好有坏不重要，重要的是你交了。不交报告这个行为本身，就是最大的异常信号。

为什么这个逻辑成立？让我们拆开来看

第一：关闭遥测的教程只在中文社区传播

这次源码泄露后，“关闭遥测"的教程主要通过什么渠道传播的？微信群、Telegram 中文群、中文技术论坛。

这意味着：接触到这个信息的人，绝大多数是中文用户，尤其是中国大陆用户。合规地区的英文用户，大部分根本不知道有这回事，知道了也没有强烈动机去做。

所以，从风控视角来看，“关闭遥测"这个行为本身就自带了一个地域标签——做这个操作的人，有很高的概率是中国大陆用户。

第二：动机完全不对等

谁会有强烈动机去关闭遥测？

• 中国大陆用户：遥测数据可能暴露真实地理位置 → 导致封号 → 经济损失。这是「求生型动机」——不关就可能死。
• 合规地区的隐私敏感用户：可能出于隐私偏好想关，但不关也完全没有后果。这是「偏好型动机」——无所谓。
• 普通合规用户：根本不知道可以关，也不在乎。

求生型动机的行为转化率，远远高于偏好型动机。风控系统不需要知道你是谁，只需要知道：在所有关闭遥测的用户中，不合规地区用户的比例显著偏高。

这就够了。

第三：你关不掉的东西比你能关掉的多得多

很多人以为关了遥测就"隐身"了。但遥测只是众多信号中的一部分。以下这些信号，无论你怎么设置环境变量，服务端每次 API 请求都能看到：

• 你的连接 IP 及地理归属
• IP 类型（住宅 IP 还是机房 / VPN）
• TLS 握手指纹（JA3/JA4）
• HTTP 指纹（Header 顺序、行为特征）
• 你的 OAuth Token 和账号信息
• API 调用参数、频率、时间分布
• 客户端版本号

你关掉遥测，这些信号一个都没少。服务端该看到的全都看到了。你唯一做到的事情，是多暴露了一个信号：这个人主动关闭了遥测。

等于你本来穿着一件有点可疑的外套走在街上，现在你把外套脱了——但你往脸上贴了个纸条，写着"我刚脱了外套”。

把这三点连起来

风控系统看到一个用户关闭了遥测，它的推理链大概是这样的：

1. 这个人关闭了遥测 → 他知道怎么关 → 他看过中文社区的教程 → 大概率是中文用户
2. 他为什么要关？→ 合规用户没有强动机 → 大概率是不合规地区用户，害怕暴露
3. 关闭遥测后，遥测画像缺失 → 但服务端硬信号全在 → 可以继续通过 IP、行为模式、注册信息交叉验证

最终结论：关闭遥测不仅没有降低风险，反而给风控系统多提供了一个高权重的判定依据。

那应该怎么做？

核心思路只有一句话：让自己看起来像一个正常的合规地区用户，而不是让自己消失。

1. 不要关闭遥测

不要设置任何与遥测相关的环境变量。保持默认就好。如果你已经设置了，请尽快清除。

# 检查是否已经设了相关变量
env | grep -i telemetry
env | grep -i otel
env | grep -i analytics

# 如果有，去你的 shell 配置文件里删掉对应的行
# 检查这些文件：~/.bashrc, ~/.zshrc, ~/.profile, ~/.bash_profile

2. 不要安装手机客户端

这一点非常重要，但很多人忽略了。

手机客户端会采集三种几乎不可能伪装的硬件级地理信号：

• GPS 定位：直接定位你的物理位置
• SIM 卡 MCC/MNC：你的 SIM 卡属于哪个国家的运营商（中国三大运营商的编码是 460/461，这是写在硬件里的）
• 基站定位：即使关闭 GPS，基站也能定位

这三个信号是风控系统中置信度最高的地理证据，任何一个命中制裁地区，基本就是直接判定。

实际更多，ios 有专门的 api，见前文：Claude Code：防封号、模型选择与设计哲学

而且，伪装这些信号的成本极高——你要么用合规地区买的手机和 SIM 卡远程操控，要么用已经 Root 的设备配合位置伪装模块。前者麻烦，后者容易触发 Root 检测反而弄巧成拙。

最优策略就是不安装。 目前 Claude Code 的核心功能在桌面端 CLI，不安装手机客户端不影响使用。没有手机客户端，风控系统就少了一整类高置信度信号来源。少一个维度的数据，就少一个暴露的可能。

3. 网络：用质量好的代理，保持稳定

• 尽量使用住宅 IP，不要用机房 IP 或免费 VPN（IP 类型是可以被检测的）
• 选一个合规地区的 IP 后固定下来，不要频繁切换国家
• 全程保持代理连接，不要有时候走代理有时候不走——IP 地理位置突然从纽约跳到上海，这个信号太强了

4. 环境一致性：让所有信号指向同一个地方

如果你的 IP 在美国纽约，那你的系统时区、语言设置也应该对齐：

# 时区与 IP 归属地一致
export TZ="America/New_York"

# 语言设置为英文
export LANG="en_US.UTF-8"
export LC_ALL="en_US.UTF-8"

最常见的穿帮是：IP 在纽约，但时区是 Asia/Shanghai。 这种矛盾在风控系统看来是非常明显的。

同样的道理，如果你用的是 Linux，避免使用 deepin、UOS 这类中国特有发行版——它们的发行版名称本身就是一个强地理信号。用 Ubuntu、Debian 这类国际通用发行版。

5. 正常使用，不要搞自动化

• 正常的交互式使用，有间隔、有停顿
• 不要 24 小时无间断调用
• 不要用脚本批量跑
• 合理的调用频率

风控看的不只是"你在哪”，还有"你怎么用"。一个号如果表现出自动化特征，不管在哪都会被标记。

6. 如果这台设备曾经被封过号，整个环境都需要清理

这一点很多人会忽略。如果你的设备上有过被封号的记录，那不是换个账号重新登录就完事了的。风控系统大概率会采集设备级别的标识信息——比如 deviceId、硬件指纹、本地存储的历史数据等。这些东西不会因为你换了账号就消失，它们留在你的设备上，像一个"前科记录"。

新账号登录进来，风控系统一关联，发现这台设备上之前有封号历史——风险分直接拉满。

所以如果遇到这种情况，需要对整个运行环境做一次彻底清理。具体需要处理哪些因素，其实是可以通过逆向分析客户端源码来确认的——看它在本地存了什么、上报了哪些设备标识、哪些路径下有持久化数据。清理干净这些，才算真正"换了一台新设备"。

一句话总结

风控的对抗逻辑不是"消失"，而是"融入"。 你不需要让自己变成一个没有任何数据的幽灵——那反而是最显眼的。你需要的是让自己看起来和千千万万合规地区的正常用户没有区别。

保持遥测开启，保持环境一致，保持网络稳定，保持正常使用模式。这不能保证 100% 安全（记住，风控是概率题），但这是目前能做到的最优策略。

关闭遥测呢？那是告诉风控系统：“我有东西要藏”。

也给大家一个简单的判断框架：当你在考虑任何一个"防封手段"的时候，问自己一个问题——这个操作是让我更像一个普通用户，还是更不像一个普通用户？ 如果答案是后者，那大概率是在帮倒忙。

最后说一句：我无意和任何人辩论这个问题。如果你分析之后仍然认为关闭遥测是更好的选择，那完全尊重你的判断，我也支持。风控这个东西本质上是黑盒，没有人能拿出确凿的证据说"这样做一定对"或"那样做一定错"——它没办法像跑单元测试一样进行实际验证。我只是分享我自己的分析逻辑，供你参考。

本文由语音输入初稿，与 Claude Code + Opus 4.6 协作完成文章架构和语言组织，题图由 Nano Banana 生成。

附录：参考文档

以下两份文档是从不同视角（攻防双方）对 Claude Code 风控体系的详细分析。文档内容较长且技术性强，供有需要的读者深入参考。

需要强调的是：这两份文档的内容也是基于源码分析的推测，不代表 Anthropic 的实际风控策略。 但它们的分析逻辑有参考价值。

附录 A：红队视角——不合规地区用户规避风控策略手册

这份文档从攻击者视角梳理了规避手段。值得注意的是，即使是站在"怎么绕过风控"的角度，文档也明确指出：伪装而非关闭——关闭遥测本身就是风险信号，最优策略是让信号上报但内容是伪装的。

一、攻击者画像与前提

攻击者拥有的资源

攻击者面对的风控信号（已知）

根据泄露源码和风控策略文档，攻击者知道防守方会采集和分析以下信号：

服务端硬信号（无法从客户端侧消除）：
  - 连接 IP 及地理归属、IP 类型（住宅/机房/VPN）
  - TLS 握手指纹（JA3/JA4）
  - HTTP 指纹（Header 顺序、行为特征）
  - OAuth Token 行为
  - API 调用参数、频率、时间分布
  - 客户端版本号

注册信息（注册时已提交）：
  - 手机号（含国家码）
  - 邮箱
  - 银行卡（BIN 可识别发卡国）
  - 收货地址

遥测信号（客户端可控）：
  - 系统时区、locale、平台、架构
  - Linux 发行版、WSL 版本
  - 终端类型、包管理器、运行时
  - 工具调用行为
  - 进程资源占用

移动端信号（如果安装）：
  - GPS 定位
  - SIM 卡 MCC/MNC
  - 基站定位

二、核心对抗原则

原则 1：全链路伪装，不留短板

风控是多信号交叉验证，任何一层遗漏都会成为突破口。必须逐层伪装，不能只做部分。

原则 2：伪装而非关闭

关闭遥测本身就是一个风险信号。最优策略是让所有信号都上报，但上报的内容是伪装后的合规画像。

原则 3：保持一致性

所有伪装的信号必须指向同一个合规身份。IP 在纽约、时区在洛杉矶、手机号在伦敦——这种不一致比不伪装更危险。

原则 4：保持稳定性

不要频繁更换 IP、身份、设备。频繁变化本身就是异常信号。选定一套合规身份后长期固定使用。

三、分层规避方案

第一层：身份构建（注册阶段）

目标：让注册信息完全指向合规地区，通过注册阶段的筛查。

手机号

方案：获取合规地区手机号

  选项 A：Google Voice 美国号码
    获取方式：需要一个已有的美国号码激活，或通过二手市场购买
    成本：免费（自行注册）或 $5-20（购买）
    风险：Google Voice 号段被部分平台识别为虚拟号

  选项 B：美国 MVNO 实体 SIM 卡
    服务商：Mint Mobile / Tello / Ultra Mobile 等
    获取方式：通过转运购买预付费 SIM 卡
    成本：$15-30/月
    优势：真实运营商号码，不是虚拟号

  选项 C：英国 / 日本等合规地区号码
    根据目标身份选择对应国家的号码

不要使用：
  - +86 中国大陆号码
  - +98 伊朗号码
  - 一次性接码平台号码（容易被识别）

邮箱

方案：使用国际邮箱服务商

  推荐 Gmail（最普遍）
  推荐 Outlook / Hotmail
  推荐 ProtonMail（隐私导向，但不可疑）
  推荐 自有域名邮箱

  不要用 qq.com / 163.com / 126.com / yeah.net / foxmail.com
  不要用 任何中国邮箱服务商域名

注意：
  Gmail 注册时的 IP 和语言设置也应与目标身份一致
  邮箱用户名不要包含拼音姓名

银行卡

方案：获取合规地区发行的支付方式

  选项 A：Wise（原 TransferWise）虚拟卡
    支持美国、英国等多国卡 BIN
    成本：开户免费，使用时有小额费用

  选项 B：Stripe Issuing / Privacy.com 虚拟卡
    美国卡 BIN

  选项 C：合规地区实体银行账户
    如果有海外关系人可协助开户

不要使用：
  - 中国银联卡（62 开头 BIN）
  - 伊朗银行发行的任何卡
  - 通过非正规渠道获取的他人银行卡（违法）

收货地址

方案：使用合规地区地址

  选项 A：美国转运仓地址（如 Anytime Mailbox / US Global Mail）
  选项 B：合规地区朋友/亲属地址
  选项 C：合规地区商业虚拟地址服务

身份一致性检查

所有注册信息必须指向同一个国家/地区：

  一致的示例：
    手机号：美国 +1
    邮箱：Gmail
    银行卡：Wise 美国卡
    地址：美国加州

  不一致的示例：
    手机号：英国 +44
    邮箱：Gmail
    银行卡：Wise 美国卡
    地址：日本东京
    → 多国混杂，反而更可疑

第二层：网络伪装（连接 IP）

目标：让每次 API 请求的源 IP 显示为合规地区的真实住宅 IP。

核心要求

必须满足：
  1. IP 地理归属在合规地区
  2. IP 类型为住宅 IP（不是机房/数据中心）
  3. IP 出口固定或变化范围小（同一城市/ISP）
  4. IP 归属地与注册身份地区一致

代理方案对比

最优方案

优先级：
  1. 自建住宅代理（如果有合规地区的关系人）
     在朋友/亲属家部署一个小设备（树莓派等）作为代理出口
     成本低、稳定、完全不可检测

  2. 高质量住宅代理服务商
     选择不太知名的小型服务商，IP 池被标记概率更低
     务必选择「静态住宅 IP」而非「轮转住宅 IP」

  3. 机房 VPN（不推荐）
     只在其他方案不可用时作为临时过渡

使用纪律

固定使用同一个出口 IP（或同一小段 IP 范围）
IP 归属地与注册信息、时区设置一致
在使用产品的全程保持代理连接

不要频繁切换不同国家的 IP
不要有时走代理有时不走（IP 地理跳变）
不要使用免费公共代理（IP 信誉极差）

第三层：环境伪装（遥测信号）

目标：不关闭遥测，而是让遥测上报的环境画像与合规身份一致。

系统时区

# 设置为与 IP 归属地一致的时区
export TZ="America/New_York"

# 持久化：写入 shell 配置文件
echo 'export TZ="America/New_York"' >> ~/.bashrc

# 验证
date  # 应显示 EST/EDT 时间

关键：时区必须与 IP 归属地一致。 IP 在纽约但时区是 Asia/Shanghai 是最常见的穿帮。

系统语言和 Locale

# 设置为英文 locale
export LANG="en_US.UTF-8"
export LC_ALL="en_US.UTF-8"
export LANGUAGE="en_US:en"

# 持久化
echo 'export LANG="en_US.UTF-8"' >> ~/.bashrc
echo 'export LC_ALL="en_US.UTF-8"' >> ~/.bashrc

# 验证
locale  # 所有项应显示 en_US.UTF-8

Linux 发行版

高风险发行版（中国特有，直接暴露）：
  - deepin
  - UOS（统信）
  - openKylin（开放麒麟）
  - openEuler（华为）
  - EulerOS

安全发行版（国际通用）：
  - Ubuntu
  - Fedora
  - Debian
  - Arch Linux
  - macOS（最不可疑）

如果当前使用高风险发行版：
  方案 A：更换发行版（最彻底）
  方案 B：在 Docker 容器中运行 Claude Code，容器使用 Ubuntu 镜像（推荐，简单且有效）

Docker 容器化方案（推荐）

# 使用标准 Ubuntu 镜像
FROM ubuntu:22.04

# 设置合规环境
ENV TZ="America/New_York"
ENV LANG="en_US.UTF-8"
ENV LC_ALL="en_US.UTF-8"

# 安装必要工具
RUN apt-get update && apt-get install -y \
    nodejs npm curl git locales && \
    locale-gen en_US.UTF-8

# 安装 Claude Code
# ...

包管理器和镜像源

风险点：部分遥测可能采集包管理器信息，间接暴露镜像源配置

检查并替换：
  npm：
    不要用 registry.npmmirror.com（淘宝镜像）
    应该用 registry.npmjs.org（官方源）

  pip：
    不要用 pypi.tuna.tsinghua.edu.cn（清华镜像）
    应该用 pypi.org（官方源）

  apt：
    不要用 mirrors.aliyun.com / mirrors.tuna.tsinghua.edu.cn
    应该用 archive.ubuntu.com（官方源）

命令：
  npm config set registry https://registry.npmjs.org/

遥测信号伪装自查清单

在启动 Claude Code 前逐项确认：

  [ ] TZ 环境变量设置为合规地区时区
  [ ] LANG / LC_ALL 设置为 en_US.UTF-8
  [ ] 发行版为国际通用发行版（或使用 Docker 容器）
  [ ] 包管理器镜像源为官方源
  [ ] 终端语言设置为英文
  [ ] 代理已连接，IP 归属地与时区一致
  [ ] 未设置任何关闭遥测的环境变量

第四层：行为伪装（作息与使用模式）

目标：让 API 调用的时间分布与声称的地理位置一致。

作息时间问题

核心矛盾：
  真实位置：中国大陆（UTC+8）
  伪装位置：美国纽约（UTC-5，即 UTC+8 减 13 小时）

  如果正常工作时间是北京时间 9:00-21:00
  对应纽约时间 20:00-08:00（前一天晚上到第二天早上）

  风控视角：一个「纽约用户」每天晚上 8 点开始工作到凌晨 → 可疑但不绝对异常

应对策略

策略 A：接受「夜猫子」画像
  很多程序员确实是夜间工作者
  纽约时间晚 8 点到凌晨的活跃不算极端异常
  只要不是严格的 UTC+8 9-to-5 模式就不太突出
  评估：中等风险，对于个人用户通常足够

策略 B：选择时差更小的合规地区
  日本（UTC+9）与中国（UTC+8）仅差 1 小时
  → 伪装为日本用户，作息几乎无需调整
  → 但需要全套日本身份（获取难度更高）
  澳大利亚东部（UTC+10/11），与中国差 2-3 小时
  评估：如果能获取对应地区身份，这是最优解

使用模式注意事项

正常的交互式使用模式（有间隔、有停顿）
偶尔的非工作时间使用（真实用户也会有）
合理的 API 调用频率

不要 24 小时无间断调用（明显自动化）
不要精确的整点/半点调用（脚本特征）
不要极端均匀的调用间隔（非人类行为）

第五层：应对版本升级

关键操作：清除所有旧版关闭遥测的痕迹

1. 检查并删除旧环境变量
   env | grep -i telemetry
   env | grep -i otel
   env | grep -i analytics

2. 清理所有 shell 配置文件

3. 正常升级到新版本

4. 不要停留在旧版本（旧版本本身是高风险信号）

方案弱点自评（红队诚实评估）

附录 B：防守方视角——风控策略设计文档

这份文档从风控设计者的角度分析了信号体系、用户分群、打分模型和处置策略。可以帮助你理解"对面是怎么想的"。

一、风控目的

目的 1：反不合规地区用户

禁止受制裁/不合规地区（中国大陆、朝鲜、伊朗等）的用户使用产品，满足美国出口管制和制裁合规要求。

目的 2：反黑产

打击逆向产品、批量注册、额度倒卖等黑产行为，减少经济损失。

二、当前现状与约束条件

客户端形态

源码泄露事件

• Coding Agent 的当前版本源码（cli.js.map）已被逆向泄露
• 泄露内容包括遥测上报逻辑和通过环境变量关闭遥测的方法
• 泄露信息主要在中文社区传播，已有用户据此关闭遥测

服务端天然可见的信号（不受遥测开关影响）

无论客户端是否关闭遥测，服务端每次 API 请求必然可见：

• 连接 IP 及地理归属
• IP 类型（住宅 / 机房 / VPN / 代理）
• TLS 握手指纹（JA3/JA4）
• HTTP 指纹（Header 顺序、行为特征）
• OAuth Token 及账号身份
• API 调用参数（模型、token 用量）
• 客户端版本号
• 请求时间戳

注册阶段已采集的信息

• 注册手机号（含国家码）
• 注册邮箱
• 付款银行卡（BIN 可识别发卡国）
• 收货地址

三、用户分群模型

根据两个维度（是否安装移动端、是否关闭遥测），用户自然分为四群：

                      遥测开启                遥测关闭
                ┌────────────────────┬────────────────────┐
  有移动端      │  A 群：信号最全      │  B 群：移动端兜底    │
                │  识别难度：★☆☆☆☆   │  识别难度：★★☆☆☆   │
                ├────────────────────┼────────────────────┤
  无移动端      │  C 群：依赖遥测画像  │  D 群：仅剩服务端    │
                │  识别难度：★★★☆☆   │  识别难度：★★★★★   │
                └────────────────────┴────────────────────┘

四、「关闭遥测」作为风控信号的逻辑论证

信息传播的地域偏向性

源码泄露后，「关闭遥测教程」主要通过中文社区传播。这意味着接触到该信息的用户群体本身就不是地域均匀分布的。

动机强度的不对称性

贝叶斯推理

P(不合规地区 | 关闭遥测)

    P(关闭遥测 | 不合规地区) × P(不合规地区)
= ─────────────────────────────────────────
              P(关闭遥测)

其中：
  P(关闭遥测 | 不合规地区) → 极高（信息触达 + 求生动机）
  P(关闭遥测 | 合规地区)   → 低（多数人不知道，知道的也缺乏强动机）

结论：「关闭遥测」是识别不合规地区用户的高权重信号。

五、版本升级策略：制造筛查窗口

新版本的三个关键动作

升级后用户的三种表现

表现 1：升级新版本 + 未检测到旧环境变量 → 之前未关闭过遥测的普通用户，正常处理

表现 2：升级新版本 + 检测到旧环境变量存在 → 曾主动关闭遥测，同时获得动机信号和恢复后的环境画像

表现 3：拒绝升级 / 停留旧版本 → 刻意维持遥测关闭状态，宽限期后 API 拒绝服务

六、综合打分模型

信号权重表

处置分级

七、反黑产专项策略

八、避免误伤的保障机制