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

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

這里牽扯到兩個(gè)問題。

頁面渲染邏輯

query 所攜帶的參數(shù)

組件內(nèi) URL 問題

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

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

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

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

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