php 有没有过气不好讲，但是整个 php 社区发展在我看来确实有停滞的趋势了。

框架层面，全球市场 laravel 一家独大，整个 php 开源生态与其说是 php 生态，不如说是 laravel 生态，国内的话 laravel/thinkphp/hyperf/webman 倒是分庭抗礼，我也几乎都试过，但是用下来体验最好的还是 laravel ，选 laravel 的一般很少选 tp 了，hyperf 体验次之，但是 hyperf 也有自己的问题，比如对 IDE 不够友好，有时候报错会报道 xxxx.proxy.php 上，不太方便调试。以前 php 圈子活跃的时候，有很多框架如雨后春笋般冒出来，很多有特色的框架会给人眼前一亮的感觉，然而最近再去翻那些框架的 repo ，要么 archive 了，要么就几乎不维护了。

常驻进程/协程/异步方案上，国内外分化地比较明显，国内偏好 swoole/workerman 方案，国外更偏好基于 fibers 的 reactphp ，swoole 另辟蹊径使用 hook 方案，整个异步/协程的体验比较丝滑。当年 fibers 提案时被寄予厚望，整个 php 圈子希望由此统一并繁荣 php 的协程/异步 IO 生态，不过这么多年过去了，看起来事与愿违。而 swoole 作为一个第三方扩展，库作者开发库时，也不太会考虑为其专门做适配。phper 只能等待官方再一次重视协程/异步支持，不知道这一次又要等到猴年马月去了。

php 本身也有一些问题亟待解决：

php-fpm 是一个很大的问题，当一个公司很小的时候，fpm 确实很奏效，解决（隐藏）了很多问题，但是一旦业务规模上升到一定程度，他就成了累赘，每一个请求都要重新走一遍初始化框架的流程，这带来了很多不必要的性能开销。php 作为一个脚本语言，其实性能并不弱的，fpm 就像一个枷锁，阻碍了 php 的性能释放，这也成为大公司抛弃 php 的一个很重要的原因。当然你说我们有 reactphp/workerman/swoole 常驻进程方案，但同样的道理，没有官方对 cli 下 server 的支持，各个小群体各自为战，劲使不到一处，又能翻多大的水花。

类型问题：1. php 成也 array ，败也 array 这句话不是没有缘由的，关联数组太好用了，无论做什么，第一时间想到的就是用 array 来装，而整个组里只要有一个人，关联数组到处乱飞，就能极大地降低项目的可读性和可维护性，所以在我的项目里，只允许方法内使用关联数组，一个关联数组不能传到方法外面，如果要，就请转成对象，即便如此，你也只能约束自己，无法约束第三方的 SDK 或者开源库，很难完全阻止关联数组的泛滥。2. 缺少泛型支持，当然弱类型语言对泛型的支持并不那么迫切，但一个 php 项目做的越深，就越觉得应该要有泛型，当然有 phpdoc 帮助我们声明泛型从而获得 IDE 的支持，但是写代码还要写 phpdoc 让整个开发的体验很割裂，体验下降了一大截。

其他的高级开发用到的什么多进程/线程/协程/锁/定时器乱七八糟的就不说了，而且周边生态上没有官方的语言服务器实现使得开发者只能依赖收费插件/phpstorm 才能获得良好的开发体验，环境搭建复杂，使得语言上手的成本较高（似乎是有一些社区方案，不过都只能开发使用，并不是生产级的）。

php 规划的问题：此处看法比较主观，我觉得目前 php 圈子缺乏一个有足够权威的大佬领导规划 php 的开发，能有魄力和实力带领 php 走出目前的困境，据我所知 php 基金会目前全职加上兼职总共有 10 名开发者，swoole 也有不少开发者在 php 开发组，开发力量不算弱，但近年来 php 的更新并没有给人带来惊喜。