微信小程序推出以后，我在公司內(nèi)部開(kāi)過(guò)幾場(chǎng)小程序開(kāi)發(fā)培訓(xùn)課。出于培訓(xùn)課程需要，以公眾號(hào)“贊賞”功能作為需求，制作出一個(gè)“贊賞”小程序DEMO。

本案例涵蓋前后端完整設(shè)計(jì)與代碼講解，其中包括2個(gè)小程序前端頁(yè)面，3個(gè)后端JSON接口，涉及到的相關(guān)知識(shí)要點(diǎn)包括了登錄、后端信息獲取（AES-128-CBC解密算法）、微信支付、后端數(shù)據(jù)存儲(chǔ)等，是個(gè)完整的麻雀案例。

案例借助開(kāi)源NAMI框架（ https://github.com/wodenwang/nami ），十分鐘即可完成前后端本地部署。

案例效果一覽：

小程序登錄

微信公眾平臺(tái)（包括公眾號(hào)、小程序）相比APP的一個(gè)明顯優(yōu)勢(shì)，是開(kāi)發(fā)者可以直接利用微信的用戶鑒權(quán)體系，免去注冊(cè)、密碼登錄的步驟。微信小程序?qū)τ诘卿浀脑O(shè)計(jì)，更是用之于無(wú)形，在整個(gè)用戶使用過(guò)程中都是無(wú)感知的，一進(jìn)小程序其實(shí)就已經(jīng)登錄了。

也許有讀者會(huì)說(shuō)，小程序登錄的時(shí)候不是會(huì)彈出一個(gè)用戶信息的詢問(wèn)框嗎？錯(cuò)了，這個(gè)詢問(wèn)框是調(diào)用wx.getUserInfo獲取“用戶資料”時(shí)候彈出的，調(diào)用wx.login的“登錄”操作是不會(huì)彈出任何詢問(wèn)框的。

關(guān)于微信小程序登錄，官方文檔的流程實(shí)現(xiàn)起來(lái)挺不容易的（如下圖），需要服務(wù)端維護(hù)一個(gè)保存OpenID等用戶資料的緩存池，同時(shí)小程序客戶端還需要維護(hù)一個(gè)3rd session key，并且在之后每次做服務(wù)端請(qǐng)求的時(shí)候都要帶入這個(gè)3rd session key。

所幸NAMI框架已經(jīng)把這塊封裝好，下面我們用一點(diǎn)篇幅來(lái)看看案例是如何做Login。

(1) app.js

import nami from '/nami/index';

App({
  data: {
    userInfo: null,
    rankLoaded: false //排行榜已加載
  },

  onLaunch: function () {
    var app = this;
    //登錄
    nami.login(() => {
      nami.getUserInfo((userInfo) => {
        console.log("已獲取數(shù)據(jù)", userInfo);
        app.data.userInfo = userInfo;
      }, () => {
        console.log("用戶拒絕提供信息");
      });
    });
  }
})

案例在小程序入口的時(shí)候?qū)崿F(xiàn)nami封裝的登錄，登錄成功之后可以看到localstorage中保存了一個(gè)叫做NAMI_TOKEN的字符，這個(gè)就是小程序登錄之后要求前端保存的3rd session key了。

(2) rank.js

/**
     *下拉刷新
     */
    onPullDownRefresh: function () {
        wx.stopPullDownRefresh();
        var that = this;
        //這里使用了nami封裝的request而不是wx.request
        nami.request({
            loading: true,
            url: '/request/scholes_pay/rank.groovy',
            success: function (res) {
                that.setData({
                    dataList: res.data.list
                });
                app.data.rankLoaded = true;//加載完成
            }
        });
    },

截取一個(gè)服務(wù)端請(qǐng)求的代碼片段做分析，發(fā)現(xiàn)NAMI框架將request也做了封裝，其主要目的是在每次服務(wù)端請(qǐng)求的時(shí)候?qū)ocalstorage中的NAMI_TOKEN帶入，如圖。

（3）服務(wù)端代碼：rank.groovy

/**
 * 排行榜
 * @author woden
 */

//重點(diǎn)是這一句獲取已登錄的用戶信息
//NAMI框架中通過(guò)nami_token在服務(wù)端緩存池找到對(duì)應(yīng)的用戶資料，并返回給邏輯代碼
//這里的session指的是NAMI框架中封裝的會(huì)話上下文
def user = session.appUser();

//根據(jù)被贊賞金額排名的用戶列表
def list = db.query("""
select b.*,a.TOTAL_FEE from
(
    select sum(TOTAL_FEE) TOTAL_FEE,OPEN_ID from PAY_DETAIL group by OPEN_ID
) a 
left join PAY_USER b on a.OPEN_ID = b.OPEN_ID
order by a.TOTAL_FEE desc,b.UPDATE_TIME asc 
limit 10
""".toString());

def result = [];
def i=1;
for(def o:list){
    def vo = [:];
    vo.avatar = o.AVATAR_URL;
    vo.nickName = o.NICK_NAME;
    vo.fee = fmt.formatPrice(o.TOTAL_FEE/100);
    if(user.openId == o.OPEN_ID){
        vo.my = true;
    }
    vo.rank = i++;
    result += vo;
}

return [list:result];

從這個(gè)案例看出，NAMI框架遵循規(guī)范推薦的技術(shù)原則，將緩存池、3rd key等業(yè)務(wù)無(wú)關(guān)的技術(shù)細(xì)節(jié)封裝在框架中，讓開(kāi)發(fā)人員可以更專注于業(yè)務(wù)邏輯本身。

小程序支付

小程序推出之初，許多開(kāi)發(fā)人員對(duì)于小程序支付的實(shí)現(xiàn)也是焦頭爛額，官方給出的時(shí)序圖如下，讀者可以自己感受一下。

微信小程序的支付對(duì)于前端的接口倒是簡(jiǎn)單，只需事先一個(gè)wx.requestPayment接口，至于API里面指定的參數(shù)，填空就是了。先看看案例中前端支付是怎么寫的。

（1）index.js

/**
   * 綁定選中贊賞金額按鈕
   */
  selectItem: function (event) {
    //獲取待支付金額，單位：元
    var total = event.currentTarget.dataset.item;
    var that = this;
    that.setData({ selected: total });

    //向服務(wù)端發(fā)起支付請(qǐng)求，獲取wx.requestPayment需要的信息
    nami.request({
      loading: true,
      url: '/request/scholes_pay/pay.groovy',
      data: {
        total: total * 100 //元轉(zhuǎn)為分
      },
      success: function (res) {
        console.log("獲取支付密匙", res);

        //發(fā)起支付，根據(jù)服務(wù)端的返回填空
        wx.requestPayment({
          timeStamp: '' + res.data.signature.timestamp,
          nonceStr: res.data.signature.nonce,
          package: res.data.signature.pack,
          signType: 'MD5',
          paySign: res.data.signature.signature,
          success: function (res) {
            app.data.rankLoaded = false;//通知排行榜重新加載
            wx.showToast({
              title: '支付成功,感謝',
              icon: 'success'
            });
          },
          fail: function (res) {
            wx.showToast({
              title: '已取消支付',
              icon: 'success'
            });
          },
          complete: function () {
            that.setData({ selected: 0 });//取消選中
          }
        });

      },
      fail: function (res) {
        //do anything
      }
    });
  }

上面的代碼看出，調(diào)用wx.requestPayment之前需先請(qǐng)求服務(wù)端下單，并返回對(duì)應(yīng)的支付密匙信息。好，接下來(lái)我們看看服務(wù)端下單的邏輯怎么寫。

（2）服務(wù)端代碼：pay.groovy

/**
 * 下單支付
 * 
 * @author woden
 *
 */

//獲取當(dāng)前用戶
def user = session.appUser();
log.debug("user:{}",user);
if(!user?.nickName){
    nami.error("用戶拒絕提供資料,無(wú)法支付.");
}

//更新用戶信息
if(db.find("select OPEN_ID from PAY_USER where OPEN_ID=?",user.openId)){//找得到則更新
    db.exec("update PAY_USER set NICK_NAME=?,AVATAR_URL=?,UPDATE_TIME=? where OPEN_ID=?"
            ,user.nickName
            ,user.avatarUrl
            ,now
            ,user.openId
            );
}else{//否則新增
    db.exec("insert into PAY_USER (OPEN_ID,NICK_NAME,AVATAR_URL,UPDATE_TIME) values (?,?,?,?)"
            ,user.openId
            ,user.nickName
            ,user.avatarUrl
            ,now
            );
}

//支付下單
//調(diào)用NAMI框架的app.pay.order接口(封裝了微信支付下單)，直接獲取訂單order對(duì)象
def total = request.getInteger("total");
def order =app.pay.order([
    openId : user.openId,
    total : total,
    body : '多謝贊賞',
    notify : nami.invoke('host.groovy')+'/request/scholes_pay/pay_callback.groovy' //回調(diào)
]);

//向客戶端生成支付加密串
//調(diào)用NAMI框架的app.pay.signatur接口(根據(jù)prepayId換取支付密匙)
return [tradeNumber:order.tradeNumber,signature:app.pay.signature(order.prepayId)];

這里NAMI有兩個(gè)接口，分別是：

• app.pay.order ：統(tǒng)一下單；
• app.pay.signatur ：簽名算法。

NAMI框架已將接口調(diào)用、基于支付安全考慮的簽名加密算法都封裝好，讓開(kāi)發(fā)人員關(guān)注業(yè)務(wù)邏輯本身而非這些技術(shù)細(xì)節(jié)，這在實(shí)際項(xiàng)目開(kāi)發(fā)的時(shí)候可以大大提升效率。

踩坑

即使開(kāi)發(fā)這么小的案例，數(shù)數(shù)也踩了不少坑，除了像兼容性問(wèn)題、工具BUG、各種組件BUG這種已經(jīng)讓開(kāi)發(fā)者們“習(xí)以為常”的坑以外，我重點(diǎn)列幾個(gè)被官方升級(jí)“升”出來(lái)的坑。

• 獲取用戶資料的確認(rèn)框被“拒絕”后不再?gòu)棾?，?dǎo)致獲取不到用戶資料。 調(diào)用wx.getUserInfo彈出詢問(wèn)框，假如點(diǎn)了“拒絕”之后，再次調(diào)用wx.getUserInfo不再?gòu)棾觯文憬Y(jié)束進(jìn)程、清理緩存都沒(méi)有，硬是要等大概十多分鐘后，才會(huì)再次彈出詢問(wèn)框。這時(shí)候可別再點(diǎn)錯(cuò)了，否則又得等十多分鐘。 
  這是小程序某個(gè)版本升級(jí)“升”出來(lái)的。在此之前我看過(guò)有些產(chǎn)品喜歡把wx.getUserInfo設(shè)計(jì)成用戶主動(dòng)點(diǎn)擊按鈕去獲取的事件，例如設(shè)計(jì)一顆“登錄”按鈕，用戶一點(diǎn)擊就調(diào)用wx.getUserInfo，用戶點(diǎn)擊“允許”就相當(dāng)于登錄了；這個(gè)“十多分鐘不彈出”的特性升級(jí)之后，以前這類主動(dòng)登錄的模式就得改改了。
• 內(nèi)置的Promise被廢除。 一開(kāi)始看到小程序支持ES6，支持Promise的時(shí)候非常高興，想著可以寫更優(yōu)雅的異步代碼塊了。誰(shuí)知道在某個(gè)版本升級(jí)之后，Promise就不被支持了，實(shí)在不知何故。雖然說(shuō)有一些例如es6-promise的第三方框架可以代替，但不是終歸總是不爽。
• 地理位置API，獲取不了當(dāng)前坐標(biāo)對(duì)應(yīng)的地名。
• 我一怒之下使用百度地圖API實(shí)現(xiàn)了，還是終歸不爽。

最后說(shuō)個(gè)血淚小教訓(xùn)，調(diào)試微信支付的時(shí)候千萬(wàn)千萬(wàn)不要用銀行卡或信用卡去測(cè)試，頻繁的支付1分錢1毛錢1塊錢，會(huì)導(dǎo)致卡被銀行封掉。

另外用內(nèi)置的DB console可以查看案例的運(yùn)營(yíng)數(shù)據(jù)，觀摩一下。讀者可以看出誰(shuí)贊賞了最多，最多又是多少錢嗎？

下載源碼：大家可以從 Github獲取“贊賞”案例源碼 。