前端優(yōu)化: 跳轉(zhuǎn)網(wǎng)址可以直接打開

簡單分析可以進(jìn)行測試為，分享出去的卡片，均可以通過直接打開（請務(wù)必測試結(jié)果是否登錄，神坑）。

這里牽扯到兩個問題。

頁面渲染邏輯

query 所攜帶的參數(shù)

組件內(nèi) URL 問題

第一個問題會牽扯到后端接口下發(fā)的內(nèi)容，比如這樣的場景：

后端發(fā)布一個數(shù)據(jù)列表，不管出于什么原因，列表包含了單擊列表的所有細(xì)節(jié)，然后共享這些細(xì)節(jié)。這種情況基本上就是一個分享炸彈，微信小程序天然的頁面爬蟲也是一個 gg。在這種情況下，你需要優(yōu)化前端和后端，分離 xdetail 接口，通過 id 獲取細(xì)節(jié)等等，并確保共享頁面接口設(shè)置好了，這樣你就不用登錄了。

然后就是這個 id 之類的東西如何帶進(jìn)去，這就是第二個問題。

有時候我們可能會出現(xiàn)因為對于一些具有特殊原因在 localStorage 或干脆沒有直接掛在 getApp（） 實例內(nèi)存上，臨時儲存上個頁面的 key，然后下個頁面設(shè)計出來后在 onLoad 中拿這個 key 去使用。如果你有這個系統(tǒng)操作能力或者社會歷史文化遺留環(huán)境問題，務(wù)必將其發(fā)展放在下個頁面的 path 上，掛載在 query 后面。原因之一就是網(wǎng)絡(luò)爬蟲技術(shù)不會從上頁面給你帶內(nèi)存管理數(shù)據(jù)，更不會為了驗證本地緩存內(nèi)容是否合理有效。

第三個問題也很常見，因為一個小程序 seo 可以使用 navigator 是用來導(dǎo)航的，而且很有可能 nav 的功能封裝在一個組件中，比如卡片類組件，它本身就是一個視圖(記住要更改為 navigator)和其他元素。后面可能跟著一個路徑，這個路徑是在 bindtap 之后從組件所攜帶的項計算出來的，而 item 是父頁面所攜帶的接口列表元素。如果發(fā)生這種情況，首先用導(dǎo)航器替換組件的根視圖，刪除 bindtap 和相應(yīng)的事件，并編寫 itemnavigator 的 url 屬性。Url (或類似的內(nèi)容) ，然后再執(zhí)行一個步驟，其中父頁面獲取列表，將列表傳遞給 map，或者使用 url 傳遞給 list 元素，在這里 url 將直接計算。