地址栏里的完整链接，并不等于可以外发的链接
运营把落地页发给同事、客服把用户投诉里的网址贴进工单、开发把复现步骤写进聊天——这三件事里，最省事的动作都是：从地址栏全选，复制，粘贴。地址栏展示的是当前文档的完整 URL。按 WHATWG URL 的拆法，它至少包含协议、主机、路径、查询串（? 后面）和片段（# 后面）。片段默认不进 HTTP，上一篇已经写过；查询串会进请求行，也会跟着复制一起走。
问题出在查询串经常不是业务必需。你点开的可能是一封带跟踪的邮件、一条付费广告，或社交平台自动追加了点击标识的卡片。落地页本身只需要 /product/42，地址栏却变成 /product/42?utm_source=summer-mailer&utm_medium=email&utm_campaign=summer-sale&fbclid=…。对分析系统来说，这是一次可归因的访问；对下一个读到这串字符的人来说，这是一份不该出现在工单里的侧写：从哪条活动进来、是不是刚点过广告、邮件服务商有没有给这名收件人编过号。
HTTPS 只保护传输过程中的窃听。它不擦掉地址栏、浏览器历史、聊天记录、截图和服务器访问日志。OWASP 对「查询串信息暴露」写得很直：即使用了加密通道，查询串仍会出现在 Referer、Web 日志、共享系统、浏览器历史、缓存和肩窥场景。外发前要处理的，不是「这个站安不安全」，而是「这一串问号后面有没有不该离开当前标签页的标签」。
UTM 写的是活动，点击 ID 写的是这一次点击
两类参数经常混在同一条 URL 里，职责不同，外发时的风险也不同。第一类是你（或投放平台）主动写上去的活动标签。Google Analytics 帮助中心把它们叫 campaign parameters，并给出标准例子：https://www.example.com/?utm_source=summer-mailer&utm_medium=email&utm_campaign=summer-sale。官方说明要求：只要加参数，就应当同时使用 utm_source、utm_medium 和 utm_campaign；另外还有 utm_id、utm_term、utm_content、utm_source_platform 等扩展项。值区分大小写：utm_source=google 和 utm_source=Google 在报告里会拆成两行。
这类标签通常不编码单个用户。它们描述的是渠道和战役：来自哪封邮件、哪次夏季促销、邮件里的上链接还是下链接。即便如此，把它们贴进对外聊天仍然会泄露内部投放结构。接收方能读出你在推哪条活动、用的是邮件还是付费点击，也能据此猜测你的获客路径。对竞品或无关第三方，这已经超过「打开这个页面」所需要的信息。
第二类是广告或邮件平台自动追加的点击标识。常见名字包括 Google Ads 的 gclid、Display & Video 360 的 dclid、iOS 场景下的 gbraid / wbraid、Meta 的 fbclid、Microsoft Ads 的 msclkid、X 的 twclid，以及邮件服务商常用的 mc_eid。它们的设计目标是把「这一次点击」缝回平台自己的投放记录，而不是给你看一句人话。值对接收方不可读，对平台可读。把带 fbclid 或 gclid 的整串转发给别人，等于把一次可拼接的点击凭证交了出去；mc_eid 一类则更接近「这封邮件发给了哪一条收件人记录」。
还有第三层：站点自己的归因或分享参数。中文电商和内容站常见 spm、scm、pvid、share_token、refer_share_id。它们不是 Google 的 UTM 规范，但同样会让一条「看起来只是商品页」的链接带上分享路径或推荐人痕迹。外发策略如果只删 utm_*，这一层仍会留下。
| 类型 | 典型键 | 外发时的问题 |
|---|---|---|
| 活动标签 | utm_source、utm_medium、utm_campaign |
泄露渠道和战役名称，不是打开页面所必需 |
| 点击 / 收件标识 | gclid、fbclid、mc_eid、msclkid |
可被平台拼回单次点击或收件人记录 |
| 站内归因 | spm、pvid、share_token |
带出分享路径或推荐痕迹 |
| 业务参数 | id、q、sku、page |
通常要保留，删了页面会打不开或结果不对 |
查询串会落到哪些地方
CWE-598（当前标题是 Use of HTTP Request With Sensitive Query String）把问题写成：敏感信息放进了查询串。它会进浏览器历史、经 Referer 传给其他站点、写进 Web 日志，或在别的记录里留下副本。条目在 2026 年 4 月的 4.20 版里改过名字，强调不只 GET 会带查询串，POST、PUT、DELETE 同样可以。缓解建议写得很具体：敏感数据放进请求体或请求头，而不是查询串。
营销参数多数算不上口令或会话令牌，但暴露面是同一套。你把完整 URL 贴进即时通讯，至少会产生这些副本：聊天服务商的消息存储、接收方的本地记录、若再被转发则是下一跳的存储。若接收方点开它，目的站的访问日志会记下带参数的请求行；若该页再加载第三方脚本或图片，还可能把完整 URL 放进 Referer，送给广告或分析域名。OWASP 列举的「共享系统」在公司内部尤其常见：工单、文档、错误监控、会话回放。一条本该只用于复现的链接，会在这些系统里按明文检索得到。
这也是为什么「我们站点用了 HTTPS」回答不了外发问题。HTTPS 让路径上的观察者更难读出明文；它不阻止你自己把明文贴进下一个系统。CWE-598 举过的真实缺陷包括：安全摄像头把密码放进查询串、通信产品把访问令牌放进 GET。那些是更严重的同类错误。UTM 和点击 ID 的危害通常更轻，但机制相同：问号后面的内容默认会被人复制、被系统记录。
不要用带登录态、重置密码或一次性令牌的真实链接做演示。需要对照参数时，用已经公开的商品页或文档页，自己在查询串后追加可丢弃的测试值，例如 utm_campaign=canary-2026。
Referer 会把问号后面的内容带给第三方
复制粘贴是主动外发。还有一种被动外发：接收方打开页面之后，浏览器按默认策略把「我从哪来」告诉后续请求。这个头的标准名字是 Referer（少一个 r）。MDN 的 Referer 隐私说明举过典型例子：重置密码页脚有社交链接，点出去就可能把带令牌的地址交给社交站点；页面里嵌的第三方图片，也可能把当前完整 URL 送给图片所在的域名。
浏览器用 Referrer-Policy 决定送多少。Chrome 等引擎的默认值是 strict-origin-when-cross-origin：同源请求可以带完整 URL（含路径和查询串），跨源且不降级时只送源（协议 + 主机 + 端口），从 HTTPS 跳到 HTTP 则不送。web.dev 的 Referrer 实践把这条写成兼顾隐私和可用性的默认。它能挡住「把完整查询串送给另一个域名」的一部分情况，挡不住同源分析请求，也挡不住站点把政策设成 unsafe-url 或完全不设、而旧客户端仍送全 URL 的情况。
对「我只是把链接发给同事」这件事，Referer 的意义是：同事一点开，你贴出去的 utm_* 和点击 ID 可能再走一程。若落地页有第三方像素、客服挂件、CDN 上的字体，策略一旦允许送全 URL，这些参数就会出现在那些域名的日志里。外发前先剥掉查询串里的追踪项，等于同时减少两跳泄露：聊天记录里的明文，以及打开之后可能发出的 Referer。
和片段的对比值得再写一句。密钥如果放在 # 后面，按 HTTP 报文设计不会进请求行，也就不会进 Referer 的常规实现。查询串没有这层保护。把活动标签和点击 ID 放在 ? 后面，是为了让服务器和脚本读到它们；这也正是它们会进日志的原因。需要核对「问号进请求、井号默认不进」时，步骤见URL 的井号后面为什么适合放密钥，以及什么时候会失效。
系统会自动剥一部分，但不能当成外发策略
从 iOS 17、iPadOS 17 和对应的 macOS 开始，Apple 在邮件、信息和 Safari 无痕里提供链接跟踪保护。Apple 隐私功能页的表述是：某些网站会在 URL 上追加用于跨站追踪的额外信息；在信息里分享链接时会去掉这些信息，以免追踪你或接收方；Safari 无痕浏览也会在你浏览时去掉加在 URL 上的跟踪。Apple 的 Privacy Features 把这件事写成系统能力，而不是给你一份参数名单。
Apple 没有公布完整剥离清单。社区测试（例如 PrivacyTests.org 一类对照）常提到 gclid、fbclid、mc_eid、twclid、dclid；utm_source 等活动标签通常会留下。覆盖范围也有边界：常规 Safari、第三方浏览器、应用内 WebView 并不等于邮件 / 信息 / 无痕这三条路径。对方用 Android、用桌面 Chrome、从 Slack 或微信点开，都不会自动替你剥。
所以「手机已经会去掉追踪参数」只能写成：在特定系统、特定应用里，一部分点击标识可能在打开前被删。它不能写成：你贴进工单的那一串已经被处理过。外发发生在复制的那一刻，发生在操作系统还没介入的地方。要控制的是剪贴板里的字符，不是接收方设备会不会再剥一次。
该剥什么，该留什么
一条可执行的规则是：先问「没有这个键，页面还打不打得开」。商品 id、搜索 q、分页 page、语言 lang、文档锚点对应的业务查询，删了会改变资源。活动标签、点击标识、邮件收件人编号、分享令牌，删了通常只改变归因，不改变页面本身。
第二问是「这条链接要完成什么任务」。发给同事复现缺陷，对方需要的是稳定的资源地址，不需要知道你来自 utm_campaign=summer-sale。发给用户「请打开这个商品」，对方需要 sku，不需要你刚刚点过的 gclid。只有当你的任务就是「请对方从这条带参活动链接进入，以便我们统计这次转发」，才应该保留 UTM；即便如此，也不该附带你自己的点击 ID。
手工删很容易漏。一条真实投放链接可能同时有五六个 utm_*、一个点击 ID、两三个站内归因。肉眼从右往左擦，经常擦掉 id，却留下 fbclid。更稳的做法是按键名规则处理：凡是 utm_ 前缀一律去掉；再去掉已知的点击 ID 表；若任务允许，再去掉常见分析键（_ga、_gl、mc_eid、mkt_tok）和常见电商归因。路径、主机、业务查询保留。做完之后对照「已删除键名清单」，而不是只看结果是不是「短了一些」。
保守和标准是两种不同的风险偏好。保守：只动 UTM 和点击 ID，尽量不碰站内自定义键，避免把尚未认识的业务参数误删。标准：再加上常见分析和电商归因，适合把链接发到公司外部或公共区域。两种都不能声明「已经匿名」。页面路径本身可能含用户名，查询串里的 email= 也不在 UTM 表里。规则清洗解决的是已知追踪键，不是任意敏感字段。文本里的手机号、证件号、密钥要另做脱敏，不能指望剥 URL 参数一并完成。
写给同事的最短可用句子：复现用路径 + 业务参数；统计用 UTM，且不要附带自己的点击 ID。拿不准时先剥 utm_* 和 *clid，再人工看剩下的键。
当场核对：对照剥离清单，再搜 Network
口号写「本地清洗、不上传」无法自证。能当场看到的是三样东西：哪些键被删了，哪些键还在，以及你的原始 URL 有没有作为业务数据出站。
先准备一条金丝雀。打开一个不会涉及真实客户的公开页，在地址后追加 ?utm_source=canary-share&utm_medium=email&utm_campaign=canary-2026&fbclid=canaryclid&id=42。把整串贴进清洗输入。跑完后，结果里应当看不到四个追踪键，应当仍能看到 id=42。若工具给出「已剥离」列表，逐项核对这些名字，不要只看最终 URL 变短了。
再打开开发者工具的 Network，勾选 Preserve log，在过滤器里粘贴 canary-share 或整段金丝雀查询串。XHR / Fetch 的请求行、查询串和请求体都不该出现它；访问统计的 query 与 body 同样不该出现。静态资源、样式和脚本可以出现——那是页面自己的文件。原文作为业务字段出站，才算失败。标题或路径里出现「隐私」「清洗」字样是预期，输入框全文不是。
- 构造带
utm_*、fbclid和业务id的金丝雀 URL，不要用真实客户或未公开活动名。 - 清洗后核对照表：追踪键应在「已删除」一侧，
id应在结果 URL 里。 - 用金丝雀字符串搜索 Network；命中任意业务请求即说明原文离开了标签页。
这套步骤证明的范围很窄：这一次操作里，已知追踪键按规则消失，业务键还在，原文没有作为已观察到的 HTTP 字段离开当前标签页。它不证明扩展程序没有读输入框，也不证明未列入规则的自定义追踪键已被处理。换浏览器或换规则表之后，值得再跑一遍金丝雀。
用打开即用的清洗页把规则练熟
若你希望用一个把剥离清单写在页面上的工具来练习，可以从 MakePwd 的隐私清洗开始。打开即可使用，无需注册，也没有账号。URL 解析和参数剥离发生在当前标签页；原文按产品说明不作为请求发出，也不会写入 analytics。标准模式去掉 utm_*、广告点击 ID、常见分析参数，以及淘宝、拼多多、抖音等场景里常见的归因键；保守模式只去掉 UTM 和点击 ID。路径和 id、q 这类业务参数会保留。一次最多 100 条，单条超过 8 KB 会被拒绝，只接受 http 或 https。
练习时用上面的金丝雀，不要用正在投放的真实点击 ID。跑完同时看两处：右侧或结果区的剥离清单，以及 Network 里有没有原文。清单是给「删对了没有」用的；Network 是给「有没有上传」用的。两处都过，才能向同事解释：我删的是这些键，我搜过金丝雀没有出站。
清洗只处理链接形态。聊天记录或工单正文里的手机号、证件号、邮箱、API Key，要切到同一页的数据脱敏，按模式做掩码，并且仍然需要人工复核。MakePwd 不声称 GDPR 或等保认证。若清洗完仍是一段必须保密的内容，用阅后即焚一次性发送，密钥留在 URL 的 # 片段；整份文件则用文件加密盒在本机做成 .lock / .enc 再走网盘或邮件。这些步骤都不要求登录。
常见问题
去掉 UTM 之后，接收方还能打开页面吗？
能，只要业务参数和路径还在。UTM 和点击 ID 服务归因，不服务路由。删掉 utm_campaign 或 fbclid，落地页仍应按路径和 id 打开。若删完 404 或结果变了，说明误伤了业务键，应退回保守模式并逐个对照。
HTTPS 是不是已经保护了这些参数？
没有保护到外发这一步。HTTPS 降低传输中被窃听的风险，不擦地址栏、历史、聊天和日志。OWASP 写明：即便走加密通道，查询串仍会出现在 Referer、Web 日志、共享系统和浏览器历史里。该不该贴完整链接，和站点有没有证书是两件事。
苹果会自动去掉追踪参数，我还要自己剥吗？
要。系统能力作用在邮件、信息和 Safari 无痕等路径，且不公布完整名单；UTM 通常会留下。你把链接贴进工单或安卓设备上的聊天时，这些保护不会替你执行。外发策略看的是剪贴板内容，不是接收方系统会不会再剥一次。
干净链接会不会把商品 id 也删掉？
按键名规则时不应该。id、q、sku 不是 utm_ 前缀，也不在常见点击 ID 表里。核对方法是金丝雀里同时放追踪键和业务键，看结果是否只少了前者。若某站把追踪写进自定义键名，规则表不会认识它，需要人工删或扩充名单。
下次外发前记住的三件事
第一，地址栏全选不等于可以外发。问号后面先分成活动标签、点击 ID、站内归因和业务参数，只有最后一类默认该留。第二，HTTPS 和系统自动剥离都不代替你检查剪贴板；查询串会进历史、工单、日志，并可能经 Referer 再走一程。第三，核对看两处：已删除键名清单，以及用金丝雀搜索 Network。
若你还要继续追问「明文有没有作为业务数据离开这个标签页」，请读浏览器里做加密，怎么当场核对明文没有离开本机。本文只把「完整链接里哪些查询串不该跟着外发」收成可以写进结论的范围。