前文 說到我開發了一個簡單的小程序叫做 車標速查（代碼以及二維碼詳見 這里），本文簡單講講如何將這個小程序轉為 mpvue 開發（最終 成果 ）

mpvue 官網的 文檔 真的是非常簡單，不，應該說是簡潔，因為依托 Vue，所以很多語法不需要贅述，直接去看 Vue 的文檔就好了。mpvue 這個名字真的是不忍吐槽，起名也太不上心了吧 ... 反正我個人覺得不好聽

mpvue 的入門非常簡單，可以看這個 quickstart。生成的模版目錄結構和 Vue 開發很像，但是有區別，為了使之構建出符合小程序項目結構的代碼格式： json/wxml/wxss/js 文件。src 是開發目錄，dist 是最后 build 的目錄，也就是小程序的代碼

簡單看一下 src 的代碼結構：

復制代碼├── App.vue
├── data
│   └── data.js
├── main.js
├── pages
│   ├── about
│   │   ├── index.vue
│   │   └── main.js
│   ├── detail
│   │   ├── index.vue
│   │   └── main.js
│   └── index
│       ├── index.vue
│       └── main.js
└── utils
    └── index.js

App.vue 最后會被編譯成 app.js/app.wxss，一些全局相關的樣式和鉤子函數會被放在這里（比如說 onLaunch，但是在 mpvue 里我們可以用 created 代替）。main.js 會被編譯成 app.json，一些全局相關的配置放在這里（比如頁面入口，tabbars 等）

pages 目錄即為每個頁面，以 index 目錄為例，index.vue 會被編譯成 main.js/main.wxml/main.wxss，而 main.js 可以放置針對單個頁面的配置，最后會被編譯成 main.json（如果沒有填入配置項，則不會生成該文件）

然后來簡單過下開發過程中踩的一些坑：

• pages 目錄下新增入口，需要重新 npm start 啟動，因為新建了 webpack 的 entry
• 關于 navigator。index 頁面點擊圖標需要去詳情頁，這就有了導航需求。小程序有原生的 navigator 組件，現在用 mpvue 開發，那么能不能用 Vue-Router 呢？答案是并不可以，參考 這個 faq。所以最后還是用了小程序原生的 navigator 組件
• detail 頁面的 onLoad 鉤子會有一個 options 參數，如果在這個頁面用 created，是獲取不到的，可以看下 mpvue 的 生命周期。因為 mpvue 不建議使用小程序的生命周期鉤子，所以比較好的方式是在 mounted 的時候用 this.$root.$mp.query 去獲取 options
• .vue 文件需要加上 style／script 標簽后才能被正確編譯，這點不難理解，script 里的內容被編譯成 js 文件，而 style 里的內容被編譯成 wxss 文件，一個小程序的頁面需要它們支撐
• filters 還是不能用
• 關于富文本。看了下 v-html 指令是可以用的，但是是被編譯成 rich-text 組件，并不符合我的要求，最后用的是 mpvue-wxParse，還是不錯的，跟 wxParse 功能基本一樣
• 關于 scroll-view。因為有個側邊導航點擊跳轉的功能，還是用了 scroll-view 去實現，并沒有更好的辦法
• {{}} 中小程序原生不支持的語法，mpvue 同樣無法支持，比如一些復雜的計算，比如函數等
• 所有頁面里面的 created 生命周期函數都會在小程序加載的時候， 一次性執行，而不是每進入一個頁面執行一次（可以用 mounted 或者 onLoad 或者 onReady 代替）

總的來說，我從入門 mpvue 到用其改寫這個小程序，也就不過一天時間，由此可見 mpvue 上手真的非常快，但是它給我的總體感覺是有點雞肋，一方面可能是我這個項目有點簡單（不需要用到 Vuex 以及組件化），另一方面可能還不是很了解 mpvue

官網概括的它的主要能力：

• 徹底的組件化開發能力：提高代碼復用性
• 完整的 Vue.js 開發體驗
• 方便的 Vuex 數據管理方案：方便構建復雜應用
• 快捷的 webpack 構建機制：自定義構建策略、開發階段 hotReload
• 支持使用 npm 外部依賴
• 使用 Vue.js 命令行工具 vue-cli 快速初始化項目
• H5 代碼轉換編譯成小程序目標代碼的能力

我覺得目前主要的亮點在于 Vuex 的可引入以及組件化開發，但是越來越覺得隨著原生小程序開發的改善，這些功能都會被補充進去。所以，最大的賣點可能還是在于 多端統一

我覺得有點雞肋的另一個重要原因是，使用 mpvue 開發并不能完全忽略小程序的 API 或者組件，比如這個小程序，還是要用 navigator 組件以及 scroll-view 組件去實現一些功能（當然隨著 mpvue 生態的發展，完全有可能出現 navigator／scroll-view 的 mpvue 組件，但是這樣造輪子是否值得？），而且可能還有其他一些 API。而類比 jQuery 和 js，jQuery 完全不用去考慮原生的 dom 操作方式，從而更加 “傻瓜式”。mpvue 的開發模式注定不會是這樣的結局（因為并不是從小程序底層去開發）

另外一點，用 mpvue 開發，增加了一層 vue->小程序 編譯環節，所以 reload 的速度應該會比原生開發慢一點

魯小夫 在 如何看待美團開源的 mpvue ? 這個問題下的答案非常值得思考：

不過我們也該思考一下，為什么大家對微信小程序自帶的機制有這么多意見，為什么大家對 vue 這么認同，為什么多端兼容這個事情這么重要，為什么微信小程序沒有擁抱開源，為什么微信小程序的技術棧沒能做到標準化通用化。為了兼容微信小程序，前端工程師做了這么多工作，弄了那么多框架，到底得到的是什么。

以前看到過一句話，大概意思是，微信小程序有太多滿分的開源框架可以借鑒，最后卻造了個負分的輪子。

all in all，我的看法是，如果你剛好熟悉 Vue 或者需要多端統一開發，那么 mpvue 或許是個選擇，如果你只是從頭開始開發一個小程序，原生開發也未嘗不可。說到底，一系列小程序框架的出現無非是原生開發體驗太差，但是我相信，以微信的能力，假以時日能夠把小程序原生開發的體驗做好。