虽然已是 2018 年，但网上依然流传着一些「高危 PHP 函数，请一定要禁用！」的标题党文章（搜索关键字：一些需要禁用的PHP危险函数）。
这些文章的内容简单直接，给出 php.ini 的 disable_functions 的配置（包含一大堆函数），说这些函数十分危险，一定要禁用，有的内容甚至和7、8年前一模一样，被开发者们奉为秘籍，薪火相传。
禁用危险函数在理论上是可以加强安全性，但这种做法就好比做饭时害怕用菜刀切菜伤到自己而改用手撕。搞安全一定要重视对入口的控制，而不是自废武功，因为禁用某些函数会导致某些需求很难、甚至不能实现。
举个例子。
比如 Laravel 中定时任务功能的底层使用了 Symfony/Process，其中就依赖 proc_open 函数来执行命令（及其一系列函数），如果被禁用，定时任务就没法用了。
这里还有个小坑。
朋友本来有一个稳定运行的 Laravel 项目，但某天为了加强安全性，就在 php.ini 里禁用了一堆函数（网上找来的），其中就包含 proc_open 这些。后来他突然发现所有的定时任务都没有跑了，Laravel 日志和 PHP 错误日志也没有任何异常。后来他猜测应该和函数禁用行为有关，于是还原了配置，可是此时定时任务还是没有运行。
这里的坑就在于他的所有定时任务都设置了 withoutOverlapping。当开启这个设置之后，Laravel 在运行任务时会设置排他锁：开始的时候检查有没有上锁，有锁则忽略执行，否则就上锁，执行命令，执行结束之后解锁。上锁当然没问题，可是执行挂了（这里应该是静默失败，普通异常是会被捕捉然后解锁的），后面就自然没有解锁，所以配置恢复之后，开始执行时发现锁依然存在，是不会实际执行的。
怎么解决呢？Laravel 的锁使用的系统默认 Cache，所以只需要去对应 Cache 的 driver 中删掉锁的缓存文件就好了，或者等待锁过期之后也行（5.5 默认是 24 小时）。
