摘要：小紅要以最低成本最快速度推出版本，投放市場，收集反饋，持續(xù)迭代?？偨Y(jié)在技能掌握充足的情況下，個人感覺開發(fā)效率要略高于。

我個人是比較不喜歡去正兒八經(jīng)的比較兩個框架的，這樣沒有意義，不過欲善其事先利其器！

技術(shù)是相通的，但是在某個特定的領(lǐng)域的某個階段肯定有相對最適合的一個工具！

這里比較不是從技術(shù)角度比較，而是從公司技術(shù)選型考慮的，特別是初創(chuàng)的互聯(lián)網(wǎng)創(chuàng)業(yè)公司。沒辦法，誰讓互聯(lián)網(wǎng)公司離不開軟件呢！哈哈哈。

首先是雙方選手出場介紹：

Laravel框架號稱是Web藝術(shù)家的框架，富有生產(chǎn)力，代表了最優(yōu)雅最流行的PHP框架，經(jīng)過一段時間的使用，也上了一個項目，感覺特點如下：

比較規(guī)范（PHP的框架中），適合團隊分工協(xié)作

開發(fā)速度快（社區(qū)生態(tài)和腳手架加持）

部署方便（PHP的部署就那樣吧，Git一套推拉下來就搞定了）

功能模塊比較全面

架構(gòu)較復(fù)雜（在PHP框架中，O(∩_∩)O哈哈~）

全棧，前后端一個IDE搞定

其他文中再說

Spring Boot準確來說并不是一個完整的框架，而是為了使 Spring 全家桶更方便使用、更親民而產(chǎn)生的一個整合框架。所以Spring Boot 的背后是 Spring 近乎無敵的生態(tài)和解決方案。
先簡單說一下特點吧：

背靠 Java 這個老家伙，還有 Spring 這個J2EE 的標準背書，生態(tài)非常強大

開發(fā)速度快（在Java系列中。。。），約定大于配置

基于JVM，執(zhí)行效率有保障

需要掌握Spring的那一套，對于本身不是 J2EE 的童鞋學(xué)習(xí)成本有點高

有Cloud 加持，微服務(wù)在召喚

智能到令人發(fā)指的Spring Data JPA

其他稍后文中再說

好啦，介紹完選手，就開始來分析一下該用哪個啦，這里我們設(shè)定一個情境：

假設(shè) 小紅 是一位有一個自認為價值 20億 的Idea，并且打算付諸實踐的小BOSS（即將成為），稍懂軟件架構(gòu)和開發(fā)技術(shù)，沒錯，是很菜的那種（如果很厲害那隨便怎么用框架了，沒所謂），且啟動資金只有 30萬。

我也不想假設(shè)的這么慘的，現(xiàn)實中這種情況很多，那我們就以這種情景展開分析。小紅要以最低成本、最快速度推出 1.0 版本，投放市場，收集反饋，持續(xù)迭代。這是一個系統(tǒng)工程，講其他因素剔除，只考慮技術(shù)問題，可以總結(jié)成以下幾點：

成本（開發(fā)效率和人工成本）

響應(yīng)（迭代和部署效率）

安全（穩(wěn)定性和 BUG解決速度）

協(xié)作（團隊協(xié)作和擴展性）

開發(fā)這個過程，我們將它定義為需求和原型都已經(jīng)確定，并且已經(jīng)簡單建模完畢，嗯，就是猿們到崗后拿著需求文檔打開電腦（Windows）的時候開始，到 1.0 版本發(fā)布這段時間，是誰跑得快！O(∩_∩)O哈哈~

首先是 Laravel 框架，步驟是這樣的：

配置本地環(huán)境：包括PHP-CLI、Vagrant 、VirtualBox、HomeStead Box、Composer、nodejs（Mix要用到）、Python、Virtual Studio、Node-gyp（Node-Sass要用到）、PHPStorm、Git，一切就緒后composer create-project laravel/laravel xxx

開發(fā)：定義migration、model，然后transformer和repository，再寫service和passport啥的，再寫controller，view視圖，然后完善 Event、Notification、推送啥的，期間伴隨著單元測試

部署：Git push、Git Clone 、Pull，env整一個，上線

對 Laravel 的開發(fā)流程熟悉的人呢，開發(fā)速度是很快的。

我們再來看看Spring Boot：

業(yè)務(wù)不復(fù)雜就不要折騰微服務(wù)啦，不要像某人一樣明明只有一臺機器，硬是要開幾十個端口，然后跑幾十個Spring Boot的小服務(wù)，還用Cloud全家桶串起來了。我竟無言以對

單體應(yīng)用擼起來，步驟如下：

配置開發(fā)環(huán)境：IntelliJ IDEA下一個、JDK裝一個、其他要用到的Redis啥的裝上，分分鐘就搞定可以開擼了。

開發(fā)：定義JAP Entity，Repository、Service，配置Spring Security（包括Oauth2），定義Validation，開擼Controller、異常處理，視圖層啥的，單元測試也少不了

部署：打出Jar包，扔到服務(wù)器上執(zhí)行吧，nginx映射一下，搞定

我個人覺得Spring Boot的開發(fā)效率要比 Laravel 框架高些！

為什么呢? 因為如果對 Spring 的機制熟悉，也了解 Security、JPA、Thymeleaf模板、RabbitMQ 等等功能模塊的使用，Spring Boot 的封裝是比 Laravel 要好的，但前提是對Spring 那一套熟悉，不然從何入手都弄不清楚。

Spring 有些組件是非常復(fù)雜的，例如 Spring Security

Laravel 框架借鑒了很多 Java Spring 的思想，比如容器，依賴注入、切面，這方面明顯 Spring Boot 是正宗，注解啥的6得飛起！

Java 語言非常嚴謹，在開發(fā)過程中的體驗比較好，至少像我這樣天馬行空的猿，還非得要 Java 這個老頭來管著，不然分分鐘要跑偏。

回到開發(fā)效率這個問題上，如果對兩個框架都比較熟悉的情況下，Spring Boot 是開發(fā)比較快的，但 Laravel在某些方面是完勝Spring Boot，如下：

Laravel 框架的 ORM 構(gòu)建需要經(jīng)歷兩個步驟，migration 和 model ，而且改動 migration 需要調(diào)整 model，無法向 JPA 一樣Entity 即數(shù)據(jù)庫結(jié)構(gòu)；

Laravel 框架需要手動實現(xiàn)一些注入綁定，通常是$app->bind，盡管這不消耗多少時間，但是比起Spring強大的注解還是慢不少，而且主流IDE對 Spring 的 Bean 提供了導(dǎo)航查看功能，牛逼哄哄啊；

如果要做網(wǎng)頁渲染，Laravel的動態(tài)腳本語言特性加上Blade模板基本是秒殺Spring Boot 的；

要讓層次更分明一些的話，Laravel 需要手動實現(xiàn)Repository 模式，反正我是受不了Model 直接定義業(yè)務(wù)邏輯的，放在Controller里也受不了，不但難看，還不好擴展；

在授權(quán)這方面，Laravel 自帶的和Spring Security 都很強大，可以說是開箱即用，打平；

Laravel框架開發(fā)反饋調(diào)試方面是完勝Spring Boot的，這方面可以說所有非編譯型的語言都很爽！盡管Spring Boot 也有DevTool，但是架不住 PHP 根本就不需要重新啟動呀。

Laravel框架的代碼提示遠遠比不上Spring Boot，而且還需要第三方包Ide-Helper的加持，不然代碼追蹤都不行，可是就算用了第三方包還是看不了 容器內(nèi)長啥樣??；

像 Laravel 這樣靠面向?qū)ο篌w現(xiàn)優(yōu)雅的框架，卻遇到了PHP 這門面向?qū)ο蟛惶耆恼Z言，以致于在 Java 體系內(nèi)很容易實現(xiàn)的一個功能，到了PHP體系卻無能為力；

Route 路由這方面 Laravel 非常強大，而且直觀，比Spring Boot 靈活，所以定義路由的時候效率完爆Spring Boot；

異常處理兩者都非常方便，提供了統(tǒng)一處理的方式，難分伯仲；

Api Json數(shù)據(jù)定制這方面，Laravel 比 Spring Boot 要強大，這是因為PHP的數(shù)組操作非常靈活，對于 Java 來說需要定義工具類和實體類來專門處理；

i18n國際化，Laravel 比Spring Boot 方便；

前端資源處理，就這個功能本身來說，Laravel的Mix配合Blade模板完爆Spring Boot，但是話說回來，只要不是全棧，這不算什么優(yōu)勢。設(shè)想一下如果是前端做好頁面，拿到后端套模板，那Thymeleaf 完爆 Blade，因為Thymeleaf 可以保留預(yù)覽數(shù)據(jù)，渲染實際數(shù)據(jù)，Blade 做不到這一點。

總結(jié)：在技能掌握充足的情況下，個人感覺 Spring Boot 開發(fā)效率要略高于Laravel。個人掌握情況不一樣，請勿噴，可以參考文中的幾個維度，自己思考一下。

最后想提一下，順便求證：

Laravel 不念 “拉瓦” 
 Laravel 不念 “拉瓦”
 Laravel 不念 “拉瓦”

時候不早了，有點困。今天就寫到這，明天再寫人工成本的考量。

大家晚安！謝謝