前言
最近在網上查了一下php的最常用的三種框架tp，laravel，yii2的資料並結合自己的理解總結一下三種框架的優缺點，話不多說請看正文。
正文
-
yii2:
-
優點：gii蠻不錯的，簡化了開發流程，可以生成絕大數的代碼，開發後臺等效率還是蠻高的
-
缺點：前後端完全的分離的趨勢下，yii2前後端的耦合的還是有些重了
-
-
laravel:
-
優點：優雅，框架結構組織清晰（抽象了中間件，任務，服務等模塊），提供的artisan開發工具開發效率高，社區活躍完善，並且提供了簡化的輕量級框架lumen
-
缺點：貌似代碼有些過於優雅喪失了一些性能
-
-
lumen
-
優點：基本結構同Laravel，但是已經爲API開發做了一些優化，非常適合RESTful的API服務器缺點 -
缺點：如果要用Lumen做傳統web，需要自行加載一些Service，比如session；此外，有些爲Laravel寫的包會不太兼容Lumen，需要自行修改和調整
-
-
thinkphp3.2
-
優點：簡單明瞭方便快捷，上手快
-
缺點：缺少面向對象的設計，框架社區相關的輔助工具少
-
-
thinkphp5
-
優點：基本面向對象，可能借鑑了laravel或者ruby on rails, 對於開發者更加友善了
-
缺點：框架社區相關的輔助工具仍然少
-
爲什麼不選TP5.x
-
TP5.x明顯借鑑了很多Laravel的設計，但是感覺學得不倫不類的，就行中國特色的xxx一樣。而且TP5.x的查詢構建器很弱，用起來很不爽。還是Eloquent用起來舒服。（Doctrine的那種類似JavaBean的ORM也用過，但是還是沒有Eloquent這種ActiveModel式的好用。）
關於優化
關於其他語言
高併發場景下go語言顯然是一個很好的選擇，但是一定要結合實際看看項目組人員能力。
PHPer一般對js會比較熟悉，建議可以用node.js做一些高併發的服務。
當然workerman和swoole也是備選方案，但是workerman和swoole中，我覺得，最大的問題在於缺少node.js一樣完善的錯誤處理機制。
-
路由：
-
Laravel默認的路由機制比較適合SEO，但是對於只用作API的服務器來說開銷就有點高了。
-
相對而言TP/Yii默認的
module/controller/action的匹配方式效率比較高。 -
建議API的路由使用傳統的
module/controller/action的方式來匹配。可以參考： laravel-default-routes 或 lumen-default-routes.
-
-
環境配置（.env文件）：
-
Laravel的這種機制很不錯，可以很方便的區分開發/測試/生產環境。
-
但是.env文件畢竟還是一個純文本文件，無法享受到 opcache 的加速，所以在實際項目中，我們使用了 .env.php 來代替。
-
-
渲染HTML（視圖模版）:
-
Laravel 默認用的 blade 很贊。
-
TP 用的基於 taglib 的視圖模版實在不敢恭維，而且奇葩的是模版的花括號之間居然不能放空格，所有東西都擠在一起...
-
當然有興趣的話用smarty模版就大善了
-
如果要效率最高，鐵定使用原生PHP做模版最佳，但是轉義輸出都帶自己寫，一不留神容易有xss漏洞
-