PHP的困境

大概PHP開發人員都比較討厭這個說法，諸如此類的還有

PHP涼了嗎？
PHP窮途末路了？
Is PHP Dead？
學PHP不如學nodejs、go .....

知乎和不少技術社區都充斥這種話題，PHP的維護者大概會說

PHP沒問題，是phper的問題
你涼了，PHP也不會涼
世界上大多數網站都是PHP開發的
PHP入門快，開發快，中小型網站首選
性能不足？你大概沒聽過swoole吧

除了惡意抹黑的，惡意誇讚的，帶有利益關聯的，還有更多的是其餘的語言社區的調侃：

PHP是世界上最好的語言

任何編程語言都有多面性，都有本身的獨特優點，就像PHP二十多年，即使和現代語言相比有許多不足，但依然能誕生了許多優秀的軟件，情人眼裏出西施，許多phper珍惜她陪伴的日日夜夜，依舊深愛着這個「最好的語言」。

只是像上面同樣，針對PHP的弊端和將來持懷疑和悲觀見解的人越來越多，社區內人心思變亦愈發明顯，PHP如今無疑處在一個關鍵節點上，即使如今PHP的存量項目十分龐大，但趨勢一旦造成，若是沒有強有力的扭轉力量，到某個時間點就會一瀉千里，急速消亡，就像當初的Flash/ActionScript同樣，曾經多風光，現今誰記得！

好了，不作更多的情緒化吐槽，如下僅從我我的的經歷，分析概括PHP困境的表現和產生的緣由。

1、對PHP的認識

做爲一門腳本語言，PHP首要的是寫得快，寫的爽，不要有過多的心智負擔，若是須要性能或者特殊功能沒法實現，就用它的底層語言（C語言）實現，多數腳本都是這樣作的，像 C+Python、nodejs C/CPP+JavaScript、Nginx+Lua等等，熟悉遊戲開發的開發者應該很熟悉這個套路，不論是客戶端仍是服務端，一般底層搞個C/C++,常規業務配個Lua，兼顧性能和開發效率。PHP的不少函數效率極高，其實只是包裝的C函數而已。

上述模式在大多數場景效果很好，有性能、有效率，只要底層服務足夠多，即使不會使用底層語言C/C++，只用腳本自己也能知足大多數項目需求。

​2、PHP差了什麼

PHP在標準庫和擴展規範上一直沒有作到標準化、規範化，分散的函數庫和類庫，早起面向過程和後期面向對象的混雜，固然這有不少的歷史遺留問題，亦或者是保持兼容性，這方面不是我要表達的重點。重點是PHP在底層服務方面有致命的缺陷，尤爲隨着近年來開發模式的不斷髮展，互聯網用戶規模的擴大，node/go等方案的強勢崛起，這種缺陷愈發致命。

​PHP官方不提供基礎服務的實現

這裏說的網絡服務不是socket/stream的系統函數包裝，而是基礎的server，就像你用nodejs不用本身去實現個http服務器，go就更不用說了，多年來，PHP官方方案依舊是依賴於Apache/Nginx/PHP-FPM，PHP本身根本沒有獨立性，幾乎將PHP限制死在了簡單的web應用上。

其實也不用追求什麼異步、協程，像Java大多數應用的仍是跑在阻塞的api上，那又如何？不是照樣風生水起。PHP雖然沒有多線程，可linux多進程也沒差到哪兒去，再加上常駐內存，其實能夠有極大的性能提高和更廣闊的應用場景。

一直以來我都很難理解PHP官方爲何不作基礎server，尤爲是如今node/go/dart等，新生代的解決方案都會自帶一個標準實現，直到最近才稍有感悟：

​PHP官方對PHP的定位是什麼？

PHP is a popular general-purpose scripting language that is especially suited to web development.

​彷佛一直是這樣，從沒改變過，只不過十年前的web開發和如今的web開發早已天差地別，可是官方好像不是這樣想的，近年來，除了PHP5.4和PHP7有兩次大的內部性能的提高外，並無什麼有效的變革，我不能說這些沒什麼用，我只想說這個世界競爭激烈，開發者和語言沒有領結婚證，外面的小賤人多得是。

順便引伸一下PHP擴展開發，PHP官方好像沒有優化擴展開發體驗的計劃，那個Zend Api真是一言難盡，數次想用擴展開發的功能最後用了RPC

PHP對一些基礎功能極度依賴C語言的實現，若是底層沒有實現，幾乎是必需要引入第三個編程語言解決。

社區對PHP的期待是什麼？

從簡單的博客站點到現在的分佈式應用、微服務，社區對PHP在標準化、規範化、性能、適用場景一直有更高的期待，指望她能在原來的web上更進一步。爲此經過擴展、開發模式等各方面嘗試新的模式，reactphp/amp/php-pm/swoole/roadrunner/workerman等方案提供了基礎的網絡服務，pthreads/parallel/pth 提供了多線程的方案，swoole提供了協程的方案，PSR社區標準和Composer包管理器爲現代規範打下基礎，更有 jphp/peachpie/polarphp等新的解釋器的嘗試，能夠說phper一直在努力讓PHP更現代，走向更廣闊的空間，惋惜的是多數方案的質量根本難以和node/go等語言內置的方案競爭，因爲不是官方支持，或者支持平臺有限，測試不足，API不友好等緣由，在PHP社區內部也難以廣泛接受。

看了PHP的rfc，仍是在集中於語法、jit，官方彷佛曆來都不關注一些經常使用基礎設施。或許zend公司不求上進，php開發團隊定死了php的運行模式，亦或是我要求太多了吧。是啊，你對php作過什麼貢獻，你憑什麼要這要那~~

3、簡單說下swoole

最初使用swoole還在1.x，尚未websocket實現，仍是多進程/異步的模式，作過好多個項目，遊戲、IM、網關等等，有一些坑，還好要麼簡單調整下源碼或者規避掉也沒什麼大問題，也買過swoole的加密軟件，swoole前期一直在嘗試各類模式，後來固定到協程，也算是穩定了方向，總體仍是很讚揚swoole團隊的。只不過咱們後來逐步過渡了其餘模式，引入了其餘語言，就用的少了。

商業化也無可厚非，誰都不是喝西北風的。不過我建議swoole作一次大的減法，固定一種開發模式，只作核心的功能，能夠減輕開發壓力，提升軟件穩定性，也能夠適當減輕商業化的壓力。有時候這樣也行，那樣也行，還不如專一同樣。

還有即使商業化，也及不同意swoole去扶植任何一個框架，那是社區的事情，官方應該去作一些商業配套軟件，php和swoole已經十分上層了，稍有技術積累的團隊不會輕易採用那些框架。也建議社區不要作過多的框架，社區缺的是高質量的組件，例如搞一個完整的、獨立的、無依賴的、適合協程環境的數據庫組件，比那些有價值的多

4、吐槽一下技術輿論環境

惟大公司馬首是瞻，全部的技術都向bat看齊，大公司的技術沒什麼神祕的，並且不少大公司的技術方案跟業內所認爲的相差甚遠。越是咱們認爲人家會用的，其實根本沒有，或用的不多，java體系最爲突出

從BAT「出來」的同窗，不要胡亂傳播技術方案，人家100個項目，有3個用到了框架A，仍是魔改的，你就胡扯這個公司大面積使用框架A，趕忙上車吧，而後你有又搞不定~~

培訓企業，賣視頻、賣課程的常常編造一些技術方案、面試場景，並且還惡意攻擊類似技術，太沒底線

培訓的質量是一年不如一年了

5、結語

當前的技術方案百花齊放，競爭很是激烈，若是PHP不能提出有競爭力的方案，那它的歷史使命就快結束了，開發者都是喜新厭舊的，相愛的時候你儂我儂、纏綿悱惻，離開的時候頭也不回，始亂終棄。

祝 PHPer 2020年好運