文档章节

PHP 霸主地位被动摇,JIT 是穷途末路后的绝地反击?

编辑部的故事
 编辑部的故事
发布于 01/09 19:23
字数 2341
阅读 7270
收藏 16

TIOBE 2017 年度编程语言榜单已出炉,世界上最好的语言 PHP 再度无缘年度编程语言。

距离其上次(2004 年)获得年度编程语言,已有 13 年之久。而从历年 TIOBE 编程排行榜趋势图也可以看到,自 2014 年以来,PHP 总体处于持续下滑趋势。

作为世界上最好的语言,PHP 的霸主地位会被撼动吗?

据 W3Techs.com 的数据显示,近年来,有超过 80% 的网站在服务器端的编程语言选择了 PHP,一门语言流行的背后必会有其原因,PHP 一开始凭借其简单上手而流行起来,而持续流行了这么多年,我们相信不仅仅是由于它的易于使用,作为一门服务器端的语言,如果性能没有足够好,很难一直被流行至今。

下面,我们不妨回顾下 PHP 的性能是如何演进的。

PHP 的性能演进历史

PHP 是 Web 开发最常用的语言,自 1994 年 Rasmus Lerdorf 创建 PHP 以来,PHP 语言经历了许多激烈的改进,其中性能是开发人员在评估新版本时考虑的主要标准之一。每个大版本的更新都会带来很多新特性和性能提升。

有关 PHP 性能改进的主要版本历史:

  • 1994:Rasmus Lerdorf 为了维护个人网页而制作了一个简单的用 Perl 语言编写的程序,称为 Personal Home Page
  • 1995:Rasmus Lerdorf 用 C 语言对"Personal Home Page"进行重新编写,包括可以访问数据库,并于 1995 年 6 月 8 日发布了首个公开版。这是 PHP 1.0 版本,也是第一次使用了"PHP"的名字
  • 1997:Rasmus Lerdorf、Andi Gutmans 和 Zeev Suraski 加入了该语言的第三个版本的开发,并进行根本性的重新设计,性能大大提升。从那之后, PHP 开发组也创建并发展起来。PHP 也在这个时候改称为 PHP:Hypertext Preprocessor
  • 2000:以 Zend Engine 1.0 为基础的 PHP 4 正式发布,自此,PHP 的性能才开始变得正式起来
  • 2004:发布了 PHP 5,PHP 5 使用了第二代的 Zend Engine。PHP 包含了许多新特色,如强化的面向对象功能、引入 PDO(PHP Data Objects,一个存取数据库的延伸函数库)、以及许多效能上的增强
  • 2015:12 月 3 日,PHP 7.0 正式发布,使用的 Zend Engine 3 带来了 100% 的性能提升,还有统一的变量语法,基于抽象语法树编译过程

可以看到,于 2015 年发布的 PHP 7 在性能方面取得了重大的突破。该版本最大的改进莫过于无感知的 100% 性能提升,其中包含了运行速度与内存消耗。与 PHP 5 相比,PHP 7 的综合性能提升了一倍以上。

PHP 7 带来的性能飞跃让开发者获益良多,使得很多应用受益,也使得 PHP 的应用场景变得更加广泛。

那么下一步 PHP 的性能提升方向是什么?下文将分享 PHP 下一个性能提升的主要举措:JIT 的进展,以及下一个大版本的 PHP 可能带来的特性。( 整理出自:2017 年 OSC 源创会年终盛典鸟哥演讲《PHP Next: JIT》)

鸟哥表示,从 PHP 7 发布到现在,在提交一些关于性能提升的工作时,阻力会变得小很多。可以说,PHP 7 是开启了 PHP 性能发展方向的一个风潮。

事实上,为一个有长远历史的程序做优化的难度比推倒重构更高。PHP 7 在性能方面带来了跨越式的提升,如果能够将这些成果应用到使用 PHP 的 Web 系统中,也许只需要更少的机器,就能支撑起更高请求量的服务。

PHP 7 之后会有什么 —— JIT

这是一个十分值得我们期待的版本,目前由 Zend 引擎的 Dmitry Stogov 主导。虽然它是基于 PHP 7.1 版本,但实际版本号尚未确定。

JIT 是什么?为什么是 JIT?

JIT (Just-In- Time 即时编译) 并非是新技术,很多语言例如 Java 早已实现。JIT 的思想很简单,即在程序运行时动态对程序进行编译,生成平台相关的机器码(比如运行它的机器 CPU 的本地代码),从而加快程序的运行速度。

为什么是 JIT?

不妨先来看看 PHP 文件的执行流程。PHP 文件的执行流程大致是首先引擎加载 PHP 文件,解释器逐条解释执行代码。

引入 JIT 后,前面部分一样,重点是 JIT 编译器会根据 Runtime 信息对热点代码进行动态编译生成机器码,此后这部分代码就可以直接执行,不再需要解释器逐条解释执行,因此运行效率会得到提升。

Facebook 开源的 PHP 虚拟机 HHVM(HipHop Virtual Machine) 就采用了 JIT,这让他们的 PHP 性能测试结果提升了一个数量级,也让开发者意识到 JIT 是一项点石成金的强大技术。HHVM 也是目前最热门的带 JIT 编译器的 PHP 实现。

PHP 7.1 引入了类型推断

而 PHP 要想实现 JIT,必须要解决变量的类型推断这个难题。试想,如果在动态编译时仍需要进行大量的类型检查,性能将会大幅下降。

PHP 7.1 引入了一个称作“类型推断”的特性,这是现阶段正在实现的 JIT 的前驱,但它不是单独开发的,2013 年的 PHP 5 已经实现了一套推断系统,7.1 嵌入了这套系统并对其进行优化。

PHP 7 中已经可以控制变量的类型,7.1 对这个机制进行了完善。我们甚至可以说目前的 PHP 已经是半强类型语言,但由于 PHP 的弱类型语言历史,目前仍有大量代码在运行前无法得知变量类型,所以在 7.1 中 PHP 的开发者进行了大量变量类型推断的工作,为后续的 JIT 实现打下基础。

对变量进行推断,目前比较简单的一种办法是数据流分析,即分析代码的上下文,从而推断出变量的可能类型,比如:

function calc ($a1, $b2) {        // $a1: [ANY], $b2: [ANY]
    $T3 = $a1 * 2;                // $T3: [LONG, DOUBLE]
    $a4 = $T3 % 1000;             // $a4: [LONG]
    $T5 = $b2 * 3;                // $T5: [LONG, DOUBLE]
    $b6 = $T5 % 1000;             // $b6: [LONG]
    $T7 = $a4 + $b6;              // $T7: [LONG, DOUBLE]
    return $T7;
}

对于这项改进,目前依然有较多的困难,鸟哥表示他们的解决思路是对 JIT 进行分级,通过配置实现不同程度的动态编译,从而降低类型预测的难度。此外,针对具体的场景,进行垂直优化。除了基于数据流的分析,PHP 7.1 还会基于分支进行判断。

PHP 7.2 继续提升性能并完善类型推断

PHP 7.2 不久前也已发布,与 7.1 相比,它的性能有大约 10% 的提升。7.2 在数据流分析里引入了三个新特性。

  • sparse conditional constant propagation
  • 逃逸分析
  • 移除“死代码”(消除没有副作用的代码)

PHP 7.2 还包括对基于分支预测的优化,此外,还引入了称为"HYBRID VM"的虚拟机引擎。

关于 JIT 性能表现的一些数据

那么,JIT 性能的提升效果表现如何?这要取决于项目的实际瓶颈。鸟哥表示,JIT 对性能提升要看具体的情景,如果某段逻辑是计算密集型的,它的提升大概有 1/4,不过也有一些性能提升不明显的场景,如果在 IO 密集型场景下进行测试,性能的提升不会很明显,所以一定要考虑具体的使用场景。

此外,鸟哥表示,将来如果要写出更友好的代码,不妨考虑多添加一些类型提示。

最后

TIOBE 编程语言社区排行榜是编程语言流行趋势的一个指标,名次的下降一定程度反映了当前编程语言的流行趋势,但不能成为衡量一门语言是否优秀的唯一标准。有些编程语言受众领域较小,难以达到大范围的推广普及,但在它所专长的领域,发挥着独有的优势。

PHP 在服务端编程语言领域依旧占据主导地位,同时,PHP 社区组持续不断地做版本迭代更新,性能提升。下一个大版本将引入 JIT 特性,这个被奉为点石成金的技术会给 PHP 带来更好的性能,更大的发展吗?

参考:

http://hansionxu.blog.163.com/blog/static/24169810920158704014772/
http://www.laruence.com/2016/12/18/3137.html
https://www.jianshu.com/p/de1b5c6849c8

© 著作权归作者所有

共有 人打赏支持
编辑部的故事

编辑部的故事

粉丝 1121
博文 244
码字总数 410711
作品 0
深圳
运营/编辑
加载中

评论(97)

彩虹梦
彩虹梦

引用来自“eechen”的评论

JIT绝不是什么万金油,别以为有个JIT就能有多快.
跑PHP计算测试,有JIT的HHVM跟没有JIT的PHP7,性能伯仲之间:
HHVM 3.18 vs PHP 7.1 压力测试:
time hhvm php-src/Zend/bench.php 耗时 0.882s
time php php-src/Zend/bench.php 耗时 0.961s
time hhvm php-src/Zend/micro_bench.php 耗时 4.611s
time php php-src/Zend/micro_bench.php 耗时 3.934s
time hhvm php-src/ext/hash/bench.php 耗时 13.635s
time php php-src/ext/hash/bench.php 耗时 15.134s
所以别道听途说什么有了JIT性能就一定突飞猛进.
搞技术不能人云亦云,要自己去测试,去对比.

生成一个包含100万个元素的关联数组(字典/映射),PHP7的耗时仅为Node7的1/3,就连PHP5都比Node7要快.测试内容主要包含时间戳获取,字符串拼接,关联数组生成这几个开发中经常用到的操作.另外把Object换成Map(ES6)后,Node仍然比PHP5.4慢,更别提跟PHP7比了.
https://static.oschina.net/uploads/space/2017/0507/114545_l2Gp_561214.png
所以说,别以为有JIT性能就一定更高.

所以个人看法,我根本不期待PHP的JIT,因为PHP7性能本来就足够好了,就算实现了JIT,也不过锦上添花.相比JIT,个人更看好Swoole引擎,让PHP跑在逻辑内存常驻并且异步无阻塞的环境下,这个才是除了PHP7外能明显大幅提升PHP应用的杀手级引擎,只不过原有PHP应用需要修改代码适配到Swoole上才能正常运行.

引用来自“开源春哥”的评论

鸟哥今年的ppt里面讲过,jit版本在实测中比php7.2性能还有很多提升。JIT版本还是很值得期待的。
更重要的是JIT版本给php更多的想象空间,比如计算密集型的应用。
Swoole 已经把 php 搞成了 异步的东西,各种回调。。 还不如用node.js。除非计算密集型的才用php
灌直
灌直

引用来自“HNB09”的评论

PHP什么时候可以写桌面程序啊
:+1:
开源春哥
开源春哥

引用来自“回去干活”的评论

说实话,我现在线上项目7.1,全部强类型,感觉就像在写java.或者说完全就是java.
好处就是部署快,一个svn就能同步了.
就现在这样蛮好了.
如果因为 JIT而导致部署麻烦的话,我还是愿意停留在7这个系列.

引用来自“开源春哥”的评论

引入JIT之后,也不会引起部署额外的成本,应该和之前一样。所以不用担心。

引用来自“eechen”的评论

https://static.oschina.net/uploads/space/2016/1215/213629_gJ1R_561214.png
有人做过测试,计算上,JIT版本的确比PHP7要快1倍左右,但对真实应用如WordPress上来说,收益并不大,就连维护者Stogov(斯托戈夫)也明确了这一点:
https://github.com/zendtech/php-src/tree/zend-jit/ext/opcache/jit
但Swoole对PHP真实应用收益真的大,比如缓慢的Laravel框架适配到Swoole上时,在简单的测试中,RPS吞吐量能得到数量级的提升,其中【内存常驻】是提升【大型PHP框架】性能的重要原因,另外Swoole提供的异步也能轻松解决IO阻塞的问题.

https://github.com/StoneGroup/stone
测试: Laravel 简单接口
PHP-FPM: 150 RPS
Stone-Web: 3000 RPS
Stone-Server: 8500 RPS
原生PHP直接echo: 9500 RPS
Stone依赖swoole和runkit这2个PECL扩展.
PHP的应用又不是只有wordpress。:) 再者说回来,不需要改程序,升级下版本,就可以获得性能的提升,不是很好的事情嘛。
orpherus
orpherus

引用来自“eechen”的评论

引用来自“回去干活”的评论

说实话,我现在线上项目7.1,全部强类型,感觉就像在写java.或者说完全就是java.
好处就是部署快,一个svn就能同步了.
就现在这样蛮好了.
如果因为 JIT而导致部署麻烦的话,我还是愿意停留在7这个系列.

引用来自“开源春哥”的评论

引入JIT之后,也不会引起部署额外的成本,应该和之前一样。所以不用担心。
https://static.oschina.net/uploads/space/2016/1215/213629_gJ1R_561214.png
有人做过测试,计算上,JIT版本的确比PHP7要快1倍左右,但对真实应用如WordPress上来说,收益并不大,就连维护者Stogov(斯托戈夫)也明确了这一点:
https://github.com/zendtech/php-src/tree/zend-jit/ext/opcache/jit
但Swoole对PHP真实应用收益真的大,比如缓慢的Laravel框架适配到Swoole上时,在简单的测试中,RPS吞吐量能得到数量级的提升,其中【内存常驻】是提升【大型PHP框架】性能的重要原因,另外Swoole提供的异步也能轻松解决IO阻塞的问题.

https://github.com/StoneGroup/stone
测试: Laravel 简单接口
PHP-FPM: 150 RPS
Stone-Web: 3000 RPS
Stone-Server: 8500 RPS
原生PHP直接echo: 9500 RPS
Stone依赖swoole和runkit这2个PECL扩展.

原生php能跑9500,laravel去掉session等middleware,大概能跑个1600。但是laravel的路由性能不好,多了也会慢,得改造成常驻内存模式。
eechen
eechen

引用来自“回去干活”的评论

说实话,我现在线上项目7.1,全部强类型,感觉就像在写java.或者说完全就是java.
好处就是部署快,一个svn就能同步了.
就现在这样蛮好了.
如果因为 JIT而导致部署麻烦的话,我还是愿意停留在7这个系列.

引用来自“开源春哥”的评论

引入JIT之后,也不会引起部署额外的成本,应该和之前一样。所以不用担心。
https://static.oschina.net/uploads/space/2016/1215/213629_gJ1R_561214.png
有人做过测试,计算上,JIT版本的确比PHP7要快1倍左右,但对真实应用如WordPress上来说,收益并不大,就连维护者Stogov(斯托戈夫)也明确了这一点:
https://github.com/zendtech/php-src/tree/zend-jit/ext/opcache/jit
但Swoole对PHP真实应用收益真的大,比如缓慢的Laravel框架适配到Swoole上时,在简单的测试中,RPS吞吐量能得到数量级的提升,其中【内存常驻】是提升【大型PHP框架】性能的重要原因,另外Swoole提供的异步也能轻松解决IO阻塞的问题.

https://github.com/StoneGroup/stone
测试: Laravel 简单接口
PHP-FPM: 150 RPS
Stone-Web: 3000 RPS
Stone-Server: 8500 RPS
原生PHP直接echo: 9500 RPS
Stone依赖swoole和runkit这2个PECL扩展.
orpherus
orpherus

引用来自“福嘞娃”的评论

引用来自“orpherus”的评论

引用来自“回去干活”的评论

说实话,我现在线上项目7.1,全部强类型,感觉就像在写java.或者说完全就是java.
好处就是部署快,一个svn就能同步了.
就现在这样蛮好了.
如果因为 JIT而导致部署麻烦的话,我还是愿意停留在7这个系列.

引用来自“邪小白”的评论

写php写着写着就等于在写java了。特别是定了很多规范之后。哎,但是确没有java那么多重量级的第三方包,还不如直接些java呢。

引用来自“志田未来”的评论

解析 json,json_decode 一个函数搞定, java 可以不?
有些情况弱类型更方便.
PHP 只是提供更多选择,又不是废除弱类型,
有傻吊喜欢所有强类型,不会利用 PHP 优势,那也没办法.

引用来自“bboo”的评论

这位同学怕是不知道java那些强大的第三方库
gson,fastjson等等 都是既简单又强大
而且,这还是在java不太推荐用json这种灵活性太高的情况下

引用来自“志田未来”的评论

解析一个 json 还满世界找第三方库,怪不得开发效率这么低啊
来用你强大的第三方库,用 php 一句话提取出:json_decode('{"*":"xx", "1":{"*":123}}', true)["1"]['*']
要自动识别为 string, 别想定义结构,或类型转换,自动取出数据来给我瞧瞧啊

引用来自“orpherus”的评论

主流不是gson就是jackson,maven仓库里就有,国内可以用阿里云的mirror,还要满世界找?

你要的一句话,jacksonObjectMapper().readTree("""{"*":"xx", "1":{"*":123}}""").get("1").get("*").asText()

引用来自“志田未来”的评论

所以还是做了类型转换, asText/asInt
要自动识别为 int, $a=json_decode('{"*":"xx", "1":{"*":123}}', true)["1"]['*']
gettype($a) 为 int,java 不行了吧

引用来自“orpherus”的评论

常用的数据结构,我们都会定义好类型,不会用这种方式解析。哪天不小心拼写错误,或者访问了不存在的字段的时候,编译器会报错,而不是像PHP那样上线了再报undefined index xxxx。

在给客户端返回JSON的时候,php还需要手动转换一下类型,最常见的坑就是json_encode((object)[]),map为空的时候,它会当作空list返回,客户端直接抛异常了。

今天恰好在v2看到有人吐槽PHP返回值,时而int时而string,变幻莫测。
https://www.v2ex.com/t/421511

引用来自“福嘞娃”的评论

就你还说做过PHP,笑死人了,那叫数组,不叫map,json_encode([])都是以数组的形式转换成json的,数组的格式都是之前就封装好的一个结构,比如['status'=>'ok','code'=>1,'msg'='str','data'=>$data];所有的数据都是放到$data数组里面,即使数组是空的,也不会影响固定的结构,客户端永远不会报错,PHP数组的强大是你无法理解的,随意添加删减,可以装任何类型,所有的变量都可以装在数组里面统一处理

引用来自“orpherus”的评论

data为空的时候,还是会有歧义
['status'=>'ok','code'=>1,'msg'='str','data'=>{}]
['status'=>'ok','code'=>1,'msg'='str','data'=>[]];
两层还好办,如果嵌套四五层或者更多,有时内层的数据还是别人的接口返回的。
我们代码里有大量这种强制转换,关联数组那点儿优势早就被这种糟糕的体验抵消了。

引用来自“福嘞娃”的评论

$data永远是数组,就算没有东西也是数组,并不会歧义,接口有问题status就是error了,不会出现什么‘data’=>{},$data 是可以首先就定义为数组的$data=[];数据只是$data里面的一个元素而已,里面的元素可以定死,也可以不定死,这种东西根本就不是什么问题,只有做php不超过3个月的人才会说这种,数组可以二维三维四维,元素是里面再定数组,简单方便的很,比java这种强类型简单10倍都不止,同样做到无坑,PHP比java还是代码少很多也简单很多
接口需要返回{k1:v1, k2:v2}的时,不序列化的时候都一样,一旦json_encode,有东西就是{},没东西就是[]。为了规避这种错误,我们设计接口的时候尽量不返回map,都用list,把{k1:v1, k2:v2}变成[{k: k1,...},{k:k2,...}]这种形式,客户端自己去转化成map用。然后为了防止某些地方不长眼返回了{k1:v1,k2:v2}这种key不连续和纯粹的数组,一律用array_values强转了。

在我看来Java和PHP都是糟糕的语言,都很罗嗦,只看语法本身,这两货给C#提鞋都不配。你拿来举例的车轮,现在内部在推Go语言,难道Swoole团队不如你们懂PHP?

@orpherus 听你扯犊子,韩天峰就在群里,车轮根本就没有用Go,以后用Go也不是做PHP层面的东西

好吧,你比我这个在车轮干了两年的员工更了解车轮,呵呵
马丁的早晨
马丁的早晨

引用来自“福嘞娃”的评论

引用来自“bboo”的评论

引用来自“gaicitadie”的评论

还有那些鄙视php只能做web端“增改删查”的,现在市面上的项目有几个不是web的?有几个不是“增改删查”堆积起来的?可以说80%以上的java程序员都在做着“增改删查”的工作。真正底层大数据的领域未必是java的强项了,不然java也不会跟PHP在这个帖子下打起来。

同行是冤家嘛,都是做着web增改删查的工作,抢着这块蛋糕,javaer却嘲笑“php只能做增改删查”,全然忘记了自己就是做增改删查的抠腚仔,丢不丢脸呐
我也逛了不少论坛,真的发现一个共同点:phper的素质普遍比较差,没说几句就会人身攻击。反观其他语言的开发者就要好很多。

@bboo 我逛了这么久论坛,javaer基本是最弱智的,我已经不知道看到过多少个javaer说php只能写在page里面,jsp==php这种话,相反很少看到其他语言开发人员这样说

php的点是拼接符,这一点实在难以接受,总是容易搞错。
福嘞娃
福嘞娃

引用来自“bboo”的评论

引用来自“gaicitadie”的评论

还有那些鄙视php只能做web端“增改删查”的,现在市面上的项目有几个不是web的?有几个不是“增改删查”堆积起来的?可以说80%以上的java程序员都在做着“增改删查”的工作。真正底层大数据的领域未必是java的强项了,不然java也不会跟PHP在这个帖子下打起来。

同行是冤家嘛,都是做着web增改删查的工作,抢着这块蛋糕,javaer却嘲笑“php只能做增改删查”,全然忘记了自己就是做增改删查的抠腚仔,丢不丢脸呐
我也逛了不少论坛,真的发现一个共同点:phper的素质普遍比较差,没说几句就会人身攻击。反观其他语言的开发者就要好很多。

@bboo 我逛了这么久论坛,javaer基本是最弱智的,我已经不知道看到过多少个javaer说php只能写在page里面,jsp==php这种话,相反很少看到其他语言开发人员这样说
福嘞娃
福嘞娃

引用来自“orpherus”的评论

引用来自“回去干活”的评论

说实话,我现在线上项目7.1,全部强类型,感觉就像在写java.或者说完全就是java.
好处就是部署快,一个svn就能同步了.
就现在这样蛮好了.
如果因为 JIT而导致部署麻烦的话,我还是愿意停留在7这个系列.

引用来自“邪小白”的评论

写php写着写着就等于在写java了。特别是定了很多规范之后。哎,但是确没有java那么多重量级的第三方包,还不如直接些java呢。

引用来自“志田未来”的评论

解析 json,json_decode 一个函数搞定, java 可以不?
有些情况弱类型更方便.
PHP 只是提供更多选择,又不是废除弱类型,
有傻吊喜欢所有强类型,不会利用 PHP 优势,那也没办法.

引用来自“bboo”的评论

这位同学怕是不知道java那些强大的第三方库
gson,fastjson等等 都是既简单又强大
而且,这还是在java不太推荐用json这种灵活性太高的情况下

引用来自“志田未来”的评论

解析一个 json 还满世界找第三方库,怪不得开发效率这么低啊
来用你强大的第三方库,用 php 一句话提取出:json_decode('{"*":"xx", "1":{"*":123}}', true)["1"]['*']
要自动识别为 string, 别想定义结构,或类型转换,自动取出数据来给我瞧瞧啊

引用来自“orpherus”的评论

主流不是gson就是jackson,maven仓库里就有,国内可以用阿里云的mirror,还要满世界找?

你要的一句话,jacksonObjectMapper().readTree("""{"*":"xx", "1":{"*":123}}""").get("1").get("*").asText()

引用来自“志田未来”的评论

所以还是做了类型转换, asText/asInt
要自动识别为 int, $a=json_decode('{"*":"xx", "1":{"*":123}}', true)["1"]['*']
gettype($a) 为 int,java 不行了吧

引用来自“orpherus”的评论

常用的数据结构,我们都会定义好类型,不会用这种方式解析。哪天不小心拼写错误,或者访问了不存在的字段的时候,编译器会报错,而不是像PHP那样上线了再报undefined index xxxx。

在给客户端返回JSON的时候,php还需要手动转换一下类型,最常见的坑就是json_encode((object)[]),map为空的时候,它会当作空list返回,客户端直接抛异常了。

今天恰好在v2看到有人吐槽PHP返回值,时而int时而string,变幻莫测。
https://www.v2ex.com/t/421511

引用来自“福嘞娃”的评论

就你还说做过PHP,笑死人了,那叫数组,不叫map,json_encode([])都是以数组的形式转换成json的,数组的格式都是之前就封装好的一个结构,比如['status'=>'ok','code'=>1,'msg'='str','data'=>$data];所有的数据都是放到$data数组里面,即使数组是空的,也不会影响固定的结构,客户端永远不会报错,PHP数组的强大是你无法理解的,随意添加删减,可以装任何类型,所有的变量都可以装在数组里面统一处理

引用来自“orpherus”的评论

data为空的时候,还是会有歧义
['status'=>'ok','code'=>1,'msg'='str','data'=>{}]
['status'=>'ok','code'=>1,'msg'='str','data'=>[]];
两层还好办,如果嵌套四五层或者更多,有时内层的数据还是别人的接口返回的。
我们代码里有大量这种强制转换,关联数组那点儿优势早就被这种糟糕的体验抵消了。

引用来自“福嘞娃”的评论

$data永远是数组,就算没有东西也是数组,并不会歧义,接口有问题status就是error了,不会出现什么‘data’=>{},$data 是可以首先就定义为数组的$data=[];数据只是$data里面的一个元素而已,里面的元素可以定死,也可以不定死,这种东西根本就不是什么问题,只有做php不超过3个月的人才会说这种,数组可以二维三维四维,元素是里面再定数组,简单方便的很,比java这种强类型简单10倍都不止,同样做到无坑,PHP比java还是代码少很多也简单很多
接口需要返回{k1:v1, k2:v2}的时,不序列化的时候都一样,一旦json_encode,有东西就是{},没东西就是[]。为了规避这种错误,我们设计接口的时候尽量不返回map,都用list,把{k1:v1, k2:v2}变成[{k: k1,...},{k:k2,...}]这种形式,客户端自己去转化成map用。然后为了防止某些地方不长眼返回了{k1:v1,k2:v2}这种key不连续和纯粹的数组,一律用array_values强转了。

在我看来Java和PHP都是糟糕的语言,都很罗嗦,只看语法本身,这两货给C#提鞋都不配。你拿来举例的车轮,现在内部在推Go语言,难道Swoole团队不如你们懂PHP?

@orpherus 听你扯犊子,韩天峰就在群里,车轮根本就没有用Go,以后用Go也不是做PHP层面的东西
高久峰
高久峰

引用来自“HNB09”的评论

PHP什么时候可以写桌面程序啊

早可以了
Windows和Mac持续走低,Linux是否能够重返荣耀?

  【IT168 编译】上一次听到“Linux桌面年”这个词汇还是很早之前。今年,FOSS和Linux社区又提出了这个说法,并期望Linux在未来的几个月内采用率会呈指数级增长。虽然在桌面场景中,Linux...

it168网站
2017/09/07
0
0
如何对抗亚马逊?从云服务及无人商店做起

【Technews科技新报】尽管谈及零售业战争多半是指亚马逊及沃尔玛,但事实上,其他零售商也并非坐以待毙。 亚马逊不仅是零售业的黑马,更已成为科技业的巨头,其云端业务是近年来成长最为迅速...

黄 敬哲
04/03
0
0
Mozilla 押重注到 Firefox 57,正面回击 Chrome

曾几何时,Firefox 风靡全球,不但深受程序员喜爱,也成为普通人的桌面贵客,最高占有率曾达到七八成。但是现在,根据全球浏览器报告来看,Google Chrome 已经在近两年牢牢占据霸主地位。就拿...

王练
2017/08/18
5.8K
59
2017年互联网发展几大趋势

趋势不一定非得十大、八大,总有凑数之嫌! 结合目前已找到的各种猜想,以及我个人对互联网的看法,总结以下几个2017年互联网爆发点! 一、共享经济 1、摩拜单车、OFO 将如同滴滴打车和优步打...

找前辈网
2017/10/24
0
0
PHP 语言地位遭受挑战,PHP 程序员路在何方?

在 TIOBE 12 月编程语言排行榜中,PHP 位居第九位,相比 2016 年下降了两位。 PHP 从诞生到现在已经有 20 多年的历史,历经互联网的兴衰,但在编程语言领域仍保持着举足轻重的地位。 Top 10...

OSC源创君
2017/12/18
11.3K
294

没有更多内容

加载失败,请刷新页面

加载更多

下一页

windbg学习记录

我开始熟练使用windbg是从帮助手册开始的,也就是.hh命令。 就像学习windows开发从msdn开始一样,微软的产品虽然不开源,但是文档做的是相当的好。然而那些开源的东西呢?开源的竞争力其实就...

simpower
10分钟前
0
0
学习scala的网站汇总

https://www.codacy.com/blog/how-to-learn-scala/

Littlebox
12分钟前
0
0
配置本地的cloud9开发环境

前言 说到在线IDE开发环境,cloud9是不能绕过的,cloud9支持很多语言,默认支持的就有Node.js,Python,Ruby,PHP,Go,更逆天的是,他还支持数据库,包括MySQL,MongoDB,Redis,SQLite。但...

Kefy
16分钟前
0
0
springcloud应用程序上下文层次结构

如果您从SpringApplication或SpringApplicationBuilder构建应用程序上下文,则将Bootstrap上下文添加为该上下文的父级。这是一个Spring的功能,即子上下文从其父进程继承属性源和配置文件,因...

itcloud
21分钟前
0
0
新程序员最爱的免费资源

简评:国外美女程序员推荐了她自己用过的一些免费资源,对新手比较友好的那种。 原作者 Ali Spittel,是个美女程序员,以下这些资源都是她自己试过的。以下「我」代表 Ali Spittel。 学 HTML...

极光推送
24分钟前
0
0

没有更多内容

加载失败,请刷新页面

加载更多

下一页

返回顶部
顶部