本週擼了兩款小程式，在這裡總結下開發過程中的小經驗，希望對大家有用。

小程式端

我們先說小程式要注意的地方。

##預設入口轉發問題

當一個小程式Page的js檔案中存在 onShareAppMessage 方法時，可以觸發轉發功能，但是通過小程式開發者工具生成的模板中，入口檔案的js中並沒有此方法，為了釋出後方便對小程式進行分享，建議在pages/index/index.js中新增。

當然預設情況下，我們需要點選小程式右上角的…才能看到轉發，這樣並不能對使用者起到引導作用，通常的做法是使用一個button，並且設定open-type為share，這樣就可以通過按鈕啟動分享。

但是原生按鈕很難看，我們可以設定一個圖片，在wxml內的程式碼一般如下

<button open-type="share"><image src="/images/icon-share.png"></image></button>

當然需要通過wxss將button的樣式去掉，背景、邊框等等，程式碼如下

button {
    padding:0;
    margin:0 auto;
    width:70rpx;
    height:70rpx;
    display:block;
    border:0;
    background: transparent;
}
button::after {
    border
 
:0; 
}

尤其是對 button::after 要進行設定，否則按鈕的邊框是無法去掉的。

關於登入

關於小程式登入邏輯都差不多，從小程式發一個請求（含code）給伺服器程式碼，伺服器通過code換取open_id和session_key，其中open_id我們需要儲存，用來表示使用者身份，session_key用來獲取使用者基本資訊時解密使用。

當伺服器端進行了儲存後要生成一個key，將其返給小程式，以後小程式凡是發起需要使用者認證的請求，都帶這個key用來判斷使用者身份，在yii2中，這個key就是我們restful中的access_token。

以上是關於小程式登入的前後臺邏輯，如果你使用yii2類框架，很多都內建了，並不複雜。

但是這裡還有幾個問題

1. 小程式端何時進行登入邏輯？
2. 發起請求時access_token過期瞭如何處理？

小程式端何時進行登入邏輯？

在登入判斷上，我們先進行小程式是否含有access_token來判斷，當然即便存在，還需要對checkSession進行一次判斷。

var session = Session.get();// 獲取access_token
if (session) {
    wx.checkSession({
        success: function () {
            
        },
        fail: function () {
            
            doLogin();
        },
    });
} else {
    doLogin();
}

這裡Session是對access_token的一次封裝。

發起請求時access_token過期瞭如何處理？

這個問題最常發生的場景就是我們傳送了一次需要使用者認證的請求，此刻如果伺服器端發現收到的access_token已經失效，會返回異常，此刻小程式一般要如何處理那？

我的推薦方式是靜默狀態的自動登入一次再，先看程式碼。

if (response.statusCode === 401) {
    Session.clear();
    if (!hasRetried) {
        hasRetried = true;
        doRequestWithLogin();// 
        return;
    }
}

我來解釋一下這段程式碼，當小程式發起一次需要使用者認證的請求但是被伺服器駁回為401錯誤（一般為使用者認證失敗），此刻我先清理掉小程式端自身對access_token（Session.clear()方法實現），然後在進行登入後再發起請求（doRequestWithLogin()）。

但是我們不能一直在執行請求失敗就登入操作，因此可以設定一個開關hasRetried，只進行一次嘗試。

客服訊息

在小程式開發中，客服訊息的重要性不言而喻，它除了作為客服服務外，還作為小程式到微信瀏覽器的一個渠道，比如本次在「寶寶愛識圖」的開發中，我用它來實現將收款微訊號到使用者的推送工作，這主要是解決在ios端虛擬產品不能進行微信支付事情。

一般的策略是讓客戶點選客服按鈕然後輸入一個關鍵詞，伺服器端通過客服訊息介面識別使用者身份，結合關鍵詞給予響應的訊息推送。

模板訊息

很多人認為很雞肋的方法，畢竟需要獲取form_id和prepay_id後才能下發模板訊息，似乎很受限制，但是我們可以建立一個formId的種子表，將盡可能多的使用者和後臺的行為都採用form表單提交的形式，並且獲取formID，對，要變態的多，這樣你的formId表資料起來了，以後想發訊息的時候用就好了。

關於如何設定能獲取formId的小程式表單也很簡單，設定report-submit為真即可，如下程式碼

<form bindsubmit="abc" report-submit="{{true}}">
    
</form>

然後在js端通過如下程式碼獲取

abc(event) {
    var formId = event.detail.formId;
    xxx
},

儘可能多的。

伺服器端

接下來總結下伺服器端，我使用yii2的restful元件作為介面支援，關於restful的基本功能請參考yii2官方文件或我之前錄製的課程《Yii2的RESTful講解》，在這裡分享我認為關鍵的點。

讓yii2能解析json的請求內容

預設情況下yii2並不能識別請求中的json格式，而我們小程式在發起請求時喜歡用它，因此我們要對yii2進行一下配置。

config/web.php

'request' => [
    'cookieValidationKey' => 'xxx',
    'parsers' => [
        'application/json' => 'yii\web\JsonParser',
    ],
],

對，在web.php中對元件request增加內容解析yii\web\JsonParser。

使用者認證

小程式的登入需要服務端的使用者認證配合，當然我使用yii2框架，內建的restful已經支援了，如果你的系統不支援使用者認證，可以自行建立access_token的生成機制，具體可以參考騰訊開放的小程式服務端框架wafer。

在yii2的restful中的使用者認證使用了行為機制，我們來看下流程程式碼

// 在需要授權的控制器內
class CardController extends ActiveController {
    public $modelClass = 'app\modules\say\models\Card';
    
    public function behaviors() {

        $behaviors = parent::behaviors();
        $behaviors['authenticator'] = [
            'class'=>HttpBearerAuth::className(),
            'only'=>[
                'index'
            ],
        ];

        return $behaviors;
    }
    
    ...
}

就如上面的程式碼，我們生命index動作是需要使用者認證的，並且認證機制為HttpBearerAuth型別，在小程式端需要在header內包含如下程式碼

header: {
	'Authorization': 'Bearer ' + access_token
},

當伺服器驗證通過後，在action的程式碼內直接使用 Yii::$app->user->id 就可以獲得使用者ID。

ok~

這就是前幾天小程式開發過程中給大家分析的點，後續升級過程中會繼續分享給大家。