某女：你能让这个论坛的人都吵起来，我就跟你吃饭。
PHP程序员：PHP是世界上最好的语言！
某论坛炸锅了，各种吵架……
某女：服了你了，我们走吧！
PHP程序员：今天不行，我一定要说服他们，PHP必须是最好的语言。
有人用的语言，就有人骂，骂声越大，用的人也就越多。世上没有完美的语言，最合适的语言就是最好的语言，我们要做的，就是扬长避短，少踩那些坑，下面直接进入主题。
0x01, 弱类型
==和===异同这种太过低级的坑就直接跳过了，先看一个稍微隐蔽点的坑
function translate($keyword)
{
$trMap = [
'baidu' => '百度',
'sougou' => '搜狗',
'360' => '360',
'google' => '谷歌'
];
foreach ($trMap as $key => $value) {
if (strpos($keyword, $key) !== false) {
return $value;
}
}
return '其他';
}
echo translate("baidu") . "\n";
echo translate("360") . "\n";
期待的结果是
百度
360
实际运行结果是
百度
其他
仔细检查，没有string和int的混用，比较也都是用的 !== ，没有用==，为什么还会掉坑里？
问题出在了array上面，虽然你写的是
$trMap = [
'baidu' => '百度',
'sougou' => '搜狗',
'360' => '360',
'google' => '谷歌'
];
但是PHP给你处理成了
array(4) {
["baidu"]=>
string(6) "百度"
["sougou"]=>
string(6) "搜狗"
[360]=>
string(3) "360"
["google"]=>
string(6) "谷歌"
}
360变成了int类型，这个时候strpos不该报错吗？不，当然是原谅它啦，它选择兼容int
If needle is not a string, it is converted to an integer and applied as the ordinal value of a character.
360的hex表示是0x168，所以当你这样调用时，它能匹配
translate("\x1\x68")
那么正确的写法是怎么样的呢？稍加改动即可
strpos($keyword, $key) //改为 strpos($keyword, (string) $key)
可怕之处在于
- 自以为用了===就安全了，忽视了弱类型无处不在这个隐患
- 你可能并没有仔细看每一个函数的说明，没有逐个核对每个参数的类型
- 引发的bug不一定能重现，也有可能平时不会触发，但是留下了安全漏洞
如何100%的避免弱类型的坑？答案是换强类型语言。如果不能换呢？通过以下准则，虽然做不到100%避免，但是做到99.99%是有希望的。
- 能用===/!==的地方，绝不用==/!=，知道类型的情况下，先强转再用===比较
- 调用函数的时候，如果你知道参数类型，在调用时强制转换一下，不能嫌麻烦
我说的是弱类型，不是动态类型，两者不是一码事，不要误会。Python是动态类型强类型，PHP是动态类型弱类型，C语言是静态类型弱类型。如果可以选择，我宁可PHP放弃弱类型，因为弱类型带来的麻烦，已经超出它的便利了。提供一个strict运行模式也行，给足大家十年八年时间慢慢迁移。
0x02, 空字典json序列化成了[]
随着APP的流行，PHP很多时候不是跟浏览器端的JS交互，而是跟Java和ObjC这样的静态类型语言交互，返回值的类型定义，就很重要了，举个栗子
$ret1 = [
'choices' => ['鱼香肉丝', '宫保鸡丁'],
'answers' => [
'张三' => 0,
'李四' => 1,
'赵云' => 0,
],
];
$ret2 = [
'choices' => [],
'answers' => [],
];
echo json_encode($ret1) . "\n";
echo json_encode($ret2) . "\n";
输出
{"choices":["\u9c7c\u9999\u8089\u4e1d","\u5bab\u4fdd\u9e21\u4e01"],"answers":{"\u5f20\u4e09":0,"\u674e\u56db":1,"\u8d75\u4e91":0}}
{"choices":[],"answers":[]}
客户端在定义这个model的时候，可能是这样定义的
class ResultDTO {
lateinit var choices: List<String>
lateinit var answers: Map<String, Int>
}
当返回ret1的时候，一切顺风顺水，皆大欢喜。如果返回ret2呢，客户端抗议了
com.fasterxml.jackson.databind.JsonMappingException: Can not deserialize instance of java.util.LinkedHashMap out of START_ARRAY token
原因是什么呢？PHP的json_encode面对一个空的array的时候，它很为难，它不知道应该当它是list还是map，所以它只能一刀切，认为它就是list，于是客户端就不高兴了。解决办法不是没有，依然是强制转换。
$ret2 = [
'choices' => [],
'answers' => (object) [],
];
但是这样就带来一个问题，如果answers不是写死的，而是某个API的返回值，你并不确定它是不是会返回空的，它也没有义务帮你cast成object，因为JSON序列化是跟前端交互的事情，不应该放到后端service层面解决。那么你只能自己动手了，手动把返回值中可能出现空map的地方，全部强制转换一遍。
PHP的关联数组的确很强大，算法设计的也不错，性能也很好，但是它不是没有代价的，上面的栗子算是其中一个。如果PHP也像其它语言一样，区分map和list，可能会省事一些，毕竟区分{}和[]，对程序员来说并不会增加很多学习成本。
0x03, 健忘的FPM
近些年，Swoole和WorkerMan那样的CLI部署方式，慢慢被中国人知悉和应用，然而跟FPM或者mod_php相比，CLI方式还是太过非主流，在绝对垄断的FPM/mod_php面前，CLI在缓慢成长中。FPM的缺点很明显，每个请求结束的时候，你在PHP代码里创建的对象都被清理了，你执行过的代码，就跟没执行过一样，不留痕迹。
在hello world那样的微型应用中，好像问题不大，稍微大一点的项目，我们为了DRY，为了少做重复劳动，为了提高开发效率，不得不使用框架，然后问题就来了，用PHP写的PHP框架，由于FPM的健忘，框架从init开始，到读取配置文件，到初始化各个组件，这种工作在每个请求到来的时候，都要重复的做一次，如果你需要读一个100M的元数据，那么每个HTTP请求来时，你都要读一次并解析一次，当你HTTP请求结束返回时，你解析过的100M元数据，又被销毁了，下一个请求来时，你依然要重复做。
本来PHP 5.6已经可以吊打Python 3.6的性能了，PHP 7.1都不屑于跟Python比性能了，快几倍了。但是一旦引入同体量的框架，比如PHP用Laravel，Python用Django，剧情就反转了，Django竟然可以吊打PHP7加持的Laravel了。一个百米运动员就算跑的再快，每次枪响后都要先穿鞋带，穿好鞋带再穿鞋，然后再跑，跑完了把鞋脱下，再把鞋带抽出。就算它100米只要1秒就能跑完，光穿鞋的时间就够别的选手跑个来回了。
所以包括PHP之父本人在内，都对Laravel这样的封装深的厚框架表示质疑，在需要考虑性能的时候，主流人士往往推荐不用框架，或者用极简的框架，要么就是那些C写的框架，比如yaf和phalcon。框架性能问题算是曲线解决了，那么用户自己的逻辑呢？这个就比较麻烦了。分情况探讨，简单类型，如string，可以用yaconf这个扩展，可以做到不重复读取。如果是复杂的数据结构，比如树状结构，就没法用这种方式解决了。有没有解决办法呢？也不是没有，你可以写个脚本，把数据转换成PHP代码，然后通过opcache缓存起来，也能缓解一下问题。要彻底解决，只能写个C扩展让它常驻内存了，但这就超出一般PHP开发的能力范围了。
FPM这种方式并非PHP首创，在fastcgi出现之前，CGI都是这么干的，而且还是每个请求新开一个进程，比FPM还要开销大。然而到了21世纪，还在用FPM这种健忘型运行模式的，常见语言里就只剩PHP了。可能再过十年，FPM也渐渐被Swoole这样的不健忘的给取代了。
0x04，多线程支持
这里不讨论Apache的MPM是否支持多线程，也不讨论PHP的扩展是否支持多线程，更不讨论PHP到底能不能利用多线程或者多核，这里只讨论纯粹的PHP代码，能否创建和管理线程。前几年，PHP是完全不支持多线程，现在呢？据说有了pthreads，然后打开它的文档，发现
WarningThe pthreads extension cannot be used in a web server environment. Threading in PHP should therefore remain to CLI-based applications only.
WarningThe pthreads extension can only be used with PHP 7.2+. This is due to ZTS mode being unsafe in prior PHP versions.
两个限制
- 只能用在CLI下面
- 只支持PHP 7.2+
没用过多线程的人，自然不能体会多线程的便捷之处，跟多进程相比，数据共享在进程内部要容易的多。现代语言支持多线程是很自然的事情，跟PHP对比最多的Python，早就有了原生线程的支持，虽然因为GIL做不了CPU密集型应用，但是做个IO密集型还是很方便的。多线程只是锦上添花，不是雪中送炭，好在PHP的多进程支持还算OK，咱们就用多进程好了，最多共享数据结构的时候，想办法绕开便是。线程池 + 执行队列，变成进程池 + 执行队列。
0x05, 32bit平台下，没有8字节的long类型
PHP的int是平台相关的，32位平台下是4字节，64位平台下是8字节，为了代码的健壮性和可移植性，我们只能假定int就是4字节的类型。但是我们很多时候需要8字节类型，因为
- 精确到毫秒的时间戳需要long
- 很多平台对接需要long，比如阿里巴巴
这个时候就需要GMP和BCMath这样的库了，比起语言直接支持8字节的long，麻烦了一些。
0x06, 数组函数设计的太差，使用不便
PHP提供了一大堆array_xxxx函数，而没有把这些函数作为数组的方法，这种设计，乍看之下倒也没什么问题，但是有三个函数，在这种设计之下，实用性大打折扣。这三个函数是
array array_map ( callable $callback , array $array1 [, array $... ] )
mixed array_reduce ( array $array , callable $callback [, mixed $initial = NULL ] )
array array_filter ( array $array [, callable $callback [, int $flag = 0 ]] )
举个栗子，把一个数组中的数求平方，并且把平方后大于100的数相加，用普通的写法是
$arr = [1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15];
function foo_a($num_arr) {
$sum = 0;
foreach ($num_arr as $n) {
$v = $n * $n;
if ($v > 100) {
$sum += $v;
}
}
return $sum;
}
echo foo_a($arr) . "\n";
如果是简单的加减乘除，这种写法倒也OK，如果是比较复杂的逻辑，每一步的操作都会提出出来封装成相应的函数。我们来试试函数式写法，
function foo_b($num_arr) {
return array_sum(
array_filter(
array_map(function ($v) { return $v * $v; }, $num_arr), function($v){
return $v > 100;
})
);
}
echo foo_b($arr) . "\n";
看起来可读性比较差，也比较丑陋，这都拜PHP数组函数设计不合理所赐。假如可以这么写
function foo_c($num_arr) {
return $num_arr.map(function ($v) { return $v * $v;})
.filter(function ($v) {return $v > 100;})
.sum()
}
可读性和实用性是不是提高了很多？只要把map/filter/reduce这3个定义成数组的方法，并且返回数组，就可以这么写了，能不能再简洁一点呢？我们继续
function foo_c($num_arr) {
return $num_arr.map ($v -> $v * $v)
.filter($v -> $v > 100)
.sum()
}
有人可能要说我抄袭了，这不就是Java 8的lambda了嘛，对的，这就是Java 8的lambda。Java 8那点儿语法糖就吃饱了吗？显然不够，我们还可以再进一步简化下去。
function foo_c($num_arr) {
return $num_arr.map {$it * $it}
.filter {$it > 100}
.sum()
}
给只接受一个参数的lambda一个默认的参数，名字叫it，是不是又简洁了一些？还可以再继续吗？当然可以
function foo_c($num_arr) = $num_arr.map {$it * $it}
.filter {$it > 100}
.sum()
看到这里，可能已经有人看出来这是哪门语言的语法了，对的，就是它。
顺便拿PHP最喜欢比较的Python对比一下，感受一下list comprehension的魅力
sum([y for y in [x * x for x in num_arr] if y > 100])
不懂Python的人是这么写Python的，求平方写成这样，哈哈
list(map(lambda x: x * x, num_arr))
0x07, 函数命名风格太过不一致
PHP有nl2br这样的简写，还有htmlspecialchars_decode这样的长名字，据说当年PHP早期版本，用函数名字的长度作为hash，名字长度分布的均匀有助于减少hash冲突。听起来像是黑子们拿来喷PHP的，或者像PHP粉出来钓鱼的。但是看了这个
Re: Flexible function naming 我震惊了，PHP之父如是说
On 12/16/2013 07:30 PM, Rowan Collins wrote:
> The core functions which follow neither rule include C-style
> abbreviations like "strptime" which couldn't be automatically swapped to
> either format, and complete anomalies like "nl2br". If you named those
> functions as part of a consistent style, you would probably also follow
> stronger naming conventions than Rasmus did when he named
> "htmlspecialchars".
Well, there were other factors in play there. htmlspecialchars was a
very early function. Back when PHP had less than 100 functions and the
function hashing mechanism was strlen(). In order to get a nice hash
distribution of function names across the various function name lengths
names were picked specifically to make them fit into a specific length
bucket. This was circa late 1994 when PHP was a tool just for my own
personal use and I wasn't too worried about not being able to remember
the few function names.
-Rasmus
竟然是真的，太惊人了。据说后来到了PHP3的时候，替换掉了这个设计。而PHP在命名一致化的路上也一直在努力，但是考虑到兼容性，彻底解决可能还需要很多年的努力。
0x08, magic_quotes...
自动给你把GPC(GET/POST/COOKIE)变量中的特殊字符转义掉，幸好PHP 5.4已经删除这个特性了，不过有的比较传统的框架还保留着这个功能。我就想问问，你知道我要怎么用这些值吗？你知道哪些字符在我这边算特殊字符？自作主张一刀切，跟怕染HIV挥刀自宫的思路是一致的。再举个跟这个算是同类的栗子，配置对运行时行为影响过多过于复杂。
@fopen('http://example.com/not-existing-file', 'r');
很简单的一行代码，然而，它的行为却依赖诸多环境配置
如果PHP使用 --disable-url-fopen-wrapper编译, 它將不工作. (文档没有说, "不工作"是什么意思; 返回 null, 抛出异常?)
注意这点已在 PHP 5.2.5 中移除.
如果 allow_url_fopen 在 php.ini 中禁用, 也將不工作. (为什么? 无从得知.)
由于 @ , non-existent file 的警告將不打印.
但如果在php.ini中设置了scream.enabled, 它又將打印.
或者如果用 ini_set 手动设置 scream.enabled.
但, 如果 error_reporting 级别没设置, 又不同.
如果打印出来了, 精确去向依赖于 display_errors , 再一次还是在 php.ini. 或者 ini_set中.
最好的语言，隐藏了最多的黑魔法。要避开这个坑，只能尽量保证所有环境下面，编译参数一致，配置参数一致。
0x09, Error和Exception完全不同的机制
PHP 错误 (内部, 称为 trigger_error)不能被 try/catch 捕获。
同样, 异常不能通过 set_error_handler 安装的错误处理器触发错误。
作为替代, 有一个单独的 set_exception_handler 可以处理未捕获的异常。
Fatal 错误 (例如, new ClassDoesntExist()) 不能被任何东西捕获，大量的完全无害的操作会抛出 fatal 错误, 由 于一些有争议的原因被迫终结你的程序。
以上，一般框架层面会帮你解决，应用层面不需要操太多心。
0x0A, 更多的坑
eev.ee/blog/2012/0… 老外的吐槽，不过它的版本比较低，有些问题已经解决了，英文不好的看译文，五大受损, 全面解析PHP的糟糕设计 - 开源中国社区
实际上我提到的第8个和第9个坑，也在上面的文章中有提到，我就复制了来，其它的我觉得不深的坑，我倒觉得无所谓，没那么严重。
诚然，PHP的坑再多，只要用的人水平够高，也是可以写出完全正确的代码来的，然而我们大部分人都是普通人，坑的存在，或多或少都是负面影响。很多工作了5年以上的PHPer，也还会不留神掉到这些坑里。
