uni-app開發跨平臺小程式開發的諸多坑【轉載】

uni-app開發跨平臺小程式開發的諸多坑，最近用uni-app開發小程式的時候遇到不少了。本篇收集和記錄自己在開發小程式過中遇到的問題和解決辦法。之前有很多問題解決了，沒記錄在案。往後遇到的問題，我儘量記錄下來。部分小程式平臺不好開發，尤其是需要相容多個平臺，所以如果你和我一樣，想必避免不了遇到 uni-app開發跨平臺小程式開發的諸多坑。

根據平臺的不同，我預期開發的小程式包括微信、QQ、抖音、快手，百度、支付寶、小紅書(pass，不支持個人及個體戶)、京東（pass，不支持個人及個體戶）。

開發跨平臺小程式從登錄開始說起。

登錄邏輯從 uni.checkSession 開始的，支付寶小程式率先登場第一個不支持，所以支付寶小程式接入登錄邏輯相容也暫停。

uni-app 的 uni.login 已經不支持百度小程式了，改成用 swan.getLoginCode 獲取 Authrization Code 來調用 getSessionKey 介面獲取 Session Key 和 open_id。說個題外話，從 github 上開源的百度介面 go 版本SDK 慘淡的7個 star 來看，這個平臺是不是沒接入的必要了？

申請了appid之後，後來上傳發佈小程式時，突然支付寶的appid和app_secret秘鑰找不到了，沒找到藏在哪裡。懵逼了好一陣，為啥小程式相關的設置裡面沒有appid的信息？最後找到賬號中心才看見。

還發現需要下載支付寶秘鑰生成工具，設置驗簽，應該是所有的小程式平臺中，最複雜的一個了。看上去應該是 Java 開發的，文檔也是完全從 Java 技術人員的角度給出。這一點上，從個人開發接入的體驗上感受，抖音、微信、快手的介面文檔相比於支付寶對開發者要相對友好一些。

支付寶小程式開發過程中，已經登錄的情況下，調用支付寶授權登錄介面，也會報【40002 – 無效的AppID參數】。authrization_code 是第一次申請使用的，結果也用不了。

支付寶的開發平臺的資料是很亂的，你往往找appid是賬號中心才能找到的。然找 api 介面功能變數名稱，又要在介面文檔以外的某個點才能找到。抖音的都是直接在當前介面就找到響應API網關功能變數名稱了。完美詮釋了什麼叫做 A litter copy is better 。然後支付寶首頁或者開發者文檔，沒有社區快捷鏈接。搜索40002的時候，找不到社區，還是在其他搜索引擎搜索，才找到社區的入口。等找到入口時，就有開始新一輪的掃碼登錄。

uni-app以及開發的問題

開發不相容細節， 還很多。像 MySQL8.0 問題和 docker 疑難問題 也是開發過程中必須自己解決的自建伺服器問題。
還有些問題則是小程式平臺相容問題，比如：

各平臺儘管都是基於 oauth 2.0 來授權，但是不同平臺 authrization_code 和 access_token 有效期不一樣。而 session_key 的長度也不一樣。如果需要獲取手機號，又是分門別派的。

開發環境問題。

比如在支付寶的沙箱環境，調用會報 【報40002 – 無效的AppID參數】 的錯誤。參數無論多了還是少了，都會驗簽失敗。這個我有很深的印象，這種驗簽結果只有一門語言叫 Java 開發的 API 遇到過。我很納悶，這樣的話，介面如果需要擴展或者收縮，豈不是所有調用者都要跟著一起改？加密方法整的挺複雜的，調試過程中一直報 【crypto4go: certificate failed to load】。

百度智能小程式，需要特別註意。百度引入靜態圖片資源不支持絕對路徑。只能用相對路徑。

使用百度開發者工具的bug 比較多，他的開發者工具要有兩個掃碼的登錄的地方的，還有比較坑的是：

這裡也是沒辦法，只能救助於社區。社區顯示，這個問題早在2019年就已經有人提過，2022年也有人重現。現在2023年了，我在最新版百度開發者工具也遇到了雷同的 Bug 報錯。

早先百度智能小程式是支持 uni-app 的 uni.login 調用的 swan.login。但後來他搞出來一個 getLoginCode 替代了前者。必須改為 【非 web-view 組件場景下登錄請使用 button 組件或聯合登錄 / 手機號授權登錄方式實現登錄，獲取登錄憑證請使用 swan.getLoginCode 實現。】了。

前一陣，我是跟Rust 編譯器作鬥爭，最近很多時候，我都在跟幾個不同平臺的開發者工具作混戰。百度智能者小程式的登錄相關的前端代碼，是我最難調的一個平臺。它似乎自成一體，獨闢蹊徑，走了一條其他小程式平臺截然不同的道路。它出的問題是最多的。

多端小程式審核問題

做小程式，審核問題幾乎貫穿整個周期。從申請appid、寫基礎信息（百度的logo有特殊尺寸和形狀限制，支付寶的基礎信息拉下來三頁多到像是湊KPI一樣），最後來到能來到小程式版本審核的這扇巨大門口，都是非凡的成就了。期間可謂費勁九牛二虎之力，百感交集。當你本以為發佈就起飛的時候，往往這時候生活要給你來上當頭一棒，審核失敗！您給我回去修改您咧，走你！

支付寶代碼審核：沒有接入登錄邏輯時，支付寶代碼審核通過，但是什麼接入審核不通過。沒想明白，有可能是支付寶認為起名小程式不適用在支付寶小程式生態。後來間隔一周打來兩次電話，第一次說了下審核結果不通過，介面調用空白；第二次咨詢了一下我的小程式是用於什麼場景的，我的小程式審核是又通過了。我去後臺看下，沒法上架。作罷。

抖音對起名小程式違規。其實我已經接入了抖音官方的 antidirt 內容安全檢測，但是審核的時候還是，審核那邊不知是出Bug還是疏漏了，總之還是報【小程式文字上傳板塊未做風險詞以及風險內容過濾，不符合平臺要求，請補充信息安全防護能力或接入平臺內容安全檢測介面，詳見下方指引鏈接中9.5板塊】。後來第二次找客服，把我列印的日誌截圖發過去了。

另外，小logo的製作也需要圖片檢測，圖片安全加了之後，發現 chatGPT 生成的圖片地址，沒法從抖音那邊下載。那沒辦法了，生成logo 這塊功能就沒法上線了。

百度智能小程式認為起名小程式只有一個起名的功能，功能單一，所以沒有通過審核。

快手頭三次審核速度都挺快的，仔細列了不相容機型，一開始的小程式簡介和作用與實際不符，然後提交沒響應。一一改了，重新提交。

QQ 連續多次提交都是是吧。審核失敗無原因。QQ社區沉悶，並米有什麼技術或客服響應問題。

想發版本？先猜測一下審核失敗的原因吧，然後改了，繼續掃碼提交審核。接二連三的打回再提申之後，驀然發覺好些天過去了。你依舊需要猜測它到底審核了什麼？是誰呢沒原因？我試試？我到底在哪裡？
QQ小程式審核他的時間就是個薛定諤的貓，你壓根不知道他在什麼時候會進行審核（2天起步），又在什麼地方給你不知道什麼審核原因的情況下打。另外你跑到社區問也沒用，那裡沒人回覆的，最早的回覆還是去年的。

開發小程式過程中掃碼這個事

我沒完全統計，每天如果每個平臺都需要發版的話，保守估計，反覆掃二維碼的次數需要不低於 30 次。微信、QQ、支付寶的登錄時間會很快失效，所以需要天天很高頻率掃碼登錄。尤其支付寶，幾分鐘就強制失效，你要用功能，重新掃登錄，否則請出門左轉。快速失效，確實是一種安全策略，唯有快速失效，可保賬號安全？還有就是支付寶小程式裡面你要跳來跳去的，經常找不到東西，哈哈哈哈~~

從開發的體驗來說，web > 小程式開發效率，移動端還沒上過真是的應用還不知道具體審核會怎麼樣。因為 web 端發佈快，可以快速迭代。如果真的要上小程式端，不管處於獲客還是贏得流量，引流等考慮，小程式端作為最後一個節點來處理比較好。無論如何，web 端可以最快出版本。目前還是有優勢。

個人小程式開髮結論

就挑一個平臺，比如微信小程式在這一個平臺。為什麼是它？以為它目前是市面上所有的小程式的開山鼻祖。先把所有的功能，你包括設計功能、UI佈局、性能全給他弄好了。尤其包括底部 tab ！我記得有一次QQ提審時，報過一次審核不通過理由：QQ底部 tab 至少三個！而且他們的測試審核的時候，會掃你沒有展示出來頁面！也就是說，有些頁面你沒用到的，最好刪掉。

要有一個比較良好的心態，做小程式心態平和真的特別重要。特別一開始做的時候，需要充當開發者工具和第三方API的測試小白鼠。遇到問題，及時找出現問題的平臺社區進行反饋，能截圖儘量截圖（在保護敏感信息的前提下），提高處理問題的效率。畢竟有些問題不是出在你自身代碼上，你著急也沒有用。
面對審核的周期，要有一個預期：他們不會很快審核到你的。不要乾等，儘量先忙自己其他的事情。怎麼調整自己的焦慮心態，找些事情做，讓自己有意義的忙起來，就會減少自己的焦慮感。

在這個基礎上，再根據成熟度、流量、難易程度逐一佈局到其他的目標平臺（抖音、快手、QQ），最後再遷移到次優先順序（百度、支付寶、京東、小紅書）等平臺。每個平臺都有自己獨特的優勢和潛力，以及特殊性。

我記錄的比較瑣碎，開發過程中遇到以及已經解決和沒解決的問題，只多不少。一路走來，finally! 然後我的微信小程式\支付寶小程式\百度智能小程式【十倍網路工作室】已經上線了。
首頁功能目前只有兩個小功能繪製 logo 和起名字。後續將會推出更多更優質的模塊功能！