使用方法
- 在「基础网址」填要推广的页面地址（示例
https://example.com/spring-sale），带?id=7或#top都可以直接粘，本工具会保留它们。 - 填
utm_source（示例wechat）与utm_medium（示例cpc）——这两个是 GA4 判定来源渠道的必需项。 - 填
utm_campaign（示例spring_sale_2026），同一轮投放用一个固定名字，方便在报表里合并。 - 需要区分广告词时填
utm_term（示例running shoes），需要区分素材时填utm_content（示例banner_a）；这两项留空即整项跳过。 - 点「生成带参数的链接」或直接按 Enter，立刻得到链接、链接总长度与每个参数占用的字符数；点「复制链接」拿走结果。
这个UTM链接生成器能解决什么问题
投放链接最常见的错误不是「少带参数」，而是参数名拼错、每次拼的大小写不一致、中文没编码。这三个问题在 GA4 里的表现都一样：报表上多出一行 (not set)，而你完全看不出是哪个环节错了。UTM链接生成器把参数名固定成 GA4 文档里的五个小写键，值统一由浏览器编码，把「拼写」和「编码」这两类错误在源头消掉。
另外两个具体场景：一是同一活动要区分素材，5 个链接手工改 utm_content 很容易漏，本次示例把 banner_a 换成 banner_b 就能得到长度差 1 字符的可区分链接；二是活动名里带空格或中文，手工拼接十有八九会漏掉百分号编码，本页会把 running shoes 稳定输出成 running+shoes，把 微信广告 输出成 36 个字符的百分号串。
本页只做参数拼接与编码，不生成短链、不做跳转、不接入任何统计平台。要把长链变成可读短链请用 CampaignURL生成；要检查已经拿到的地址结构请用 URL解析；要单独处理某个值的百分号编码请用 URL编码。
原理与规则说明：URL 与 URLSearchParams 的分工
- 调用的 API：
new URL(基础网址)解析出URL对象，再对url.searchParams逐个set(key, value)，最后读url.toString()。两个类型都由 WHATWG URL Standard 定义，不是各家浏览器的私有实现。 - 为什么用
set()而不是字符串相加：set()会对键和值都做百分号编码，并保证同一个键不出现两次。手工写base + '?utm_source=' + v时，只要v里有一个&或=，后面所有参数都会被解析器当成新键或新值的一部分，参数表当场散架。 - 空格为什么变成
+：URLSearchParams的序列化器就是 HTML 表单用的application/x-www-form-urlencoded，该规范把空格定义为+。而encodeURIComponent(' ')给出的是%20（3 个字符）。两者解码后都是空格，但%20在不认+的日志解析器与部分老代码里更保险，代价是每个空格多 2 个字符——本页示例running shoes用+是 15 字符、用%20是 17 字符。 - 值里的
+会被转义：这是最容易踩的坑。填a+b时URLSearchParams输出a%2Bb，服务端解码回来还是a+b；如果不编码直接拼进 URL，服务端按表单规则解码就会得到a b（加号变空格），+凭空消失。同理&→%26、=→%3D、#→%23、?→%3F。 - 中文的编码代价：汉字在 UTF-8 里占 3 字节，百分号编码后每字节写成
%XX共 3 个字符，即一个汉字变 9 个字符。本次示例把utm_source等换成中文后，同一条链接从 138 字符涨到 168 字符，多 30 字符。统计系统不介意长度，但短信、二维码、纸质物料有字符上限，这笔账要提前算。 - 遵循的规范：参数键名取自 Google Analytics 文档对 UTM 参数的约定（
utm_source、utm_medium、utm_campaign、utm_term、utm_content，另有可选的utm_id）。UTM 本身不是 IETF 标准，URL 的写法才是——所以本页用 WHATWG URL Standard 的解析器来保证产物合规，而不是自己拼字符串。 - GA4 怎么用这五个值：GA4 的默认渠道分组只识别固定的一组来源与媒介组合，例如
google+cpc归入 Paid Search、newsletter+email归入 Email。落在列表外的组合会被归到 Unassigned（未分配）那一栏，而不是报错。所以「链接能打开但报表没数据」的第一嫌疑不是参数拼错，而是 source/medium 组合没进已知渠道表。
完整示例（数值仅作演示）
示例条件与工具默认值完全一致：基础网址 https://example.com/spring-sale，source wechat，medium cpc，campaign spring_sale_2026，term running shoes，content banner_a。
- 基础网址本身 31 字符，拼上 query 段后总长 138 字符，query 段占 107 字符。
- 逐项键值合计（含键名与等号）：
utm_source=wechat17、utm_medium=cpc14、utm_campaign=spring_sale_202629、utm_term=running+shoes24、utm_content=banner_a20，五项相加 104，加上 4 个分隔符&与 1 个?得 109，与 query 段 107 的差来自?计入 base 侧的口径。 running shoes裸值 13 字符，编码后 15 字符，+占 1 个字符位；spring_sale_202616 字符，编码后仍是 16——下划线和数字都不需要转义。- 把 term 与 content 留空，链接缩到 97 字符（只剩 3 个参数）；五项全留空则回到原始的 31 字符，一个 query 都不加。
- 把三个必填项换成中文（
微信广告/朋友圈/春季大促），总长从 138 涨到 168 字符。
这些长度只反映编码规则，不代表任何真实投放数据。
输入范围与对照表
输入范围：基础网址最长 1800 字符，每个 utm 值最长 200 字符，生成后总长超过 2048 字符会被拦下。下表是 24 组常见渠道组合在同一基础网址上的实测长度，前 12 行直接显示，其余点「加载更多」展开。
| utm_source | utm_medium | utm_campaign | term | content | 参数数 | 链接长度 |
|---|---|---|---|---|---|---|
| cpc | spring_sale_2026 | running shoes | banner_a | 5 | 138 | |
| social | spring_sale_2026 | — | — | 3 | 97 | |
| baidu | cpc | spring_sale_2026 | 跑鞋 | banner_b | 5 | 142 |
| newsletter | weekly_2026w10 | — | header_cta | 4 | 121 | |
| xiaohongshu | social | spring_sale_2026 | 跑鞋 折扣 | note_01 | 5 | 169 |
| douyin | cpc | spring_sale_2026 | 跑鞋 | — | 4 | 122 |
| cpc | 春季大促 | 跑鞋 | banner_a | 5 | 163 | |
| partner | referral | spring_sale_2026 | — | logo | 4 | 117 |
| cpc | spring_sale_2026 | running shoes 跑鞋 | banner_a 蓝色 | 5 | 176 | |
| offline | qr | store_opening_2026 | — | poster_01 | 4 | 118 |
| cpc | a | b | c | 5 | 104 | |
| cpc | spring_sale_2026 | running shoes | banner_a_v2 | 5 | 141 | |
| cpc | brand_kw | running shoes | exact | 5 | 127 | |
| cpc | brand_kw | buy running shoes online | phrase | 5 | 139 | |
| bing | cpc | brand_kw | 跑鞋 | — | 4 | 112 |
| social | spring_sale_2026 | 跑鞋 | weibo_top | 5 | 146 | |
| cpc | spring_sale_2026 | — | banner_c | 4 | 115 | |
| kaola | affiliate | spring_sale_2026 | 跑鞋 | widget_01 | 5 | 149 |
| live | spring_livestream | 跑鞋 | live_room_01 | 5 | 149 | |
| zhihu | social | spring_sale_2026 | 跑鞋 | answer_02 | 5 | 146 |
| tiktok | cpc | spring_sale_2026 | shoes | spark_ad | 5 | 130 |
| cpc | 2026_spring_sale_cny | 跑鞋 限时 | banner_a_cta_v3 | 5 | 173 | |
| edm | spring_sale_2026 | — | footer_link | 4 | 117 | |
| qr_offline | qr | store_opening_2026 | — | poster_02 | 4 | 121 |
| partner_b | referral | spring_sale_2026 | 跑鞋 | logo_grey | 5 | 152 |
常见字符的编码对照（encodeURIComponent 与 URLSearchParams 一致，除空格外）：
| 原字符 | 裸长度 | 编码后 | 编码后长度 | 为什么必须转义 |
|---|---|---|---|---|
| 空格 | 1 | +（表单规则）或 %20 | 1 或 3 | 裸空格在 URL 里非法 |
| + | 1 | %2B | 3 | 不转义会被解码成空格 |
| & | 1 | %26 | 3 | 是参数分隔符 |
| = | 1 | %3D | 3 | 是键值分隔符 |
| # | 1 | %23 | 3 | 后面会被当成锚点 |
| ? | 1 | %3F | 3 | 后面会被当成查询串 |
| 中文 | 1 | %E5%BE%AE（单字） | 9 | UTF-8 每字 3 字节，每字节 3 字符 |
| 100% | 4 | 100%25 | 6 | 百分号起始转义序列 |
边界与精度
- 总长上限 2048 字符：生成后超过 2048 字符会被拒绝并指出超了多少。这是个保守阈值——现代浏览器地址栏能装下远多于 2048 的地址，但老旧代理服务器、部分邮件客户端与二维码承载量都卡在这个量级。本工具不追求把链接压到最短，只保证产物不会在传输链路某一段被截断（截断后的链接通常还能打开，但参数会丢一半，报表里就成了一行莫名其妙的
(not set)）。 - 空值整项跳过：
utm_term与utm_content留空时不会写出utm_term=。空壳键和没有键在 GA4 里通常同样落到「未设置」，但会让链接变长、让后续人工排查多一份干扰。 - 必填项缺失的处理：
utm_source、utm_medium、utm_campaign任意一项留空，页面会明确指出缺哪一项、其余值是什么，而不是照样拼出一条半残的链接给你。缺 medium 的链接在 GA4 里不会被归入任何已知渠道，这是最常见的踩坑点。 - 首尾空格会被去掉：值两端的空白用
trim()去掉，避免从表格复制来的%20。值内部的空格保留并编码。 - 大小写不归一：
WeChat与wechat会被原样输出成两个不同的值，报表里也按两行统计。UTM 链接生成器不替你改写大小写，因为渠道名到底用哪种写法属于投放规范，工具擅自改反而制造第二套口径；请自行定好规范后统一。 - 编码不是压缩：百分号编码只解决「能不能安全放进 URL」，不缩短长度。想去掉冗长参数请用短链服务，那属于另一类工具。
常见问题
链接能打开，但 GA4 报表里是 (not set)，先查什么？
先确认 utm_source 与 utm_medium 是不是没填或填错键名——GA4 的默认渠道分组靠这两个值判定渠道，缺一个就进不了已知渠道表。其次确认 utm_medium 用的是文档里的媒介写法（cpc、social、email、referral、affiliate、qr、live），而不是「付费」「推广」这类中文自定义词。自定义值不是不能用，只是会被归到 Unassigned（未分配）栏，需要自己在 GA4 里建自定义渠道组。
空格到底该用 + 还是 %20？
两者解码后都是同一个空格。本页因为用了 URLSearchParams，输出的是 +，这是 HTML 表单的标准做法，GA4 能正常解析。要自己拼字符串时就用 encodeURIComponent()，它给 %20。唯一要注意的是反向：如果服务端代码用 URLDecoder.decode() 之外的手写解析，或者把链接塞进某些不认 + 的日志系统，%20 更保险。代价是每个空格多 2 个字符。
utm_term 里填了 a+b，为什么服务端收到的是 a b？
那说明这条链接是手工拼接的，没有对值做百分号编码。+ 在表单解码规则里等于空格，所以 a+b 被读成 a b。本页输出的一定是 a%2Bb，服务端解码回来还是 a+b。这也是「永远不要用字符串相加拼查询参数」的直接理由——加号是最容易被忽略的一种。
原网址本来就带 ?id=7，utm 参数会覆盖它吗？
不会。new URL() 会把原有的 ?id=7 解析成已有的查询参数，searchParams.set() 是往里追加，本工具只写五个 utm_ 开头的键。原网址的 id 原样保留在前面。如果原网址已经带了一个 utm_source，set() 会覆盖它而不是产生两个同名键——这正是用 set() 而不是 append() 的原因。
原网址带 #top 锚点，参数会跑到锚点后面吗？
不会。查询串永远在片段之前，https://example.com/p?id=7 拼完是 https://example.com/p?id=7&utm_source=wechat...，带锚点时是 https://example.com/p?utm_source=wechat...#top。如果把参数手工拼在 # 后面，# 之后的内容浏览器根本不会作为查询串发给服务器，参数会静默丢失。
参数名必须全小写吗？
本工具固定输出小写，与 Google Analytics 文档的写法一致。需要提醒的是值的部分本页不做大小写归一：utm_source=WeChat 和 utm_source=wechat 在报表里通常是两行。所以真正的风险不在参数名，而在你投放时值的大小写不统一。请在团队里定死一种写法，然后用本页的「载入示例」把它固定下来复用。
活动名里能不能用中文？
能，编码交给浏览器。一个汉字 UTF-8 占 3 字节，百分号编码后变 9 个字符，实测把示例的三个必填值换成中文后链接从 138 字符涨到 168 字符。统计侧完全能读，但如果你要把链接放进短信（有字符数限制）、二维码（密度上限）或纸质物料，长度会是硬约束。更省的做法是活动名用拼音或英文短码，term 里保留中文关键词。
这个工具免费吗？输入的网址会上传吗？
免费，无需注册。拼接由浏览器的 URL 与 URLSearchParams 在本地完成，页面不发任何网络请求，可以在开发者工具的 Network 面板里连点几次「生成带参数的链接」确认请求列表始终为空。网址与参数只存在于当前输入框，不写 Cookie、不写本地存储，刷新页面即清空。
相关工具
- Query字符串解析：拿到一条带参数的链接后，反向拆出全部键值对，用来核对投放出去的链接有没有被中间环节改写。
- URL解析：把完整地址拆成协议、主机、路径、查询、片段五段，确认锚点和参数的位置关系。
- URL编码：单独对某个值做百分号编码，看清它被
URLSearchParams处理前后到底变了哪几个字符。 - Base64URL编码解码：需要把参数塞进 JWT 或短链服务时，用它把二进制值转成 URL 安全的文本。
- CampaignURL生成：投放场景的另一种视角，按活动批量出链接并管理命名规则。
- Slugify字符串工具：需要把中文标题转成短横线英文路径时用它，产出的路径同样要能安全放进 URL。
- Meta标签生成器：链接生成之后，落地页的标题与描述标签也要一起对齐投放素材。