method_exists 和 __call 方法有什么关系？一篇讲透底层原理！

兄弟们，今天分享的这个东西，是我前几年撞过好几次墙的一个老问题。标题里那两个方法，平时我们都用得挺顺手，但它们俩合在一起，那就是一个“坑”字。

我到底是如何发现这个“坑”的？

我当时在维护一个前辈留下来的老项目，那代码写得叫一个奔放，到处都是魔术方法。我需要加个校验，确保用户调用的某个方法是存在的，不存在就给个错误提示。这不是很简单吗？我直接抄起老伙计 method_exists 就开始干活了。

我写了一个逻辑：

• 先用 `method_exists` 检查方法 A 是否存在。

• 如果返回是 `false`，我就抛出异常，或者打个日志。

  

• 如果返回是 `true`，那就接着往下走，调用方法 A。

但奇怪的事情发生了！我发现无论我怎么检查，那个方法 A 永远都返回 `false`，可当程序跳过我这个检查直接调用 `$obj->A()` 的时候，它居然他妈的跑起来了！ 整个过程没有报错，而且功能正常。

当时我就懵了，难道我用的 PHP 是个假的？我反复盯着屏幕看了半天，以为是自己眼花了，然后决定自己动手，搭一个简单的测试环境去摸摸它的底。

动手：一个简简单单的实验

我立马新建了一个空目录，写了一个小小的类，名字叫 `TestClass`，然后在里面只塞了一个东西，那就是 魔术方法 __call。这个方法大家都知道，它就是个“替身”，专门在调用那些类里压根儿不存在的方法时出来救场的。

我的代码非常简单粗暴：

先定义一个类，里面啥都没有，就一个 __call，让它接到调用后打印一句话。然后我在外面，找一个这个类里不存在的方法，比如叫 `doSomething`，我开始对它进行双重检查。

我先让 method_exists 去问问看：`TestClass`，你有没有叫 `doSomething` 的方法？

兄弟们猜怎么着？这个老实巴交的 method_exists 直接给我返回了一个 “没有”（也就是 `false`）。

我直接对这个对象的 `doSomething` 方法发起了调用。结果？终端上立马蹦出来我在 `__call` 里写的那句话，它跑起来了！

底层逻辑：它们俩的“关系”到底是什么？

这个实验立马就告诉我了：method_exists 和 __call 根本就不是一伙儿的！

我仔细想了想，这背后的逻辑简单得吓人。你可以把 `method_exists` 想成一个门卫大爷，他手上拿着一本花名册，上面密密麻麻地写着这个公司里所有正式员工的名字（也就是类里实际写出来的那些方法）。

当咱们用 `method_exists` 问他，某个方法在不在的时候，大爷就老老实实地去翻花名册。如果花名册上没有，他立马就告诉你：“查无此人！” 管你是不是魔术方法救场，大爷只认那本花名册。

而 __call ？它就不是花名册上的名字，它更像是一种 “特批权限”，一个“兜底方案”。只有当 PHP 引擎这个调度员发现，你调用的方法在花名册上根本找不到，已经走投无路了，它才会启动 __call 这个后门来处理，让你的代码不至于直接崩掉。

关系就是：

• method_exists： 它只看代码里实际存在的方法，对 `__call` 救场的那些“虚拟方法”，它看都不看，直接判死刑，返回 false。

• __call： 它是当方法确实不存在，method_exists 返回 `false` 之后，作为 PHP 引擎的一条出路才被触发的。

它们俩是一前一后、泾渭分明的两个检查点。`method_exists` 动不了 `__call` 的饭碗，`__call` 也骗不了 `method_exists` 这位老实大爷。

我为什么非要搞懂这个？

我不是一开始就这么爱钻牛角尖的。我为啥对这个小问题记得这么牢？因为当年我就是因为这个被公司老板骂了狗血淋头。

当时我刚入职没多久，对老框架还不太熟，在一次紧急上线前，我为了“稳妥”起见，加了个 `method_exists` 的检查。结果上线后，线上环境一个很核心的功能突然不工作了，用户那里全炸了。我一看，就是因为那个被 `__call` 代理的方法，被我加的检查直接给拦住了。

老板在办公室指着我的鼻子说，“你连这个基础逻辑都没搞清楚，还敢乱写校验！” 那场面，别提多丢人。那天晚上我调了半宿的代码，才把那个检查给去掉了，让系统恢复了正常。

从那以后，我对这种“魔法”和“现实”的边界就特别敏感。你永远不能相信表面上看到的东西。 这件事让我明白了，在 PHP 这种灵活的语言里，光看文档是没用的，非得自己动一遍手、掉一遍坑，你才能真正把底下的逻辑给摸透。今天我把这个经验分享出来，免得兄弟们再因为这个看似简单的逻辑，被哪个老代码的坑给绊倒了。