最近，微信小程序 掃碼簽到工具 正式上線了。

回首過去一個月的歷程，是時候該停下來做個階段性的總結了，回顧得失，以便持續改進。這篇文章，就總結一下過去跳過的那些坑吧。

這些坑大致可以歸為如下幾類：

• 小程序某些技術細節與常用技術存在不一致。文檔中雖有提及，如果不仔細看容易跳坑。

• 小程序的文檔太簡略，沒有注明支持哪些功能，哪些不支持，只有用了才知道。

• 小程序的bug。

列舉一下幾個比較典型的坑吧。  

小程序支持通過post獲取小程序碼（有點像菊花）。嘗試通過 wx.request 向微信服務器獲取 小程序碼 的圖片，結果發現返回的結果無法顯示。開始懷疑代碼有問題，調試之后，發現微信服務器返回的結果正確，而小程序會自動把二進制結果轉碼。更郁悶的是，這種轉碼丟失了文件內容，并且轉換是不可逆的。

于是，我們改方案，把服務器當中轉站，讓小程序使用 wx.downloadFile 從服務器下載圖片。在收到小程序下載圖片的請求之后，服務器直接和微信服務器獲取小程序碼的圖片，然后以附件的形式返回給小程序。

問題解決。

①掃碼簽到中用到了二維碼。

在開始的版本中，我們準備在Canvas上直接繪制二維碼，接著使用 wx.canvasToTempImage 函數保存為image文件，然后通過Image組件加載。

經過調試，一切順利。運行的時候呢，發現有時候 在繪制完圖片之后，調用 wx.canvasToTempImage 函數失敗。這種情況在調試無法重現，運行的時候偶爾出現，不穩定。

仔細檢查了代碼，沒問題啊。Google之后，有網友提出了解決方案，在drawImage完成之后，最好等3秒鐘再調用 wx.canvasToTempImage ，以保證保存成功。 

② Canvas和Image都不支持Base64圖片，Image無法保存。

最初的方案中，我們自己生成二維碼，后來為了兼容微信的“掃一掃”功能，我們決定改用小程序碼。

開始，我們把Image的src設置為Base64格式，從服務器上通過request獲取圖片的Base64編碼。小程序開發工具和iPhone上面測試都沒有問題，唯獨Android手機上無法正常顯示圖片。哦，原來在Android上，Canvas和Image都不支持Base64圖片。可是...小程序開發文檔中并沒有這方面的說明啊。 

怎么解決Android手機上的這個問題呢？如果把Image改成URL形式呢，小程序無法保存圖片，以致即使是相同的圖片，每次都要從服務器獲取，這又加重了服務器的負擔。這樣吧，使用 wx.downloadFile 把文件下載到本地，然后再處理。 

上文提到，最初我們使用的簽到二維碼是自己生成的二維碼 (QRCode) ，正方形的那種。識別率高，缺點是不支持微信“掃一掃”。在使用過程中，我們發現，相當數量的用戶看見二維碼，第一反應會使用微信“掃一掃”去掃二維碼。為了滿足這個需求，那就把二維碼替換成微信的小程序碼（有點像菊花）吧。

可是，和方形二維碼相比，識別小程序碼的成功率非常低。小程序碼距離遠點、稍微有些變形或方向沒有對正都可能造成識別失敗。一種典型的使用場景是：簽到發起者把小程序碼投影到大屏幕上，由于投影儀的分辨率和電腦不一致，圖片可能產生變形。這種情況下，簽到者怎么掃都無法識別。 而以上所有這些，對于方形的二維碼，全都不是問題。

由于小程序碼的實現和識別原理沒有開放，我們也沒法采取圖片糾錯、還原等措施改善識別效果。

魚和熊掌，真的很難兼得。

關于轉發，在官方文檔里是這么寫的。

于是，在實現中，我們定義了此方法，把方法體留空。然后紕漏出現了，當用戶簽到之后再分享，收到的人一點擊分享的鏈接會進入簽到狀態。

查了很久，才發現原因是在分享的時候，把當前頁面加載時候的參數也給分享過去了，可是，onShareAppMessage函數里面什么都沒做啊。

看來，什么都不做的話，它就會默認分享頁面加載時的參數。為了修復這個bug，就嘗試return一個object，并給這個object賦值path和title兩個參數。

終于解決了。

除了上面提到的之外，還有不少微小的bug，不一而足。雖然很快就解決了，相對開發源生代碼而言，還是有些影響開發效率的。

過去的這一個月，有些累。 

相對之前鋪天蓋地的小程序宣傳，其實它沒我們想象中的那么好。當然，不得不承認，微信平臺的龐大用戶量和小程序無需下載的便利性，這是國內其他任何平臺無法做到的。

對于 掃碼簽到工具 這種輕量級的應用，開發微信小程序或許是比較好的選擇。

至于復雜的應用，是否要開發小程序版本，可能就得慎重了。