小程式的功能不斷的增加，但是舊版本的微信客戶端並不支援新功能，所以在使用這些新能力的時候需要做相容。

關於單個 API 如何相容，微信官方提供了相容文件，因此我們這裡不再贅述。下面主要討論在整個專案如何優雅地處理相容問題。

問題

如果在每處需要相容的地方都寫上一堆相容相關的程式碼，隨著程式碼量增加，會出現以下問題：

• 程式碼難以閱讀
• 相容方案有變動時，需要改動多處
• 隨著時間推移，你的程式碼才是最需要並且是最難相容的

思考

最理想的情況是不需要任何相容處理，因此可以反推出相容性處理的程式碼並不是程式碼正常流程中的一部分，基於此：

• 相容的細節不必暴露
• 相容的方案應該統一
• 相容的方案可方便地變動

解決方案

1.將相容方案隱藏，對外提供介面即可

比如 wx.showLoading 是在 1.1.0 版本之後才提供的，對於之前的版本需要相容。我們選擇將其放在 show-loading.js 中，內部進行相容性相關處理，並對外提供 showLoading 方法。這樣呼叫者只需呼叫 showLoading 方法即可，不用考慮相容性的問題，而且如果相容的方式有變動，只需改動 show-loading.js 一處即可。

2.相容的處理還有共性可以抽象

相容處理多了之後我們會發現，對相容所做的處理無非兩方面：

• 支援該方法時，直接使用對應方法
• 不支援該方法時，做一些相容處理

因此這種模式我們又可以抽離出來，這樣做當然有一些好處：

• 減少重複程式碼
• 做一些共性的處理時，我們又只用改動一處（比如當不相容官方 API 時加上對應統計，用於分析當前應用跨版本的情況）

比如我們抽離出這樣一個簡單的 compatible.js 用於處理相容時的共性問題：

之前的 showLoading.js 我們可以這樣寫：

簡單吧 :)，這種寫法的意思是相容時正常展示 loading 即可，不相容時則不展示。

當然可能有完美主義者會覺得『怎麼能不展示呢？我就是要展示！』 那麼我們可以這樣寫：

用 wx.showToast 偽造了一個 showLoading。

3.檔案組織

相容性的檔案可能會越來越多，對於我這種有收拾的人，看到所有東西散亂地扔在一個抽屜裡肯定是不能忍的...因此我們可以多用幾個小盒子把它們分門別類地裝起來。小盒子怎麼選呢？其實官方已經給出了答案，官方 API 是按照不同的功用分組的，因此我們拿分組當『盒子』即可。最終的檔案組織像這樣：