前幾天，團隊里有個小伙伴遇到一個問題，卡殼了大半天。我覺得這個例子值得拿出來分享給大家。希望大家以后遇到類似的問題能順利繞過這種坑。

業(yè)務場景很常見，就是為了配合小程序中特定頁面的推廣，區(qū)分推廣渠道和人員，逐步實現(xiàn)較高精準度的投放。稍微特殊一點的地方在于，這個頁面在小程序中。

為了達到區(qū)分推廣渠道和人員的目的，我們決定采用在頁面url末尾添加參數src和uid的方法。由于這樣的推廣不能使用體驗版進行測試，所以全程我們只能在微信開發(fā)者工具中模擬推廣行為。

頁面本身的交互是這樣的：

在index頁面點擊按鈕跳轉到webview嵌套的h5頁面pages/webhref/webhref?url=xxx。跳轉時需要攜帶index頁面設置的參數uid和src，以及目標頁面地址url。在webhref頁面的onload方法中再接收options對象并解析。

首先，在編譯模式中設置index頁面的啟動參數，模擬index頁面被推廣的場景：? ? ??

? ? ? ?

然后在對應按鈕的點擊事件中執(zhí)行跳轉：

let?newurl?=?api.host+'/m/'+?pageurl?+'&src='?+?this.data.src?+?'&uid='?+?this.data.uid;wx.navigateTo({??url:?'../webhref/webhref?url='?+?newurl});

這樣，在跳轉后的頁面webhref的onload方法中就可以接收到這幾個參數了：

onLoad:?function?(options)?{??if?(options.url.indexOf('/pages')?==?-1)?{ console.log('options--',options); this.setData({ url: options.url + '?src=' + options.src + '&uid=' + options.uid }) }} //?{url:?"https://xxxxx.com.cn/m/bj",?src:?"111",?uid:?"222"}

像上面這樣，將接收到的這三個參數拼接起來就好了。

看起來的確就是這么簡單，然鵝~

如果過不了幾天，options.url中需要帶?該怎么辦呢？

那我們就需要兼容一下options.url有沒有?兩種情況了。這個好說：

onLoad: function (options) { if (options.url.indexOf('/pages') == -1) { let tourl = options.url; ????let?params?=?(tourl.indexOf('?')!=-1???'&':?'?') + options.src?+?'&uid='?+?options.uid?????? this.setData({ url: tourl + params ????})??}}

也不難嘛，是不是~

可是我們貌似忽略了另一個問題，如果options.url中如果有?的話，webhref頁面setData的url就會包含兩個?了，這……這就需要用到encodeURIComponent和decodeURIComponent兩個方法了。

encodeURIComponent() 函數可把字符串作為 URI 組件進行編碼。decodeURIComponent()可以進行對應的解碼。

So，為了避免瀏覽器誤解，我們在index頁面執(zhí)行跳轉時，需要使用encodeURIComponent()將url進行轉碼，到webhref之后再用decodeURIComponent()進行解碼。然后使用setData重置一下webhref頁面地址就好了。就像這樣：

// pages/index/index.jslet newurl = api.host+'/m/'+ pageurl;wx.navigateTo({ url: '../webhref/webhref?url=' + encodeURIComponent(newurl) + '&src=' + this.data.src + '&uid=' + this.data.uid});// pages/webhref/webhref.jslet newurl = decodeURIComponent(options.url);let params = (newurl.indexOf('?')!=-1 ? '&': '?') + options.src + '&uid=' + options.uidthis.setData({ url: newurl + params})看到這里，可能有的小伙伴會說，為什么不把tourl和參數src/uid一起編碼解碼呢？那樣不是更方便嗎？

其實，如果只推廣一個頁面完全可以如此。但這里關聯(lián)著我們另一個小需求，就是webhref頁面也要做推廣。所以，webhref頁面接收options時，只需要獲取url部分，然后拼接自身頁面設置的參數src和uid，拼接成完整的推廣鏈接。如果一起編碼解碼，options.url中就會包含index頁面中的src和uid參數，增加url部分的分離難度。

說句俗話，行百里者半九十。果然如此。分析代碼確認沒問題了，但是webhref頁面的數據入庫情況依然有問題。

找了各種原因，最終發(fā)現(xiàn)，在設置啟動參數時，小伙伴使用了編碼后的url和編碼前的src和uid，類似這種：url=https%3A%2F%2F100audio.com%2F%3Furl_targeting%3D1&src=111&uid=bbb。原來是自己挖的坑，還說啥呢？

所以，大家還需要注意：

設置啟動參數時，url和后面的參數要保持編碼的一致性。切記！

還是那句話，我們踩的不是坑，而是我們自己技術上的模糊點。每一個點踩實了，我們的技術能力才能得到切實的提高。和大家共勉~

原創(chuàng)不易，你的鼓勵是我持續(xù)進步的動力，希望親愛的們給一個在看或者小小的?喲~?

CC推薦·?加我微信(codenotes66)，進我的技術交流群·?關注我的公眾號，做一個有趣的技術人………

總結

以上是生活随笔為你收集整理的小程序二级页面tabbar_小程序页面推广踩坑记的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。