關于單個 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 是按照不同的功用分組的，因此我們拿分組當『盒子』即可。
最終的文件組織像這樣：