這篇文章主要是總結雲開發中踩的坑，優化了往期項目中的一些做法。

順便總結一下私信/郵件中比較高頻的問題。

文章目錄

一、做法優化總結

二、新功能的實現

三、高頻問題的總結

四、雲開發中的踩坑

最後

一、做法優化總結

1.帖子的獲取方式

一個帖子，獲取的時候分爲兩個部分，如下圖所示：
原方法：第一部分是帖子本身的信息，第二部分是關於作者的信息。之前在往期的項目中，採取的是拼接的方法，即獲取帖子item[]，再獲取作者useritem[]，這樣相當於獲取兩回而且還多了一個集合。

/*原方法截取*/

              that.data.UsernameArry = [];
              that.data.UserHeadurlArry=[];
              for (let i = 0; i < this.data.DataPostArry.length;i++){
                let openId = this.data.DataPostArry[i]._openid;
                for(let j=0;j<res.data.length;j++){
                  if(openId == res.data[j]._openid){
                 that.data.UsernameArry.push(res.data[j].Username);
				that.data.UserHeadurlArry.push(res.data[j].User_head_url);
              }
              that.setData({
                UsernameArry: that.data.UsernameArry,
                UserHeadurlArry: that.data.UserHeadurlArry
              });

優化方法：採用雲開發Aggregate進行聚合操作¹，聯表查詢，做外連接，這樣可以直接在get的階段把作者和帖子的內容取到一個集合當中。

return db.collection('A表').aggregate()
    .lookup({
      from: 'B表',
      localField: 'A表關聯的字段',
      foreignField: 'B表關聯的字段',
      as: '匹配出的記錄列表要存放的字段名',
    }).match({
      '字段匹配': '字段匹配',
    }).end()

獲得的結果，B表的數據返回在了集合裏面：

2.點贊功能/收藏功能

往期點贊採取的方式是頁面中點贊，採用的是利用數組賦值0/1，點讚的時候判斷數組，點贊之後不能取消。需要優化的原因在於方法結構太過於死板，導致整段代碼十分冗餘而且不好操作。

/*原方法的節選*/
for (var i = 0; i < res.data.length; i++) {
 	UserUpId[i] = res.data[i].Up_Post_id//點贊列表賦值
 }
                for (var i = 0; i < res.data.length; i++) {
                  UserIdArry[i] = res.data[i]._id  //所有的用戶列表_id
                  if (UserUpId.indexOf(UserIdArry[i]) == -1) {
                    var item = 'UpArray[' + i + ']'
                    that.setData({
                      [item]: 0
                    })
                  }
                  else {
                    var item = 'UpArray[' + i + ']'
                    that.setData({
                      [item]: 1
                    })
				}

優化方法：創建一個新的數據表，專門用來存儲關於帖子的Status（狀態），點贊狀態的切換直接操作這個數據表即可。（點贊轉移到評論區-內-即進入帖子後再進行操作。收藏的功能實現亦是一樣的操作）。

3.navbar導航欄

原方法：導航欄做的時候，採取的方法是一次獲取，然後隱藏元素的方式，通過點擊判斷切換hide/show狀態。這樣寫的頁面太繁瑣了，就單個頁面顯得很雜，其實有些地方可以複用，就不需要再多寫一遍。

優化的方法：同類型的頁面進行復用，獲取數據的格式儘量相同。有些地方在前端可以利用block去操作。

二、新功能的實現

1.模糊搜索實現

這裏用到的是Aggregate聚合操作¹中的.match和.lookup。利用match匹配相關條件，lookup獲取帖子與作者的集合（即優化的獲取內容方式）。

return db.collection('帖子表').aggregate()
    .lookup({
      from: '用戶表',
      localField: '帖子表匹配的內容',
      foreignField: '用戶表匹配的內容',
      as: '返回數組名稱',
    }).match(//正則匹配，滿足兩個條件其一即可
      _.or([{
        '條件一': db.RegExp({
          regexp: '.*' + '搜索的內容',
          options: 'i',
        })
      },
      {
        '條件二': db.RegExp({
          regexp: '.*' + '搜索的內容',
          options: 'i',
        })
      }
      ])).end()

2.位置及功能的實現

小程序中有自帶的獲取當前位置函數²–wx.getLocation

用戶開放權限後，會獲取到經緯度，不過暫時沒有提供解析位置的服務，所以一般會採用第三方的工具進行解析。

這裏常用的就有騰訊/百度/高德，它們的官網都有比較完備的開發手冊，專門用於微信小程序的SDK。

這裏主要功能是實現地址的解析/關鍵詞輸入提示/路線規劃。

熱詞檢索的效果：

這裏我用的是百度的sdk–百度開發文檔，定位/描點/點擊標誌顏色，處理函數格式大同小異。

//地址解析
		Map.regeocoding({
		      fail: fail,
		      success: success,
		      //location: latitude+ ',' + longitude,//經緯
		      iconPath: '/icons/marked.png',
		      iconTapPath: '/icons/markedTap.png'
		    });
//熱詞聯想 
        Map.suggestion({ 
            query: '傳入熱詞', 
            region: '城市地區', 
            city_limit: 'true/false', //城市範圍限制
            fail: fail, 
            success: success 
        });
//POI檢索
		Map.search({
		      "query": "生活/酒店/交通/美食",
		      fail: fail,
		      success: success,
		      iconPath: '/icons/marked.png',
		      iconTapPath: '/icons/markedTap.png'
		    });

注意要做好權限的獲取：

 "permission": {
    "scope.userLocation": {
      "desc": "你的定位信息只用於天氣/周邊服務"
    }
  },

3.API調用實現

利用wx.request³發起 HTTPS 請求，每個不同的功能有不同的接口地址，有些需要設置請求頭什麼的。

按照提供api接口的制定的規則，發起請求，獲取返回數據，然後再進行處理。

實現小功能，類似快遞查詢/天氣查詢/笑話大全等等。

4.手機驗證的實現

這個功能跟地圖SDK接入的方法差不多，找到較穩定的短信驗證碼接口平臺，按照規範接入平臺SDK。

三、高頻問題的總結

1、返回數量有限？

這裏首先引入官方文檔中的解釋：

小程序端與雲函數端的表現會有如下差異：

小程序端：如果沒有指定 limit，則默認且最多取 20 條記錄。
雲函數端：如果沒有指定 limit，則默認且最多取 100 條記錄。

有比較多的朋友已經發現，前面項目獲取的數量有瓶頸，所以可以採取.skip()和 .limit()關鍵字，在雲函數中獲取的時候計算數量，超過的時候進行拼接再返回。

Collection.get()官方實例

2、取消授權之後再進來重疊了怎麼辦？

在授權頁面加入判斷，每個用戶有個獨立的openid。第一次用戶進入的時候，用戶的記錄已經記錄在你的用戶表中，取消授權它的記錄仍然會在庫內。

3、用什麼框架好啊/怎麼做小程序？

各有千秋，滿足業務需求就好。如果只是做個小工具什麼的，其實原生也夠用的，也不一定說非要上什麼框架合適。主要是多思考別人實現的方式，關注功能背後邏輯是怎麼實現的。如果讓自己去實現，能不能實現/爲什麼利用這種方式實現。

重點不在於代碼，在於思想。

四、雲開發中的踩坑

一定要記住，小程序端數據庫操作權限限制>>雲函數。

1.數據庫操作失敗/受限/不成功

首先，檢查雲數據庫的權限是否已經開放。

在雲開發數據庫下，有一個高級操作（模版）。

如果在小程序端操作數據庫，發現沒報錯/又沒效果（一般是更新），先放在模版中跑一跑。

能成功的，說明是在小程序端操作被限制，只能在雲函數端進行處理。

2.對雲數據庫中數組的更新

更新數組，有數組中有數組再有對象的更新

//數組.數組.下標.對應的字段
return db.collection(A表).doc(id).update({
    data: {
     	[`數組.數組裏面數組.${位置}.更新的字段`]: '內容'   },
  })

有數組中更新數組的

//數組.下標.對應的字段
return db.collection(A表).doc(id).update({
    data: {
     	[`數組.${位置}.更新的字段`]: '內容'   },
  })

還有更新純數組[“AA”,“BB”,“CC”]

return db.collection(A表).doc(id).update({
    data: {
      [`數組名字.${位置}`]: '內容'
    },
  })

基本上，如果理解其中一個就能實現以上。

3._openid的where條件查詢

一開始我利用_openid做查詢條件，用空的作爲條件，在小程序端能給我返回我自己數據，可是我在雲模版下查詢並沒有結果。

（只是單獨openid條件進行匹配）

後面才知道，在小程序端where會自帶openid爲小程序使用者openid的條件。

也就是說，即使你指定是其他人的openid，在利用openid條件進行匹配的時候，在小程序端也只會匹配返回使用者的openid的信息。

雲函數方面就沒有這條件，所以後來改用在雲函數中，用openid條件進行匹配再做返回。

最後

微信小程序正不斷的完善與發展中，越來越多的功能也在陸續更新。

後面我也會陸續發佈新的內容，希望我的文章能給大家帶來幫助。

文筆有限，若有遺漏錯誤之處，歡迎討論指出~

（文章在公衆號同步發出~往期項目的源碼可在公衆號內查詢）

數據庫集合的聚合操作–聚合操作 ↩︎ ↩︎
獲取經緯度 ↩︎
發起的wx.request請求–request請求 ↩︎

微信小程序雲開發的踩坑與填坑篇