老读者可能还记得，我之前在某公司的运营后台系统里做过一次页面重构，其中有个特别不起眼但又绕不开的需求：从前端拿 URL 上携带的参数，顺手把一些状态写进 Cookie。听起来简单，真正动手的时候才发现，这里面的细节比想象中多得多。正好这段时间在群里也看到有朋友问类似的问题，我把当时的完整处理思路和踩坑记录整理成文，希望对正在做同类功能的人有点帮助。得先说清楚，这次分享针对的是纯前端方案，也就是在浏览器环境下，不借助任何后端能力去完成两项事情：第一，解析地址栏里?后面的查询参数；第二，对 Cookie 进行增删改查。这两种操作在前端日常开发里出现频率极高，无论是活动页、落地页、扫码登录跳转，还是页面之间传参，基本都会用到。1. 为什么这个需求值得单独写一篇文章有人可能会说，URL 取参不就是window.location.search截一下字符串，Cookie 不就是document.cookie读写一下，有什么好讲的？确实，光看 API 都简单，但真正放到项目里就会遇到一连串细节问题。我当时的项目场景是这样的：某活动页面需要根据推广人员的 ID 展示不同内容，推广 ID 通过链接参数传入；同时用户进入页面后，系统要把用户的来源渠道记录在 Cookie 里，方便后续行为追踪。听起来是不是很像很多公司都在做的渠道归因功能？需求不复杂，但当我开始写代码时，第一个问题就来了：URL 里除了可能有promoId，还有可能有utm_source、utm_medium等一堆参数，用户还可能手动改地址栏，甚至参数值里带特殊字符。如果只按split('&')的方式切，遇到参数值本身含有&或=就会被切得支离破碎。Cookie 那边的问题更隐蔽。比如我天真地以为document.cookie = 'percent=30'就能覆盖掉原来的percent值，结果发现不同路径下的同名 Cookie 会同时存在，读的时候只能读到其中一个；又比如我以为设置过期时间就直接写个时间字符串就行，结果时区和格式问题导致 Cookie 立刻失效。这些问题没有一个特别难的，但不踩一遍根本记不住。所以这篇文章我不会只给结论，而是从第一遍实现的“天真写法”开始，逐步演进到能扛住线上真实场景的可用版本，把每一处修改的前因后果讲清楚。这样你拿到的不只是一段代码，而是遇到相似问题时能自己推断出解法的判断能力。2. 获取URL携带参数的完整方案URL 参数解析是前端最经典的操作之一，但经典不意味着简单。从最初的字符串拆分，到原生 API 的统一处理，再到各种边界情况的兜底，这里面的演进过程很能说明问题。2.1 基础方案：字符串拆分与正则匹配最直觉的写法，就是把window.location.search里的内容按&拆开，再把每个键值对按=拆开。我一开始也是这么干的，代码如下：function getQueryParam(name) { const search = window.location.search.substring(1); if (!search) return null; const parts = search.split('&'); for (const part of parts) { const pair = part.split('='); if (pair[0] === name) { return decodeURIComponent(pair[1] || ''); } } return null; }这段代码放在大多数简单场景里都能跑，但问题也明显。比如 URL 是https://example.com/page?name=张三&from=baidu，它会正确返回张三。可如果参数值是https://example.com/redirect?target=https://mysite.com/page?a=1&b=2这种带 URL 的值，把整串按&一拆，b=2就被误认为独立参数了，后面target参数会被截断。还有一个常见问题是编码。浏览器地址栏里出现中文，实际location.search拿到的可能是已经编码过的内容，比如%E5%BC%A0%E4%B8%89，需要decodeURIComponent才能还原成张三。但要注意，如果参数值里有单字节的特殊字符，某些老版本浏览器里直接按=分割后再解码可能报错，稳妥做法是用正则先取原始值再解码。正则方案比split健壮一些，典型写法是对整个location.search做捕获匹配：function getQueryParamByRegExp(name) { const reg = new RegExp('(?:^|\\?|&)' + name + '=([^&]*)(?:&|$)'); const match = window.location.search.match(reg); return match ? decodeURIComponent(match[1]) : null; }这个正则的匹配范围是：参数名前面的边界只能是字符串开头、问号或&，取值部分捕获到下一个&或结尾。相比split，它天然避开了target=https://...a=1&b=2这种值里带&时的误切吗？其实也避不开，因为值里出现未编码的&时，正则仍然会在那个位置截断。也就是说，任何靠&分隔来解析的方案，都要求 URL 在拼接时对参数值做过正确的encodeURIComponent。这反而给了我一个启示：与其在解析端跟字符串较劲，不如从源头保证拼接端编码正确。这也是后面我们要重点强调的规范问题。2.2 标准方案：URLSearchParams 的使用与限制后来我全面转向了原生 API：URLSearchParams。这玩意儿就是浏览器专门为查询字符串设计的解析器，代码干净利落：function getQueryParamByURLSearchParams(name) { const searchParams = new URLSearchParams(window.location.search); return searchParams.get(name); }三行搞定，而且不用手动解码，URLSearchParams.get()内部会帮我们处理好%XX形式的编码内容。如果参数不存在，get()返回null，语义也很清楚。URLSearchParams不是只能读一次，同一个实例可以反复调用get查多个参数，也可以遍历entries()、keys()、values()，很方便。比如我当时需要把 URL 里所有utm_开头的参数打包上报，就是直接遍历：const searchParams = new URLSearchParams(window.location.search); const utmParams = {}; for (const [key, value] of searchParams.entries()) { if (key.startsWith('utm_')) { utmParams[key] = value; } }这个 API 的兼容性在现在的浏览器环境下已经没什么问题了，主流的现代浏览器和新版本移动端 WebView 都支持。但如果你手头有需要兼容极老内核的项目，或者遇到URLSearchParams被某些安全扫描策略误判的情况，前面那段正则兜底方案还是得留着。URLSearchParams也不是没有坑。最大的坑在于：如果 URL 参数是从hash（#后面）部分携带的，window.location.search根本获取不到，因为#后内容属于location.hash。有些单页应用的路由参数就是放在 hash 里的，比如https://example.com/#/order?orderId=10086，这时候直接 }new URLSearchParams(window.location.search)} 拿到的是空对象，必须手动从location.hash切出问号后的部分再解析。这个情况很容易被忽略。2.3 兼容双场景的实用封装为了把search和hash两个来源都覆盖到，也为了让旧项目能平滑过渡，我最后在项目里沉淀了一个统一的参数获取函数，核心逻辑是依次尝试多个来源，并保留正则兜底：function getUrlParam(name) { // 直接参数形式 const direct = getParamFromString(window.location.href.split('?')[1] || ''); const value = direct.get(name); if (value !== null) return value; // 从 hash 中解析 const hashIndex = window.location.href.indexOf('#'); if (hashIndex !== -1) { const hashSearch = window.location.href.substring(hashIndex).split('?')[1] || ''; const fromHash = getParamFromString(hashSearch); const hashValue = fromHash.get(name); if (hashValue !== null) return hashValue; } return null; } function getParamFromString(queryString) { if (typeof URLSearchParams !== 'undefined') { return new URLSearchParams(queryString); } // 老浏览器兜底 return { get(name) { const reg = new RegExp('(^|&)' + name + '=([^&]*)(&|$)'); const match = queryString.match(reg); return match ? decodeURIComponent(match[2]) : null; } }; }这段代码的用意不是炫技，而是把不同场景的差异收敛在一个入口里，调用方不关心参数到底是从哪段位置来的，只关心“这个参数叫什么”。实际用下来，这种封装确实省了不少事，尤其是多个页面都要做类似初始化的时候，统一入口比每处各写一遍要干净得多。3. Cookie 操作的完整细节与安全问题Cookie 这块的 API 更简单，就是一个document.cookie，但它背后牵扯到的属性配置和语义细节，远比表面看到的要多。很多新手第一次写 Cookie 相关代码时，最大的困惑在于：document.cookie既表示“获取整个 Cookie 字符串”，又可以被赋值来写入单个 Cookie，这种兼顾读写的设计并不直观。3.1 读 Cookie 的正确姿势读取 Cookie 时，document.cookie返回的是一个分号分隔的字符串，例如"name=张三; token=abc123"。要取其中某个键的值，不能直接document.cookie.name，必须自己解析字符串。我见过最朴素的读法是用数组方法做匹配：function getCookie(name) { const cookieString = document.cookie; const cookies = cookieString.split('; '); for (const cookie of cookies) { const index = cookie.indexOf('='); const key = cookie.substring(0, index); const value = cookie.substring(index + 1); if (key === name) { return decodeURIComponent(value); } } return null; }这里有两个容易翻车的地方。第一，split('; ')用的是分号加空格，但某些浏览器环境下 Cookie 字符串里可能没有空格，或者多个空格，所以稳妥做法是split(';')之后再对每段做trim()。第二，Cookie 的值同样可能被编码，写入时可以用encodeURIComponent处理，读取时就相应地decodeURIComponent还原，否则遇到中文或特殊符号会显示乱码或直接报错。用正则写也可以，还能把代码压缩到更短：function getCookie(name) { const match = document.cookie.match(new RegExp('(^|;\\s*)' + name + '=([^;]*)')); return match ? decodeURIComponent(match[2]) : null; }都行，核心思路是一样的。但这里我必须特别指出一个安全层面的关键知识点：如果服务端给某个 Cookie 加上了HttpOnly属性，那么这段纯前端代码无论如何是读不到该 Cookie 的，document.cookie里压根不会包含它。这不是 bug，是刻意设计，目的就是防止跨站脚本（XSS）攻击窃取带有敏感信息的会话凭证。大家写前端代码时如果发现某些 Cookie 读不到，先别急着怀疑自己的解析逻辑，去开发者工具里看看这个 Cookie 是不是带了HttpOnly标记，其中“HttpOnly”指的就是禁止脚本访问的意思。前端脚本在登录态这块能做的很有限，比如下面说的document.cookie写入只能影响非 HttpOnly 的 Cookie，不该试图绕过这套安全机制。3.2 写 Cookie 时容易忽略的属性细节写入 Cookie 的代码相当直观：document.cookie = 'key=value';但这个写法有个隐含的副作用：Cookie 的默认生命周期是“会话级”，也就是浏览器标签页关闭后就没了。如果希望 Cookie 能存得更久，就得显式设置expires或max-age。我当时的需求是记录用户来源渠道，希望它能保留 30 天。于是写出了第一版：function setCookie(name, value, days) { const date = new Date(); date.setTime(date.getTime() + days * 24 * 60 * 60 * 1000); document.cookie = name + '=' + encodeURIComponent(value) + '; expires=' + date.toUTCString() + '; path=/'; }date.toUTCString()是一个必须使用的细节，不能用浏览器本地时区的toString()来生成时间串。Cookie 的expires属性，遵循的是 HTTP 日期格式，本质上是格林尼治标准时间，也就是 UTC 时间。如果用toLocaleString()之类的方法生成，不同时区的电脑上给出的格式可能不同，轻则 Cookie 有效时长产生偏移，重则直接被浏览器判定为非法日期而拒绝写入。path=/则是为了指定 Cookie 的作用路径。默认情况下只对当前路径生效，比如你在https://example.com/promo/下写入，在https://example.com/order/下就读不到。这往往不是我们预期的行为，因为一个站点内的多个页面都要共享这个 Cookie。统一指定path=/意味着整站都能访问到，这是最常用的配置，建议条件允许的情况下直接写上去。再说说domain属性。它用来控制 Cookie 在哪个域名及子域名下生效。默认只对当前完整域名生效，比如sub.example.com下写入的，example.com读不到。如果业务希望主域和子域共享 Cookie，可以显式设置domain=example.com。但这个属性要谨慎使用，一旦设置了较宽的域范围，Cookie 就会被发送到该域下的所有子域，如果被 XSS 利用，影响面会跟着扩大。还有Secure和SameSite两个属性。Secure要求仅限 HTTPS 连接传输，SameSite则限制跨站请求能否携带 Cookie。早期有不少项目不重视SameSite，导致在跨站跳转场景下 Cookie 发送行为变得很诡异。像我们做渠道排查时，从外部链接进入页面，Cookie 携带规则就受SameSite影响。现代浏览器里这方面的规则已经比较严格，新写代码时最好主动加上SameSite=Lax或明确业务需要后再调整。3.3 删除 Cookie 的方法与本质删除 Cookie 的办法看起来很绕：把过期时间设为过去的时间点，让浏览器判定它已过期，从而自动清理。function removeCookie(name) { // 注意：path 必须与写入时一致，否则删除不掉 document.cookie = name + '=; expires=Thu, 01 Jan 1970 00:00:00 GMT; path=/'; }这里最大的坑就是路径不一致。如果你写入时设置了path=/，删除时却不带path=/，浏览器会把删除操作视为“在默认路径下写入一个新的名为 name 的空 Cookie”，结果原来的 Cookie 依然活得好好的。很多同学遇到“Cookie 删不掉”的问题，十有八九就是路径没对上。另一个容易忽略的问题是对同名 Cookie 的处理。浏览器允许同一个域名、同一个 name、不同 path 的 Cookie 并存，比如同时存在name=1; path=/和name=2; path=/promo/。读取时document.cookie会按路径优先级把更具体的那个排到前面，但删除时如果不把每个路径下的同名 Cookie 都删一遍，很可能出现“删了又冒出来”的错觉。处理办法也不复杂，就是按常见的几个路径分别执行同名删除：function clearCookieByName(name) { ['/', '/promo/', '/order/', '/user/'].forEach((path) => { document.cookie = name + '=; expires=Thu, 01 Jan 1970 00:00:00 GMT; path=' + path; }); }这招虽然有点暴力，但在排查问题时很管用，特别是当你怀疑某个历史遗留的旧路径 Cookie 在捣乱时。4. 实操案例：某活动页的渠道参数与 Cookie 联动这一章我以当时实际做的一个模拟项目为例，把前面讲到的所有知识点串起来，走一遍完整流程。我这里说的只是一个用来讲原理的简化版系统，但处理方式与线上项目一致。4.1 需求拆解与方案设计当时的设计是这样的：某运营活动需要根据渠道参数展示不同内容，同时把渠道信息预存在 Cookie 里，后续用户访问站内其他页面时持续生效。具体拆解出三个子任务：第一，从 URL 里读取channel参数，比如?channel=baidu，如果参数存在，在页面顶部展示对应的渠道标识。第二，把读取到的渠道值写入 Cookie，命名channel_source，有效期 30 天，全站可读。第三，如果 URL 里没带channel参数，则回退读取 Cookie 里的channel_source作为兜底来源，两者都没有就显示默认渠道。这个方案本身不复杂，但它的好处是能把参数解析和 Cookie 操作串联在同一个业务过程里，考察了编码、过期时间、路径统一、默认值回退等多个细节。4.2 完整实现与关键步骤核心代码大概长这样：(function () { // 1. 从 URL 获取渠道参数，来自 query 或 hash const channel = getUrlParam('channel'); let channelValue = channel; // 2. 如果 URL 没有，尝试读已有 Cookie if (!channelValue) { channelValue = getCookie('channel_source'); } // 3. 如果 URL 有，则以新的 URL 参数为准，并刷新 Cookie if (channel) { setCookie('channel_source', channel, 30); } // 4. 页面展示处理 const finalChannel = channelValue || 'default'; const el = document.getElementById('channel-banner'); if (el) { el.textContent = '当前渠道: ' + finalChannel; } })();这里面的顺序是有讲究的：先看 URL 参数，再看 Cookie，用新的覆盖旧的。这样设计是为了避免“用户从新的渠道链接进来，却仍然被旧 Cookie 影响”的脏数据问题。做过渠道归因的应该都懂，这种覆盖逻辑如果不加，后续分析数据时会出现张冠李戴的情况。对应地，setCookie和getCookie两个工具函数直接采用前面章节里封装好的版本：function setCookie(name, value, days) { const date = new Date(); date.setTime(date.getTime() + days * 24 * 60 * 60 * 1000); document.cookie = name + '=' + encodeURIComponent(value) + '; expires=' + date.toUTCString() + '; path=/'; } function getCookie(name) { const match = document.cookie.match(new RegExp('(^|;\\s*)' + name + '=([^;]*)')); return match ? decodeURIComponent(match[2]) : null; }这段代码在实际环境中运行得很稳定。不是说它多高级，而是每一步都把该固定的属性固定住了：过期时间用了toUTCString()，值做了百分比编码，路径统一用根路径，读取时做了正则提取和解码。基本功扎实了，线上就不会出幺蛾子。4.3 联调阶段的验证要点代码写完只是第一步，真正容易出问题的是联调阶段。我在验证时总结了几个核心检查项，现在分享给大家。用浏览器开发者工具的“Network”面板检查 Cookie 在请求中的携带情况，看是否存在跨路径丢失或SameSite阻断。修改系统时间能不能用来测试 Cookie 过期？可以，但不推荐，因为容易把本地环境搞乱，更合理的做法是把过期时间临时改短，比如setCookie的 days 参数传0或-1来观察行为。对于 URL 参数的测试，注意分别验证带参数、不带参数、参数值含中文、参数值含特殊字符（如%2C）几种情况。还有一个我特别想强调的点：写完 URL 参数拼接时要主动使用encodeURIComponent，不要直接拼字符串。比如用户从活动页跳转到落地页，需要把渠道参数透传过去，正确写法是：const nextUrl = 'https://example.com/landing?source=' + encodeURIComponent(channelValue);如果不编码，channelValue里万一有&或者=，整个 URL 结构就乱套了。这个习惯看起来小儿科，但它能避免一大堆解析层面的诡异 bug。前后端传参时同理，别让拼接端的不规范操作成为解析端事故的导火索。5. 常见问题排查与避坑经验在这类需求的开发过程中，我遇到过不少看似“玄学”的问题，最后排查下来基本都是小细节导致。整理成速查表，方便大家对照自查。5.1 中文参数乱码与解码时机问题最典型的现象：URL 里明明带着?name=张三，页面里取出来却变成一堆%E5%BC%A0%E4%B8%89。这通常不是解析代码的问题，而是没有对取值结果做decodeURIComponent。反过来，如果已经解码一遍，页面显示还是乱码，那要考虑是不是参数在拼接端被重复编码了。比如先用encodeURIComponent加工过一次，服务端又整体编码一次，前端解一层就还原不完整。排查这类问题，直接在调试工具里打印window.location.search，看原始字符串到底长什么样，再决定解一层还是两层。字典里常见的情况还有一种：写入 Cookie 时用了encodeURIComponent，但读取时忘了decodeURIComponent，也会导致页面展示的内容是编码态。规则很简单：写入端做了什么处理，读取端要对称地做反向处理，两端不匹配必然出错。5.2 Cookie 过期时间时区与清理边界过期时间问题前面说过用toUTCString()来规避，但还有一个隐藏点：new Date()和date.toUTCString()之间的时间基准要统一。如果你在某处把date.getTime()直接拼进 Cookie 值，这就不是一个标准时间格式，浏览器不一定认可。我自己踩过一次比较经典的坑是：setCookie('token', value, 7)设置 7 天过期，结果第二天再访问时 Cookie 已经没了。排查后发现代码里把days误传成了字符串，导致日期计算的数值运算变成了字符串拼接，生成的过期时间错乱。所以对工具函数来说，参数校验很有必要：function setCookie(name, value, days) { const daysNum = Number(days) || 0; // ... }如果传入不合法，至少不会让整个 Cookie 写入挂掉。5.3 同名 Cookie 路径混乱导致覆盖失败这个问题前面也提过，但值得单独拿出来强调一次。浏览器允许同名、不同路径的 Cookie 共存，所以“覆盖”和“删除”都没有想象中那么理所当然。比如你在path=/promo/下设置过channel_source=abc，又在path=/下设置channel_source=xyz，读取时document.cookie字符串里会把两个都列出来，但getCookie里的正则匹配从左往右找，大概率匹配到路径更具体的那一个，也就意味着你以为读的是全站这个值，实际拿到的可能是子路径下的旧值。排查手段很简单，开发者工具的 Application 面板里，Storage/Cookies 下面能看到每个 Cookie 的 Path 列。如果发现多个同名记录，把它们对应的路径逐个删除再重新设置即可。长期方案是统一各处的写入路径参数，写path=/就全员path=/，别一会儿有、一会儿没有。5.4 大小限制与同源策略的边界Cookie 的容量限制是 4KB 左右，指的是单个 Cookie 的键值总和。别试图把一串长文本塞进去，比如用户填的表单数据、日志报文之类，超了的话浏览器会静默拒绝写入，代码不报错但功能不生效。我当时在调试一个用户偏好设置时就是吃了这个哑巴亏，document.cookie赋值语句执行了，document.cookie用来读取也验证过，但一刷新全没了，后来一量长度才意识到是超过了容量限制。如果确实要在浏览器端存储稍大的数据，优先考虑localStorage或sessionStorage这类 Web Storage 方案。它们不是 Cookie 的替代品，但容量上限宽松得多。需要传给服务端的这种轻量标识才考虑 Cookie。选型问题做在前面，后面就不会因为容量不足而返工。6. 沉淀下来的工具函数集与个人体会项目结束后，我把这次用到的方法整理成了一个小模块，放到团队内部公共代码库里。这套函数也不复杂，但胜在稳定，后续好几个项目直接拿来复用，没有再因为 URL 参数或 Cookie 的问题拉长排查时间。6.1 统一封装的参数处理工具集// 将 URL 查询字符串解析为对象，兼容 URLSearchParams 缺失场景 function parseQueryString(queryString) { const result = {}; if (!queryString) return result; const parts = queryString.split('&'); parts.forEach((part) => { if (!part) return; const index = part.indexOf('='); let key = index > -1 ? part.substring(0, index) : part; let value = index > -1 ? part.substring(index + 1) : ''; try { key = decodeURIComponent(key); value = decodeURIComponent(value); } catch (e) { // 个别字符解码失败时保留原样，不影响整体解析 } if (Object.prototype.hasOwnProperty.call(result, key)) { result[key] = [].concat(result[key], value); } else { result[key] = value; } }); return result; } // 获取指定 URL 参数，优先 search，兼容 hash function getUrlParam(name, targetUrl) { const url = targetUrl || window.location.href; const searchIndex = url.indexOf('?'); const hashIndex = url.indexOf('#'); let search = ''; if (searchIndex !== -1) { const searchEnd = hashIndex > -1 ? hashIndex : url.length; search = url.substring(searchIndex + 1, searchEnd); } const queryObj = parseQueryString(search); if (queryObj[name] !== undefined) return queryObj[name]; // 尝试解析 hash 部分的参数 if (hashIndex !== -1) { const hashSearchIndex = url.indexOf('?', hashIndex); if (hashSearchIndex !== -1) { const hashQuery = url.substring(hashSearchIndex + 1); const hashObj = parseQueryString(hashQuery); if (hashObj[name] !== undefined) return hashObj[name]; } } return null; }这个版本的parseQueryString在处理重复参数时会把多个值合并成数组，这是个很实用的细节，比如?id=1&id=2能同时取到两个候选值。getUrlParam则是既看 query 部分也看 hash 部分，覆盖了单页应用场景。这段代码不依赖URLSearchParams，因此在老浏览器里也能跑，同时也很好理解。6.2 Cookie 工具集const CookieUtil = { set(name, value, days, path) { const expires = days ? new Date(Date.now() + days * 864e5).toUTCString() : ''; const pathStr = path || '/'; const cookieStr = name + '=' + encodeURIComponent(value) + ';' + (expires ? ' expires=' + expires + ';' : '') + ' path=' + pathStr + ';'; document.cookie = cookieStr; }, get(name) { const match = document.cookie.match(new RegExp('(^|;\\s*)' + name + '=([^;]*)')); return match ? decodeURIComponent(match[2]) : null; }, remove(name, path) { const pathStr = path || '/'; document.cookie = name + '=; expires=Thu, 01 Jan 1970 00:00:00 GMT; path=' + pathStr + ';'; } };remove方法默认删根路径下的 Cookie，但如果你见过某些场景下写入时没带 path，删除时同样可能需要多尝试几个路径。这一点我在注释里也标明并沿用，前端同事看了无需再踩一遍坑。6.3 给新手的几条实用建议最后分享几条当前开发中沉淀下来的个人经验。第一，统一编码规范。无论 URL 参数还是 Cookie 值，写入前能编码就编码，读取后能解码就解码，编码规范要贯穿整个链路。不要上游编码、下游不编码，也不要两端都编码导致二次编码。统一了规范，很多字符相关的问题自动消失。第二，优先使用原生 API 但也别放弃兜底。现代浏览器里URLSearchParams已经够用，但老系统和特殊内核的环境里，一个几行的正则方案能极大提升兼容性。两份代码并不冲突，可以像上面那样整合在一个函数里。第三，Cookie 属性必须显式声明。凡是在项目里新增 Cookie，path=/必须显式写上，需要跨子域就显式写domain，需要增强安全性就补上Secure和SameSite。不显式声明的结果就是默认值跟你想要的效果不一致，等到线上出问题再排查，成本远高于写代码那几秒钟。第四，及时检查和清理无效参数与 Cookie。线上跑久了，URL 里常常堆满各种历史遗留参数，Cookie 里也可能出现已经废弃的键。遇到这些问题，完全可以顺手在代码里增加清理逻辑，不要怕动刀，留着才是隐患。写到这里，这次实践的主要脉络就整理完了。对我个人来说，越是这种不起眼的前端小功能，越能体现基本功的扎实程度。URL 参数解析不只是split一下，Cookie 操作也不只是赋值一下，工程里的每一处细节都有它存在的理由。希望这篇记录能帮你少踩几个坑，也欢迎在实际使用过程中继续补充发现的新坑。
老读者可能还记得，我之前在某公司的运营后台系统里做过一次页面重构，其中有个特别不起眼但又绕不开的需求：从前端拿 URL 上携带的参数，顺手把一些状态写进 Cookie。听起来简单，真正动手的时候才发现，这里面的细节比想象中多得多。正好这段时间在群里也看到有朋友问类似的问题，我把当时的完整处理思路和踩坑记录整理成文，希望对正在做同类功能的人有点帮助。得先说清楚，这次分享针对的是纯前端方案，也就是在浏览器环境下，不借助任何后端能力去完成两项事情：第一，解析地址栏里?后面的查询参数；第二，对 Cookie 进行增删改查。这两种操作在前端日常开发里出现频率极高，无论是活动页、落地页、扫码登录跳转，还是页面之间传参，基本都会用到。1. 为什么这个需求值得单独写一篇文章有人可能会说，URL 取参不就是window.location.search截一下字符串，Cookie 不就是document.cookie读写一下，有什么好讲的？确实，光看 API 都简单，但真正放到项目里就会遇到一连串细节问题。我当时的项目场景是这样的：某活动页面需要根据推广人员的 ID 展示不同内容，推广 ID 通过链接参数传入；同时用户进入页面后，系统要把用户的来源渠道记录在 Cookie 里，方便后续行为追踪。听起来是不是很像很多公司都在做的渠道归因功能？需求不复杂，但当我开始写代码时，第一个问题就来了：URL 里除了可能有promoId，还有可能有utm_source、utm_medium等一堆参数，用户还可能手动改地址栏，甚至参数值里带特殊字符。如果只按split('&')的方式切，遇到参数值本身含有&或=就会被切得支离破碎。Cookie 那边的问题更隐蔽。比如我天真地以为document.cookie = 'percent=30'就能覆盖掉原来的percent值，结果发现不同路径下的同名 Cookie 会同时存在，读的时候只能读到其中一个；又比如我以为设置过期时间就直接写个时间字符串就行，结果时区和格式问题导致 Cookie 立刻失效。这些问题没有一个特别难的，但不踩一遍根本记不住。所以这篇文章我不会只给结论，而是从第一遍实现的“天真写法”开始，逐步演进到能扛住线上真实场景的可用版本，把每一处修改的前因后果讲清楚。这样你拿到的不只是一段代码，而是遇到相似问题时能自己推断出解法的判断能力。2. 获取URL携带参数的完整方案URL 参数解析是前端最经典的操作之一，但经典不意味着简单。从最初的字符串拆分，到原生 API 的统一处理，再到各种边界情况的兜底，这里面的演进过程很能说明问题。2.1 基础方案：字符串拆分与正则匹配最直觉的写法，就是把window.location.search里的内容按&拆开，再把每个键值对按=拆开。我一开始也是这么干的，代码如下：function getQueryParam(name) { const search = window.location.search.substring(1); if (!search) return null; const parts = search.split('&'); for (const part of parts) { const pair = part.split('='); if (pair[0] === name) { return decodeURIComponent(pair[1] || ''); } } return null; }这段代码放在大多数简单场景里都能跑，但问题也明显。比如 URL 是https://example.com/page?name=张三&from=baidu，它会正确返回张三。可如果参数值是https://example.com/redirect?target=https://mysite.com/page?a=1&b=2这种带 URL 的值，把整串按&一拆，b=2就被误认为独立参数了，后面target参数会被截断。还有一个常见问题是编码。浏览器地址栏里出现中文，实际location.search拿到的可能是已经编码过的内容，比如%E5%BC%A0%E4%B8%89，需要decodeURIComponent才能还原成张三。但要注意，如果参数值里有单字节的特殊字符，某些老版本浏览器里直接按=分割后再解码可能报错，稳妥做法是用正则先取原始值再解码。正则方案比split健壮一些，典型写法是对整个location.search做捕获匹配：function getQueryParamByRegExp(name) { const reg = new RegExp('(?:^|\\?|&)' + name + '=([^&]*)(?:&|$)'); const match = window.location.search.match(reg); return match ? decodeURIComponent(match[1]) : null; }这个正则的匹配范围是：参数名前面的边界只能是字符串开头、问号或&，取值部分捕获到下一个&或结尾。相比split，它天然避开了target=https://...a=1&b=2这种值里带&时的误切吗？其实也避不开，因为值里出现未编码的&时，正则仍然会在那个位置截断。也就是说，任何靠&分隔来解析的方案，都要求 URL 在拼接时对参数值做过正确的encodeURIComponent。这反而给了我一个启示：与其在解析端跟字符串较劲，不如从源头保证拼接端编码正确。这也是后面我们要重点强调的规范问题。2.2 标准方案：URLSearchParams 的使用与限制后来我全面转向了原生 API：URLSearchParams。这玩意儿就是浏览器专门为查询字符串设计的解析器，代码干净利落：function getQueryParamByURLSearchParams(name) { const searchParams = new URLSearchParams(window.location.search); return searchParams.get(name); }三行搞定，而且不用手动解码，URLSearchParams.get()内部会帮我们处理好%XX形式的编码内容。如果参数不存在，get()返回null，语义也很清楚。URLSearchParams不是只能读一次，同一个实例可以反复调用get查多个参数，也可以遍历entries()、keys()、values()，很方便。比如我当时需要把 URL 里所有utm_开头的参数打包上报，就是直接遍历：const searchParams = new URLSearchParams(window.location.search); const utmParams = {}; for (const [key, value] of searchParams.entries()) { if (key.startsWith('utm_')) { utmParams[key] = value; } }这个 API 的兼容性在现在的浏览器环境下已经没什么问题了，主流的现代浏览器和新版本移动端 WebView 都支持。但如果你手头有需要兼容极老内核的项目，或者遇到URLSearchParams被某些安全扫描策略误判的情况，前面那段正则兜底方案还是得留着。URLSearchParams也不是没有坑。最大的坑在于：如果 URL 参数是从hash（#后面）部分携带的，window.location.search根本获取不到，因为#后内容属于location.hash。有些单页应用的路由参数就是放在 hash 里的，比如https://example.com/#/order?orderId=10086，这时候直接 }new URLSearchParams(window.location.search)} 拿到的是空对象，必须手动从location.hash切出问号后的部分再解析。这个情况很容易被忽略。2.3 兼容双场景的实用封装为了把search和hash两个来源都覆盖到，也为了让旧项目能平滑过渡，我最后在项目里沉淀了一个统一的参数获取函数，核心逻辑是依次尝试多个来源，并保留正则兜底：function getUrlParam(name) { // 直接参数形式 const direct = getParamFromString(window.location.href.split('?')[1] || ''); const value = direct.get(name); if (value !== null) return value; // 从 hash 中解析 const hashIndex = window.location.href.indexOf('#'); if (hashIndex !== -1) { const hashSearch = window.location.href.substring(hashIndex).split('?')[1] || ''; const fromHash = getParamFromString(hashSearch); const hashValue = fromHash.get(name); if (hashValue !== null) return hashValue; } return null; } function getParamFromString(queryString) { if (typeof URLSearchParams !== 'undefined') { return new URLSearchParams(queryString); } // 老浏览器兜底 return { get(name) { const reg = new RegExp('(^|&)' + name + '=([^&]*)(&|$)'); const match = queryString.match(reg); return match ? decodeURIComponent(match[2]) : null; } }; }这段代码的用意不是炫技，而是把不同场景的差异收敛在一个入口里，调用方不关心参数到底是从哪段位置来的，只关心“这个参数叫什么”。实际用下来，这种封装确实省了不少事，尤其是多个页面都要做类似初始化的时候，统一入口比每处各写一遍要干净得多。3. Cookie 操作的完整细节与安全问题Cookie 这块的 API 更简单，就是一个document.cookie，但它背后牵扯到的属性配置和语义细节，远比表面看到的要多。很多新手第一次写 Cookie 相关代码时，最大的困惑在于：document.cookie既表示“获取整个 Cookie 字符串”，又可以被赋值来写入单个 Cookie，这种兼顾读写的设计并不直观。3.1 读 Cookie 的正确姿势读取 Cookie 时，document.cookie返回的是一个分号分隔的字符串，例如"name=张三; token=abc123"。要取其中某个键的值，不能直接document.cookie.name，必须自己解析字符串。我见过最朴素的读法是用数组方法做匹配：function getCookie(name) { const cookieString = document.cookie; const cookies = cookieString.split('; '); for (const cookie of cookies) { const index = cookie.indexOf('='); const key = cookie.substring(0, index); const value = cookie.substring(index + 1); if (key === name) { return decodeURIComponent(value); } } return null; }这里有两个容易翻车的地方。第一，split('; ')用的是分号加空格，但某些浏览器环境下 Cookie 字符串里可能没有空格，或者多个空格，所以稳妥做法是split(';')之后再对每段做trim()。第二，Cookie 的值同样可能被编码，写入时可以用encodeURIComponent处理，读取时就相应地decodeURIComponent还原，否则遇到中文或特殊符号会显示乱码或直接报错。用正则写也可以，还能把代码压缩到更短：function getCookie(name) { const match = document.cookie.match(new RegExp('(^|;\\s*)' + name + '=([^;]*)')); return match ? decodeURIComponent(match[2]) : null; }都行，核心思路是一样的。但这里我必须特别指出一个安全层面的关键知识点：如果服务端给某个 Cookie 加上了HttpOnly属性，那么这段纯前端代码无论如何是读不到该 Cookie 的，document.cookie里压根不会包含它。这不是 bug，是刻意设计，目的就是防止跨站脚本（XSS）攻击窃取带有敏感信息的会话凭证。大家写前端代码时如果发现某些 Cookie 读不到，先别急着怀疑自己的解析逻辑，去开发者工具里看看这个 Cookie 是不是带了HttpOnly标记，其中“HttpOnly”指的就是禁止脚本访问的意思。前端脚本在登录态这块能做的很有限，比如下面说的document.cookie写入只能影响非 HttpOnly 的 Cookie，不该试图绕过这套安全机制。3.2 写 Cookie 时容易忽略的属性细节写入 Cookie 的代码相当直观：document.cookie = 'key=value';但这个写法有个隐含的副作用：Cookie 的默认生命周期是“会话级”，也就是浏览器标签页关闭后就没了。如果希望 Cookie 能存得更久，就得显式设置expires或max-age。我当时的需求是记录用户来源渠道，希望它能保留 30 天。于是写出了第一版：function setCookie(name, value, days) { const date = new Date(); date.setTime(date.getTime() + days * 24 * 60 * 60 * 1000); document.cookie = name + '=' + encodeURIComponent(value) + '; expires=' + date.toUTCString() + '; path=/'; }date.toUTCString()是一个必须使用的细节，不能用浏览器本地时区的toString()来生成时间串。Cookie 的expires属性，遵循的是 HTTP 日期格式，本质上是格林尼治标准时间，也就是 UTC 时间。如果用toLocaleString()之类的方法生成，不同时区的电脑上给出的格式可能不同，轻则 Cookie 有效时长产生偏移，重则直接被浏览器判定为非法日期而拒绝写入。path=/则是为了指定 Cookie 的作用路径。默认情况下只对当前路径生效，比如你在https://example.com/promo/下写入，在https://example.com/order/下就读不到。这往往不是我们预期的行为，因为一个站点内的多个页面都要共享这个 Cookie。统一指定path=/意味着整站都能访问到，这是最常用的配置，建议条件允许的情况下直接写上去。再说说domain属性。它用来控制 Cookie 在哪个域名及子域名下生效。默认只对当前完整域名生效，比如sub.example.com下写入的，example.com读不到。如果业务希望主域和子域共享 Cookie，可以显式设置domain=example.com。但这个属性要谨慎使用，一旦设置了较宽的域范围，Cookie 就会被发送到该域下的所有子域，如果被 XSS 利用，影响面会跟着扩大。还有Secure和SameSite两个属性。Secure要求仅限 HTTPS 连接传输，SameSite则限制跨站请求能否携带 Cookie。早期有不少项目不重视SameSite，导致在跨站跳转场景下 Cookie 发送行为变得很诡异。像我们做渠道排查时，从外部链接进入页面，Cookie 携带规则就受SameSite影响。现代浏览器里这方面的规则已经比较严格，新写代码时最好主动加上SameSite=Lax或明确业务需要后再调整。3.3 删除 Cookie 的方法与本质删除 Cookie 的办法看起来很绕：把过期时间设为过去的时间点，让浏览器判定它已过期，从而自动清理。function removeCookie(name) { // 注意：path 必须与写入时一致，否则删除不掉 document.cookie = name + '=; expires=Thu, 01 Jan 1970 00:00:00 GMT; path=/'; }这里最大的坑就是路径不一致。如果你写入时设置了path=/，删除时却不带path=/，浏览器会把删除操作视为“在默认路径下写入一个新的名为 name 的空 Cookie”，结果原来的 Cookie 依然活得好好的。很多同学遇到“Cookie 删不掉”的问题，十有八九就是路径没对上。另一个容易忽略的问题是对同名 Cookie 的处理。浏览器允许同一个域名、同一个 name、不同 path 的 Cookie 并存，比如同时存在name=1; path=/和name=2; path=/promo/。读取时document.cookie会按路径优先级把更具体的那个排到前面，但删除时如果不把每个路径下的同名 Cookie 都删一遍，很可能出现“删了又冒出来”的错觉。处理办法也不复杂，就是按常见的几个路径分别执行同名删除：function clearCookieByName(name) { ['/', '/promo/', '/order/', '/user/'].forEach((path) => { document.cookie = name + '=; expires=Thu, 01 Jan 1970 00:00:00 GMT; path=' + path; }); }这招虽然有点暴力，但在排查问题时很管用，特别是当你怀疑某个历史遗留的旧路径 Cookie 在捣乱时。4. 实操案例：某活动页的渠道参数与 Cookie 联动这一章我以当时实际做的一个模拟项目为例，把前面讲到的所有知识点串起来，走一遍完整流程。我这里说的只是一个用来讲原理的简化版系统，但处理方式与线上项目一致。4.1 需求拆解与方案设计当时的设计是这样的：某运营活动需要根据渠道参数展示不同内容，同时把渠道信息预存在 Cookie 里，后续用户访问站内其他页面时持续生效。具体拆解出三个子任务：第一，从 URL 里读取channel参数，比如?channel=baidu，如果参数存在，在页面顶部展示对应的渠道标识。第二，把读取到的渠道值写入 Cookie，命名channel_source，有效期 30 天，全站可读。第三，如果 URL 里没带channel参数，则回退读取 Cookie 里的channel_source作为兜底来源，两者都没有就显示默认渠道。这个方案本身不复杂，但它的好处是能把参数解析和 Cookie 操作串联在同一个业务过程里，考察了编码、过期时间、路径统一、默认值回退等多个细节。4.2 完整实现与关键步骤核心代码大概长这样：(function () { // 1. 从 URL 获取渠道参数，来自 query 或 hash const channel = getUrlParam('channel'); let channelValue = channel; // 2. 如果 URL 没有，尝试读已有 Cookie if (!channelValue) { channelValue = getCookie('channel_source'); } // 3. 如果 URL 有，则以新的 URL 参数为准，并刷新 Cookie if (channel) { setCookie('channel_source', channel, 30); } // 4. 页面展示处理 const finalChannel = channelValue || 'default'; const el = document.getElementById('channel-banner'); if (el) { el.textContent = '当前渠道: ' + finalChannel; } })();这里面的顺序是有讲究的：先看 URL 参数，再看 Cookie，用新的覆盖旧的。这样设计是为了避免“用户从新的渠道链接进来，却仍然被旧 Cookie 影响”的脏数据问题。做过渠道归因的应该都懂，这种覆盖逻辑如果不加，后续分析数据时会出现张冠李戴的情况。对应地，setCookie和getCookie两个工具函数直接采用前面章节里封装好的版本：function setCookie(name, value, days) { const date = new Date(); date.setTime(date.getTime() + days * 24 * 60 * 60 * 1000); document.cookie = name + '=' + encodeURIComponent(value) + '; expires=' + date.toUTCString() + '; path=/'; } function getCookie(name) { const match = document.cookie.match(new RegExp('(^|;\\s*)' + name + '=([^;]*)')); return match ? decodeURIComponent(match[2]) : null; }这段代码在实际环境中运行得很稳定。不是说它多高级，而是每一步都把该固定的属性固定住了：过期时间用了toUTCString()，值做了百分比编码，路径统一用根路径，读取时做了正则提取和解码。基本功扎实了，线上就不会出幺蛾子。4.3 联调阶段的验证要点代码写完只是第一步，真正容易出问题的是联调阶段。我在验证时总结了几个核心检查项，现在分享给大家。用浏览器开发者工具的“Network”面板检查 Cookie 在请求中的携带情况，看是否存在跨路径丢失或SameSite阻断。修改系统时间能不能用来测试 Cookie 过期？可以，但不推荐，因为容易把本地环境搞乱，更合理的做法是把过期时间临时改短，比如setCookie的 days 参数传0或-1来观察行为。对于 URL 参数的测试，注意分别验证带参数、不带参数、参数值含中文、参数值含特殊字符（如%2C）几种情况。还有一个我特别想强调的点：写完 URL 参数拼接时要主动使用encodeURIComponent，不要直接拼字符串。比如用户从活动页跳转到落地页，需要把渠道参数透传过去，正确写法是：const nextUrl = 'https://example.com/landing?source=' + encodeURIComponent(channelValue);如果不编码，channelValue里万一有&或者=，整个 URL 结构就乱套了。这个习惯看起来小儿科，但它能避免一大堆解析层面的诡异 bug。前后端传参时同理，别让拼接端的不规范操作成为解析端事故的导火索。5. 常见问题排查与避坑经验在这类需求的开发过程中，我遇到过不少看似“玄学”的问题，最后排查下来基本都是小细节导致。整理成速查表，方便大家对照自查。5.1 中文参数乱码与解码时机问题最典型的现象：URL 里明明带着?name=张三，页面里取出来却变成一堆%E5%BC%A0%E4%B8%89。这通常不是解析代码的问题，而是没有对取值结果做decodeURIComponent。反过来，如果已经解码一遍，页面显示还是乱码，那要考虑是不是参数在拼接端被重复编码了。比如先用encodeURIComponent加工过一次，服务端又整体编码一次，前端解一层就还原不完整。排查这类问题，直接在调试工具里打印window.location.search，看原始字符串到底长什么样，再决定解一层还是两层。字典里常见的情况还有一种：写入 Cookie 时用了encodeURIComponent，但读取时忘了decodeURIComponent，也会导致页面展示的内容是编码态。规则很简单：写入端做了什么处理，读取端要对称地做反向处理，两端不匹配必然出错。5.2 Cookie 过期时间时区与清理边界过期时间问题前面说过用toUTCString()来规避，但还有一个隐藏点：new Date()和date.toUTCString()之间的时间基准要统一。如果你在某处把date.getTime()直接拼进 Cookie 值，这就不是一个标准时间格式，浏览器不一定认可。我自己踩过一次比较经典的坑是：setCookie('token', value, 7)设置 7 天过期，结果第二天再访问时 Cookie 已经没了。排查后发现代码里把days误传成了字符串，导致日期计算的数值运算变成了字符串拼接，生成的过期时间错乱。所以对工具函数来说，参数校验很有必要：function setCookie(name, value, days) { const daysNum = Number(days) || 0; // ... }如果传入不合法，至少不会让整个 Cookie 写入挂掉。5.3 同名 Cookie 路径混乱导致覆盖失败这个问题前面也提过，但值得单独拿出来强调一次。浏览器允许同名、不同路径的 Cookie 共存，所以“覆盖”和“删除”都没有想象中那么理所当然。比如你在path=/promo/下设置过channel_source=abc，又在path=/下设置channel_source=xyz，读取时document.cookie字符串里会把两个都列出来，但getCookie里的正则匹配从左往右找，大概率匹配到路径更具体的那一个，也就意味着你以为读的是全站这个值，实际拿到的可能是子路径下的旧值。排查手段很简单，开发者工具的 Application 面板里，Storage/Cookies 下面能看到每个 Cookie 的 Path 列。如果发现多个同名记录，把它们对应的路径逐个删除再重新设置即可。长期方案是统一各处的写入路径参数，写path=/就全员path=/，别一会儿有、一会儿没有。5.4 大小限制与同源策略的边界Cookie 的容量限制是 4KB 左右，指的是单个 Cookie 的键值总和。别试图把一串长文本塞进去，比如用户填的表单数据、日志报文之类，超了的话浏览器会静默拒绝写入，代码不报错但功能不生效。我当时在调试一个用户偏好设置时就是吃了这个哑巴亏，document.cookie赋值语句执行了，document.cookie用来读取也验证过，但一刷新全没了，后来一量长度才意识到是超过了容量限制。如果确实要在浏览器端存储稍大的数据，优先考虑localStorage或sessionStorage这类 Web Storage 方案。它们不是 Cookie 的替代品，但容量上限宽松得多。需要传给服务端的这种轻量标识才考虑 Cookie。选型问题做在前面，后面就不会因为容量不足而返工。6. 沉淀下来的工具函数集与个人体会项目结束后，我把这次用到的方法整理成了一个小模块，放到团队内部公共代码库里。这套函数也不复杂，但胜在稳定，后续好几个项目直接拿来复用，没有再因为 URL 参数或 Cookie 的问题拉长排查时间。6.1 统一封装的参数处理工具集// 将 URL 查询字符串解析为对象，兼容 URLSearchParams 缺失场景 function parseQueryString(queryString) { const result = {}; if (!queryString) return result; const parts = queryString.split('&'); parts.forEach((part) => { if (!part) return; const index = part.indexOf('='); let key = index > -1 ? part.substring(0, index) : part; let value = index > -1 ? part.substring(index + 1) : ''; try { key = decodeURIComponent(key); value = decodeURIComponent(value); } catch (e) { // 个别字符解码失败时保留原样，不影响整体解析 } if (Object.prototype.hasOwnProperty.call(result, key)) { result[key] = [].concat(result[key], value); } else { result[key] = value; } }); return result; } // 获取指定 URL 参数，优先 search，兼容 hash function getUrlParam(name, targetUrl) { const url = targetUrl || window.location.href; const searchIndex = url.indexOf('?'); const hashIndex = url.indexOf('#'); let search = ''; if (searchIndex !== -1) { const searchEnd = hashIndex > -1 ? hashIndex : url.length; search = url.substring(searchIndex + 1, searchEnd); } const queryObj = parseQueryString(search); if (queryObj[name] !== undefined) return queryObj[name]; // 尝试解析 hash 部分的参数 if (hashIndex !== -1) { const hashSearchIndex = url.indexOf('?', hashIndex); if (hashSearchIndex !== -1) { const hashQuery = url.substring(hashSearchIndex + 1); const hashObj = parseQueryString(hashQuery); if (hashObj[name] !== undefined) return hashObj[name]; } } return null; }这个版本的parseQueryString在处理重复参数时会把多个值合并成数组，这是个很实用的细节，比如?id=1&id=2能同时取到两个候选值。getUrlParam则是既看 query 部分也看 hash 部分，覆盖了单页应用场景。这段代码不依赖URLSearchParams，因此在老浏览器里也能跑，同时也很好理解。6.2 Cookie 工具集const CookieUtil = { set(name, value, days, path) { const expires = days ? new Date(Date.now() + days * 864e5).toUTCString() : ''; const pathStr = path || '/'; const cookieStr = name + '=' + encodeURIComponent(value) + ';' + (expires ? ' expires=' + expires + ';' : '') + ' path=' + pathStr + ';'; document.cookie = cookieStr; }, get(name) { const match = document.cookie.match(new RegExp('(^|;\\s*)' + name + '=([^;]*)')); return match ? decodeURIComponent(match[2]) : null; }, remove(name, path) { const pathStr = path || '/'; document.cookie = name + '=; expires=Thu, 01 Jan 1970 00:00:00 GMT; path=' + pathStr + ';'; } };remove方法默认删根路径下的 Cookie，但如果你见过某些场景下写入时没带 path，删除时同样可能需要多尝试几个路径。这一点我在注释里也标明并沿用，前端同事看了无需再踩一遍坑。6.3 给新手的几条实用建议最后分享几条当前开发中沉淀下来的个人经验。第一，统一编码规范。无论 URL 参数还是 Cookie 值，写入前能编码就编码，读取后能解码就解码，编码规范要贯穿整个链路。不要上游编码、下游不编码，也不要两端都编码导致二次编码。统一了规范，很多字符相关的问题自动消失。第二，优先使用原生 API 但也别放弃兜底。现代浏览器里URLSearchParams已经够用，但老系统和特殊内核的环境里，一个几行的正则方案能极大提升兼容性。两份代码并不冲突，可以像上面那样整合在一个函数里。第三，Cookie 属性必须显式声明。凡是在项目里新增 Cookie，path=/必须显式写上，需要跨子域就显式写domain，需要增强安全性就补上Secure和SameSite。不显式声明的结果就是默认值跟你想要的效果不一致，等到线上出问题再排查，成本远高于写代码那几秒钟。第四，及时检查和清理无效参数与 Cookie。线上跑久了，URL 里常常堆满各种历史遗留参数，Cookie 里也可能出现已经废弃的键。遇到这些问题，完全可以顺手在代码里增加清理逻辑，不要怕动刀，留着才是隐患。写到这里，这次实践的主要脉络就整理完了。对我个人来说，越是这种不起眼的前端小功能，越能体现基本功的扎实程度。URL 参数解析不只是split一下，Cookie 操作也不只是赋值一下，工程里的每一处细节都有它存在的理由。希望这篇记录能帮你少踩几个坑，也欢迎在实际使用过程中继续补充发现的新坑。