自建新聞從無到有。當然，評論、點贊也是一步步來的。
關於點贊的設計，也是會挖過坑，也把坑給填了。
需求是這樣子的：點贊有【好球，警告】兩個選項，點了可以取消，取消之后可以再點，也可以直接從好球直接切換到警告，同時好球和警告數也要跟着更新
采用數據庫：mongodb，關於字段設計，一開始我是這樣子的：
support : Number , 用來記錄總的好球數
warning: Number 用來記錄總的警告
supportList: Array 用來存有點贊行為的用戶id,大概就是 [{uid:'12345',type:1},{uid:'123',type:2}]
---------------------------------------------------------------------------------------------------------
第一次點好球或者警告，support，warning就都是增1啦，而supportList的話，我就直接把用戶的id和點贊類型push到了數組，然后的然后就是坑來了：
現在是用戶要取消點贊，那是不是意味着我要到supportList遍歷對象並移除有關該用戶的鍵值對，如果是要更新的話，也是要遍歷后再更新保存，想到這樣子我就頭大了。。。。
然后，我就想到···· 既然用戶的id是唯一的，那這樣子的話，我不就可以把用戶的id作為鍵值對的鍵，然后行為作為值呢，然后字段也就變成了這樣子啦：
support : Number , 用來記錄總的好球數
warning: Number 用來記錄總的警告
supportDict Object 用來存用戶的點贊行為，形如{'5265':1,'5234':2},
用鍵值對來存用戶的點贊行為效率是比數組對象要高很多的【是不是！】
首先是點贊行為【1為好球，2為警告】如{'5265':1,'5234':2}就表示用戶5265點了好球，5234點了警告；
接下來就是取消行為【0為取消】，假設用戶5265取消點好球，就直接更新{'5265':0,'5234':2},用0來表示當前沒有行為，雖然可以移除5265這個字段，但不移除的話，我們就可以通過讀取該字段下的鍵，知道用戶曾經有點贊行為；
更新行為和取消行為類似，也是去更新字段的值；
其他需要修改的就是字段support、warining的值，如加1，減1；
-----------------------------------------------------
在查詢點贊行為時，客戶端會附帶uid的參數；此時只要在supportDict上查詢是否有該鍵，同時返回該鍵的操作行為即可，就不用像之前的設計還要去遍歷數組，效率一下子就提升了。
-----------------------------------------------------
我的理解就是這樣子啦。雖然我知道這篇文章會很少人看到，但是如果有人看到的話，可以和我分享下關於點贊更好的設計啦。