有些开发工具最别扭的地方，不是它会收集遥测，而是你想关掉它时，得像背一张厂商暗号表。
.NET 要设 DOTNET_CLI_TELEMETRY_OPTOUT=1。Azure CLI 是 AZURE_CORE_COLLECT_TELEMETRY=0。Gatsby 是 GATSBY_TELEMETRY_DISABLED=1。Homebrew 是 HOMEBREW_NO_ANALYTICS=1。Go 还要跑 go telemetry off。Netlify CLI 又是另一套命令。
donottrack.sh 现在提了一个很小的倡议：统一用 DO_NOT_TRACK=1。用户在系统环境里声明一次，CLI、SDK、框架和本地软件就应该理解：我不想被追踪。
这件事不复杂。也正因为不复杂，才扎眼。
它要关掉什么：不是禁止联网，而是拒绝非必要回传
这个提案的边界很清楚。看到 DO_NOT_TRACK=1 后，软件应该关闭这些行为：
| 类型 | DO_NOT_TRACK=1 下的含义 |
|---|---|
| 广告跟踪 | 应关闭 |
| 使用报告 | 应关闭，匿名和非匿名都算 |
| 遥测数据 | 应关闭 |
| 崩溃报告 | 应关闭 |
| 非功能必需的网络请求 | 应关闭 |
| 下载依赖、登录验证、同步数据等功能请求 | 不在禁止范围内 |
最后一行很重要。
它不是说软件不能联网，也不是把所有数据回传都打成恶意监控。下载依赖、验证账号、同步配置，这些可能就是功能本身。它针对的是另一类东西：本地软件本来能工作，但仍然顺手把使用情况、崩溃信息、统计指标发回去。
设置方式也很朴素。
| 环境 | 设置方式 |
|---|---|
| Bash / Zsh | export DO_NOT_TRACK=1 |
| Fish | set -x DO_NOT_TRACK 1 |
| PowerShell | $env:DO_NOT_TRACK = "1" |
| Windows CMD | setx DO_NOT_TRACK 1，或写入系统环境变量 |
这不是浏览器时代旧 DNT 机制的复活。不要混为一谈。
它更像 NO_COLOR、FORCE_COLOR 这类轻量约定：没有复杂协议，没有中心化审批。大家认一个变量名。工具作者愿意尊重，用户就少背一组暗号。
受影响的人也很具体。
开发者和命令行重度用户，可以先把 DO_NOT_TRACK=1 放进 shell 配置或系统环境变量里。然后看新装 CLI、SDK、框架的文档：它是否识别这个变量？是否还有单独的遥测开关？如果团队对网络回传敏感，还可以在 CI、开发容器、基础镜像里统一设置。
CLI、SDK、框架维护者要做的事更直接：保留原有关闭方式，同时识别 DO_NOT_TRACK=1。文档里写清楚收集什么、何时收集、怎么关闭。再进一步，默认不收集，改成 opt-in。
这才是对用户有用的隐私设计。
真问题不是不会做开关，而是默认收集太顺手
我更在意的不是 DO_NOT_TRACK 这个名字有多好，而是它把一个被拆碎的问题重新拼了起来。
今天的混乱不是技术能力不足。各家工具能做关闭开关，也已经做了。问题是每家都把开关藏在自己的变量名、命令、配置文件里。
用户想退出，就得逐个查文档。逐个设置。逐个验证。还得担心漏掉哪个新装的工具。
这叫成本转嫁。
厂商拿默认收集的好处：产品指标、功能使用率、崩溃分布、增长漏斗。用户承担退出成本：搜索、配置、怀疑、重复劳动。表面看是“给了选择”，实际是把选择切碎，撒在每个工具的角落里。
“天下熙熙，皆为利来。”这句话用在这里不算重。
很多遥测并不邪恶。开源项目和工具团队也确实需要数据，才能知道功能有没有人用、哪里崩得最多、文档是不是误导用户。站在维护者角度，完全没有数据也会痛苦。
但默认收集一旦成为惯性，激励就会滑坡。
先说匿名，后来想要更细。先说诊断，后来顺手做分析。先说改善体验，后来数据变成产品决策的硬指标。
真正危险的不是某一次上报，而是默认权力的位置。
DO_NOT_TRACK=1 的价值就在这里。它把用户的全局意愿放到所有工具前面，而不是让用户适配每个厂商的词典。它不要求工具作者放弃数据，只要求他们在看到明确信号时停手。
这要求很低。
低到如果一个工具连这都不愿意做，用户就该重新评估它的边界感。
变量本身没有执法权，关键看维护者是否认账
这个倡议目前仍是倡议。不能写成行业已经广泛采用。也不能幻想设一行变量，所有工具突然变得克制。
环境变量没有执法权。软件作者不检查它，它就只是一行躺在 shell 配置里的文本。
这里有几个现实约束。
| 约束 | 对用户意味着什么 | 对维护者意味着什么 |
|---|---|---|
| 采用不确定 | 不能只设变量就以为万事大吉 | 需要明确声明是否支持 |
| 旧开关仍存在 | 可能还要同时设置厂商自己的变量 | 不该废掉原有退出路径 |
| 子进程和 CI 环境有差异 | 要确认变量是否传进实际执行环境 | 文档要覆盖 shell、CI、容器等场景 |
| 必要联网与遥测边界可能模糊 | 需要看清工具到底回传什么 | 不能把统计请求伪装成功能必需 |
所以接下来最该看的，不是这个变量名漂不漂亮，而是工具作者是否把它写进代码和文档。
用户可以做两件小事。
一是先设全局 DO_NOT_TRACK=1。二是装新工具时看遥测说明。如果一个 CLI 连“收集什么、怎么关闭”都写不清，别急着把它放进团队脚手架、CI 镜像或企业开发环境。
维护者也有一条简单路线：识别 DO_NOT_TRACK=1，不破坏原有配置；必要联网继续保留，非必要统计默认停手；收集范围写清楚，不要藏在安装过程和首次运行后面。
小标准最怕无人理会。但小标准也常常有力。
NO_COLOR 能活下来，不是因为它复杂，而是因为它替用户说出一句很简单的话：别替我做决定。
DO_NOT_TRACK=1 也是这句话。
它表面上是在关遥测，实际问的是开发工具行业一个老问题：本地软件，到底还属于用户多少？