我有个用了两年的习惯：往外发链接之前，先把问号后面那一长串删掉。
大部分时候它工作得很好，直到有一次我把一条小红书笔记发给朋友，对方回我一句「打不开」。我自己点，也打不开。折腾半天才发现，我删掉的那串 xsec_token 不是统计参数，是这条链接的通行证。
那次之后我意识到，「问号后面全删」这条口诀虽然省事，但它把三类完全不同的东西当成了一类。想删得干净又不把链接删坏，得先知道自己在删什么。
以小红书为例，同一条笔记的三种形态：
① 完整链接，正常打开（链接已脱敏）
② 只删掉 xsec_token，其余全留——打不开
③ 只留笔记 ID 和 xsec_token——正常打开
https://www.xiaohongshu.com/discovery/item/【笔记ID】?xsec_token=【令牌】
第 ② 张是关键。它和 ① 的唯一差别就是少了 xsec_token，说明打不开的原因不在那十个参数上。而 ③ 反过来证明，除了笔记 ID 和这个令牌，其余的删光也不影响访问。
问题就在这儿：xsec_token 长得和一堆追踪参数混在一起，名字也不像定位参数，但它是这条链接的通行证。
参数其实分三类
打开任何一条带参数的链接，问号后面的东西大致逃不出这三种。
定位参数告诉服务器你要的是哪个内容。删掉链接就失效，这是硬边界。
功能参数不影响能不能打开，但影响打开之后是什么样。比如视频从第几秒开始播、翻到第几页、用哪种排序。删掉链接还在，只是回到默认状态。
追踪参数只对平台有用，对你和收件人都没用。它记录这条链接从哪来、被谁分享、通过什么渠道传播。删掉对阅读体验零影响。
真正该删的只有第三类。第二类看情况——你想让朋友从第 3 分 20 秒开始看，那个时间戳就得留着。第一类碰不得。
麻烦在于，这三类经常长得很像，偶尔还混在同一个参数里。
边界在哪：平台逐个看
YouTube 的划分最干净。watch?v= 后面那串是视频 ID，属于定位，必须留。&t=90s 是跳转时间，功能参数，看需要。?si= 是分享来源标识，2023 年 9 月起随分享按钮自动附加，每次分享生成的值都不一样，且与生成它的账号绑定——追踪参数，随便删。短链 youtu.be/xxx 本身就是干净的，后面跟的 ?si= 照删不误。
（近期有资料提到 si 被 is 取代，作用相同，看到哪个都照删。）
B 站把定位信息放在路径里，bilibili.com/video/BV1xx411c7mD 这一段就是完整地址，问号后面的东西一个都不需要。?t= 时间戳和 ?p= 分 P 是功能参数按需保留。
B 站的例子更能说明问题。从 app 里点「复制链接」，得到的是一条短链：
https://b23.tv/【七位短码】
看着很干净。但它跳转之后是这样：
https://www.bilibili.com/video/BV1Uh411p7r3/?buvid=【设备指纹】&mid=【你的UID】&p=1&plat_id=116&share_from=ugc&share_medium=iphone&share_plat=ios&share_source=COPY&share_tag=s_i&unique_k=【七位短码】&up_id=407054668
删到只剩定位信息，打开的是同一个视频：
https://www.bilibili.com/video/BV1Uh411p7r3
多出来的那一串里，share_medium 和 share_plat 说明你用 iPhone 分享的，share_source=COPY 说明你是复制而不是转发的。真正要紧的是另外两个：buvid 是设备指纹，同一台设备分享的所有链接都带同一个值；mid 是 base64 编码的你的 B 站 UID，解码就是账号。
网页端复制出来的链接则是另一个字段 vd_source，值为 UID 的 MD5 哈希。作用一样，都是把你标记出来。这个参数 2022 年 6 月上线，ClearURLs 当月就加了清除规则。
最后注意 unique_k 这个字段——它的值和短链末尾那七位是同一个。也就是说，短码本身就是查表的钥匙，表里存的正是上面这一整串。你发出去一个七位短码，等于发出去了你的设备指纹和账号 ID。
小红书就是让我翻车的那个。笔记 ID 在路径里，但从 2024 年起还需要 xsec_token 才能访问。它是平台用来防批量爬取的动态令牌，有时效、与具体笔记绑定，功能上属于定位那一类。这个必须留，同时出现的 xsec_source（标记链接来自 app 分享还是网页信息流）和各种 share 开头的字段可以删。
微信公众号文章看着参数最多最吓人，能删的其实不少。__biz（公众号 ID）、mid（图文消息 ID）、idx（这次群发的第几条）、sn（防遍历的随机签名串）四个联合定位一篇文章，缺一不可。但后面那个七十多位的 chksm 虽然名字叫校验和，实测略去并不影响访问，可以删。再往后的 scene、srcid、mpshare、key、pass_ticket、uin 全是场景和临时参数，一并删掉。
知乎的回答链接 zhihu.com/question/问题ID/answer/回答ID 本身就够用了。后面的 utm_source、utm_medium 可删，其中 utm_member 尤其该删——它对同一个账号是固定不变的，等于把你的知乎身份贴在了链接上。
X（Twitter）的 ?t= 是编码后的分享者用户 ID，?s= 记录你从哪个设备分享（s=20 是网页、s=19 是安卓），两个都能删。在 iOS 上长按分享按钮而不是直接点，系统会自动去掉 t。Instagram 的 igshid 和它的新版 igsh、igsi 同理。Spotify 的 ?si= 和 YouTube 重名但作用一样，也是与账号绑定的分享标识。
电商类普遍很宽松。淘宝商品页只需要 id=，亚马逊只需要路径里 /dp/ 后面那串十位的 ASIN，京东是 item.jd.com/商品编号.html，剩下的 ref、spm、scm、ut_sk、tag 全是追踪。
通用规则：utm_ 开头的一整族是营销归因的行业标准字段，任何网站上看到都能删。同类的还有各家广告系统的点击标识 fbclid（Facebook）、gclid（Google）、msclkid（微软），以及邮件营销的 mc_cid、mc_eid。
短链是另一套逻辑
前面讲的都建立在一个前提上：你看得见参数。短链把这个前提取消了。
先说清楚一件事，短链不是加密。它的原理是查表——服务器存了一张「短码对应哪条长链」的映射，你访问 b23.tv/xxx，它返回一个 302 跳转，把你送到真实地址。短码本身不含信息，只是一个索引号。（真正做了编码的是某些参数的值，比如前面提到的 vd_source 是 MD5 哈希，但哈希单向不可逆，也算不上加密。）
问题在于，短码本身可能就是身份。同一个视频，你分享和别人分享，生成的短码往往不一样，因为它们映射的是各自带着不同参数的那条长链。所以短链没法清理，删无可删。
按处理方式分三种。
纯跳转型，比如 youtu.be。短码就是内容 ID，本身干净，后面跟的 ?si= 删掉就行。
参数隐藏型，比如 b23.tv。看着干净，展开之后 vd_source 那一串全在。这类要先展开，再按前面的规则删。
身份绑定型，比如 xhslink.com、v.douyin.com。短码是为这次分享单独生成的，本身就承载来源信息。这类清理不了，只能重建——展开拿到内容 ID，自己拼一条规范链接。小红书 2025 年 6 月还把短链前缀从 /a 改成了 /m，这块平台一直在调。
还有一类严格说不算链接：淘口令和抖音口令码，就是夹在分享文案里那种 0.79 pQx:/ P@K.jP。它靠 app 监听剪贴板触发，没有参数可删，唯一的处理办法是整段删掉换成正常链接。这个反而最该注意——很多人复制分享文案的时候会连着口令一起发出去，完全没意识到它在那儿。
展开短链有三种办法，按省事程度排：
- 浏览器里直接点开，看地址栏跳转后变成了什么，最省事
- 命令行
curl -sI 'https://b23.tv/xxx' | grep -i location，只发 HEAD 请求，不加载页面内容 - iOS 快捷指令用「获取 URL 标头」动作取
Location字段，详见后面自动化那节
一句话：长链是删，短链是还原。
遇到陌生参数怎么判断
上面这些是记得住的，但你不可能记住所有平台。
三个可复用的办法，从省事到费事排：
看 canonical 标签。 大部分网站会在页面源码的 <head> 里放一行 <link rel="canonical" href="...">，这是网站自己声明的规范地址，通常就是最干净的形态。直接复制它，不用猜。
二分删除法。 把问号后面全删，在无痕窗口打开。能开，说明全是可删的；打不开，就把参数加回一半再试。三四轮就能定位到那个必需的字段。
关键是必须用无痕窗口。你自己的浏览器带着登录状态，很多链接就算参数不全也能打开，测出来的结论对别人不成立。
看参数名。 语义往往很直白。带 utm_、以 clid 结尾、或者叫 source、from、share、ref、spm、channel、campaign 的，基本都是「来路」的意思，放心删。带资源 ID 语义的（id、v、goods_id）和带 token、sign、signature、key 的要当心，前者是定位，后者可能是访问凭证——小红书的 xsec_token 就属于这一类。
至于 chksm 这种名字像校验、实际能删的，只能靠实测。命名规律是概率，不是保证。
把它自动化
手动删两次就够烦了，值得交给工具。但 2026 年这块的形势变了，得分平台讲。
桌面浏览器
过去这件事的标准答案是 ClearURLs，一个维护了多年的开源扩展，靠一份社区规则库自动剥离地址栏里的追踪参数。
但它现在只在 Firefox 上能用。ClearURLs 的底层是 Manifest V2，官方文档里已经写明 Chrome、Edge、Brave 会随着 MV2 退场而停用它，而项目那个「迁移到 MV3」的议题在 GitHub 上被标记为「不计划」关闭了。扩展本体最后一次更新停在 2025 年 2 月。
Chrome 系用户现在的选择是：
- uBlock Origin Lite，MV3 版本，配合「AdGuard URL Tracking Protection」这类过滤列表可以做参数剥离。功能比完整版 uBO 弱，因为 MV3 只允许声明式规则。
- AdGuard 浏览器扩展的 MV3 版本，自带 URL 追踪防护模块。
- 换回 Firefox，用官方 ClearURLs 或完整版 uBlock Origin。后者支持写自定义规则，比如
||youtube.com^$removeparam=si。
iOS：自建快捷指令
iOS 上最顺手的做法是做一个接管系统分享菜单的快捷指令。核心是七步。
接收输入：打开「在分享表单中显示」，输入类型只勾选 URL。有分享输入就用它，没有就读剪贴板。
判断是否短链：取出 Host，只有当它是 b23.tv、xhslink.com、v.douyin.com、t.cn、dwz.cn、url.cn、youtu.be 之一时，才调用系统自带的「展开 URL」动作。
这一步的限定条件是我踩坑踩出来的。最初我对所有链接无差别调用「展开 URL」，结果小红书链接直接变成了一个 404 页面——「展开 URL」不是本地操作，它会向服务器发一次真实请求，而小红书对非浏览器请求做了拦截，返回的错误页被当成了「展开结果」，原链接就此报废。长链接本来就不需要展开，所以这个动作必须锁死在已知短链域名上。
剥离追踪参数：「替换文本」动作，务必打开正则表达式开关。
(\?|&)(utm_[^&]+|fbclid|gclid|msclkid|igshid|igsh|igsi|si|is|spm|spm_id_from|vd_source|share_source|share_medium|xsec_source|mc_cid|mc_eid|chksm|scene)=[^&]+
按值匹配的两条特例，各自单独一个「替换文本」：
(\?|&)mid=[^&]*%3D%3D
(\?|&)type=normal
为什么不把 mid 直接写进上面那份名单？因为它在两个平台上含义相反——B 站的 mid 是你的 UID，微信公众号的 mid 是文章定位参数，删了文章就打不开。但两者的值形态不同：B 站是 base64、末尾带 %3D%3D 填充，微信是纯数字。所以按值匹配，一条规则同时照顾两边。type=normal 同理，type 这个词太通用，很多网站拿它做功能参数，只锁定小红书用的那个具体值才安全。
修复残缺的问号，三条规则依次执行：
\?&+ → ?
&&+ → &
[?&]+$ → （空）
再补最后一条，而且必须放在所有替换的最末尾：
^([^?]*)& → $1?
这条也是踩出来的。当第一个参数被删掉时，它前面的 ? 会跟着一起消失，剩下的链接变成 /path/&mid=xxx 这种畸形形态。这条规则把第一个残留的 & 提升回 ?。但它一开始被我放在中间执行，结果和后续的删除动作打架，产出了 /path&a=b?c=d 这种更离谱的东西。放在最后，才能保证只剩一个 & 需要提升。
输出：拷贝到剪贴板，显示通知。
三张配图对应输入、展开、清理三段。
结构上参考了 RoutineHub 上一个叫 URL Transparency and Privacy 的快捷指令对「展开 URL」动作的用法。
接收分享或读取剪贴板：
仅对已知短链域名调用 Expand：
按名单剥离追踪参数，最后修复问号：
这里必须提醒一句：上面是黑名单思路，天然有漏网和误伤两种风险。名单外的新参数删不掉，而万一某天某个平台把必需字段起了个像追踪的名字，就会被误删。想稳妥的话应该反过来做白名单——只保留已知必需的参数，其余全丢。代价是每个平台都得单独写规则。
不想自己搭的话，App Store 上有 Clean Links 这类现成方案，装完直接在分享菜单里出现，也提供快捷指令动作。
工具的共同短板
不管用哪个，规则库更新永远赶不上平台改字段。像小红书 xsec_token 这种从「可删」变成「必需」的变化，社区反应过来往往要几个月。ClearURLs 的规则库本身也有过接近一年没更新的记录。
所以清理完最好还是养成一个习惯：在无痕窗口点一下自己发出去的链接。三秒钟，但它是你和「发出去一条打不开的链接」之间唯一的保险。
什么人值得折腾这个
说实话，收益不算大。清理链接顶多是让平台少收一点归因数据，让收件人拿到一条整洁的地址。
如果你只是偶尔转个链接，装个扩展让它自动跑就够了，剩下的不用管。
真正值得花时间的是两种情况：一是你经常往公开场合发链接——群里、社交平台、文章里，这时候链接里那个和你账号绑定的字段就不只是统计问题了；二是你写东西需要引用，一条规范的永久链接比一条带着一串会过期参数的链接可靠得多。
至于我自己，坚持这个习惯两年，最大的收获反而不是隐私——是知道自己发出去的每一个字符是干什么用的。但比「删得干净」更重要的还是「删得准」。一条被删坏的链接，比一条带着参数的链接麻烦得多。
扩展阅读
- 一日一技｜如何分享一个体面的购物链接：电商平台链接的规范化模板与商品编号规则，本文的电商部分基于它展开
- 分享更清爽的链接，可以试试这个 Android 小工具：清净分享：Android 端的自动化方案
题图：Photo by Arthur Mazi on Unsplash
