PHP源码深处,藏着谁的执念?

1. ⚡ 速读摘要

图示：1. ⚡ 速读摘要

• PHP解释器的核心源码与运行机制
• 从弱类型脚本到高性能执行引擎
• 一次请求背后藏着怎样的虚拟机
• PHP为何始终比想象中更难替代
• 源码揭示了PHP真正的设计哲学

2. 一个每天运行几十亿次的“老古董”，为什么还没老？

图示：2. 一个每天运行几十亿次的“老古董”，为什么还没老？

你有没有遇到过这种情况？

服务器上跑着一套十几年没大动的PHP代码，数据库设计也很陈旧，框架版本落后，线上报警像坏了的水龙头。可它偏偏不该出事。流量涨了，它还能扛；业务扩了，它还能继续接；老板问能不能换语言，团队里没人敢拍板。

这其实暴露了一个很有意思的问题。人们经常把PHP当成一门过时的语言，甚至当成“创业公司没招到更好工程师时的临时选择”。但翻开php-src的代码，会看到另一幅画面：它不是一门不肯改变的语言，而是一套不断重做自己的执行系统。

更反常识的是，PHP解释器并不是某个小团队的周末项目。它背后有跨越数十年、数代架构师和无数贡献者的投入。Zend Engine、Opcode、垃圾回收器、JIT、扩展接口、Fiber，每一个名字背后都对应着一次对性能、兼容性与工程现实之间的艰难妥协。

我第一次认真读php-src时，最强烈的感受不是“复杂”，而是“克制”。这套代码很少因为某个新语法看起来很酷，就推翻整个执行模型。它更习惯在旧地基上换梁、加固、重新布线。

我认为，这恰恰是PHP源码最值得深挖的地方。它不只是解释一门语言，也在回答一个更大的问题：一门诞生于1995年的脚本语言，如何在Web技术栈几乎每十年换一次的情况下，持续活到今天？

捏人张今天不准备做PHP语法手册，也不准备复述“PHP8更快了”之类的结论。我们直接钻进解释器内部，看看一次请求究竟经历了什么，Zend虚拟机如何工作，PHP为什么既能保持动态语言的速度感，又不得不面对内存、安全和扩展系统带来的长期账单。

3. 项目全景：PHP真正的产品，其实不是语言

php-src的官方描述只有一句：“The PHP Interpreter”。

这句话看上去平淡无奇，甚至有点大词老套。但认真理解它，就会发现php-src承担的不是“把PHP代码翻译成机器码”这么简单。它实际上同时扮演了几个角色。

它是PHP语言的语法分析器与编译器，负责把源代码变成内部表示，再变成可执行的Opcode。

它也是Zend Engine的宿主。PHP代码真正执行时，依靠的是一套寄存器式虚拟机。源码里的$a + $b，并不会像C语言那样直接变成CPU里的加法指令，而是先变成一条类似ZEND_ADD的Opcode，再由执行引擎处理。

它还是扩展系统的基础。MySQL、Redis、OpenSSL、GD、curl、mbstring、PDO，这些PHP生态里最常见的拼图，绝大多数都通过C或C++扩展接入php-src。框架能飞起来，很大程度上是因为解释器提供了足够稳定又足够低层的扩展接口。

它也是Web服务器和应用的连接层。php-src提供多种SAPI，也就是Server API。Apache模块、FastCGI进程、CLI命令行、PHP-FPM，它们都能复用同一个语言核心，只是管理请求、加载配置和调度进程的方式不同。

它顺便还承担了请求生命周期、内存管理、引用计数、垃圾回收、文件流、网络流、哈希表、字符串处理、日期时间、国际化、安全随机数、序列化、反射和错误处理等任务。

所以，php-src更像一座城市的基础设施，而不是一条单独的道路。PHP开发者平时写的是上层应用，真正托住这些应用的是源码深处那张庞大的底层网络。

41,124个Star和8,305个Fork当然说明它有巨大的影响力，但这些数字还不足以解释它的价值。更有意义的问题是：为什么一个C语言项目，能让一门脚本语言统治Web世界这么多年？

答案藏在一个看似矛盾的事实里。PHP高级、灵活，上手几乎没有门槛；PHP底层、低效，传统印象里满是性能问题。可现实中的PHP项目，特别是使用PHP-FPM、OPcache和良好架构的项目，表现往往远超预期。

矛盾的关键在于，PHP把复杂度从开发者身边挪到了解释器内部。业务代码可以写得松散，但执行引擎必须足够聪明。php-src需要替开发者处理变量类型、内存生命周期、对象关系、请求隔离、扩展调用等大量隐性工作。

它真正厉害的地方，不是“把代码跑起来”，而是“在充满不确定性的动态代码里，尽可能可靠地跑起来”。

4. 历史脉络：PHP不是设计出来的，是长出来的

PHP最早由Rasmus Lerdorf在1995年发布。最初的动机非常朴素，它只是Rasmus用来记录访问者访问自己网页信息的工具。名字来自Personal Home Page Tools，后来逐渐演变为PHP。

早期PHP像个人主页工具的拼接包，没有统一语法，也没有后来那种完整语言的感觉。真正让PHP面貌焕新的关键节点，是Andrei Zmievski在1997年主导重写的PHP 3，以及随后出现的PHP 4与Zend Engine。

Zend Engine的名字来自Andrei Zmievski与Zeev Suraski，字母重排后成为Zend。它把PHP从“把代码直接翻译”的早期执行方式，推向了更现代的编译型脚本引擎。

PHP 4时代，PHP迅速成为动态网页开发的重要选择。大量早期CMS、论坛和电商系统都建立在这套生态上。开发者第一次发现，可以用很少的代码完成表单处理、文件上传、数据库访问和页面模板渲染。

PHP 5是一次关键跃迁。Zend Engine 2带来统一对象模型、异常机制、反射、扩展接口和更完整的面向对象支持。PHP开始从“制作动态网页的脚本工具”，转向一门真正可以支撑大型应用的语言。

但PHP 5也暴露了脚本解释器的老问题。性能瓶颈、内存占用、并发模型粗糙、扩展在不同版本间不兼容，都成了企业采用PHP时绕不开的讨论。

2009年发布的PHP 7，是php-src历史上最彻底的一次性能重构之一。核心工作包括引入新的Zend Engine 3，大量使用延迟静态绑定，改进内存管理，并使用更紧凑的变量表示和Opcode设计。

PHP 7让大量PHP应用在不修改业务代码的情况下获得了显著性能提升。很多团队甚至只需要升级运行时和检查弃用项，就能看到请求耗时和吞吐量明显下降。

PHP 8则继续把重心放在JIT、类型系统和现代语言能力上。JIT编译器可以把部分Opcode进一步编译成本地机器码；命名参数、Match表达式、Nullsafe操作符、构造器属性提升、Union类型、Attributes、Enums和Fiber等能力，让PHP在保持动态特性的同时，逐步吸收现代语言设计。

有意思的是，PHP历史上几次重大进步，都不是因为PHP突然抛弃了过去。PHP 7优化了引擎，PHP 8加入现代特性，但大量旧代码仍然可以继续运行。

这形成了PHP最独特的产品哲学：不要求所有项目都重写，只要求大多数项目在升级之后变得更稳。

当然，这种兼容传统也是一把双刃刀。它让PHP拥有巨大的存量优势，也让源码内部保留了大量历史包袱。php-src不是从零开始的一张白纸，而是一座不断加盖，却不能轻易拆掉旧地基的城市。

5. 技术深潜：一次PHP请求，到底经历了什么

要理解php-src，不能只看某个函数。更有价值的方式，是跟踪一次请求从进入进程到返回结果的全过程。

假设服务器通过PHP-FPM收到一个请求：

php<?phpfunctioncalculate(int$count): int{return$count * 2;}echocalculate(21);

从网络包到达PHP-FPM开始，到响应被写回客户端，中间会经历SAPI初始化、请求启动、编译或复用Opcode、执行PHP代码、输出缓冲刷新、请求收尾等阶段。

5.1 请求边界：PHP-FPM为什么比巨型常驻进程更适合传统PHP

PHP-FPM采用按需创建或复用Worker进程的方式处理请求。每个Worker都有自己相对独立的请求上下文。请求结束后，SAPI会执行清理工作，释放本次请求创建的变量、对象、临时文件和资源。

这种模型有一个显著优势：请求之间隔离清晰。某个请求里发生的内存错误，通常不会直接污染另一个请求，只要FPM进程没有崩溃。

它的问题也同样明显。HTTP长连接、SSE、大量并发I/O和高频任务调度，会让“一请求一进程”的模型显得笨重。每个Worker都有运行时开销，进程间通信也不够自然。

这也是Swoole、RoadRunner、FrankenPHP、Workerman等方案不断出现的原因。它们试图保留PHP开发体验，同时把传统PHP的请求边界改造成常驻应用、协程或更灵活的事件循环。

但改写请求生命周期并不只是“把FPM换成协程”。常驻进程意味着对象和状态可能跨请求存活，内存泄漏会从一次请求的问题变成长期运行的问题。扩展如果持有不适合跨请求的资源，也容易出现诡异故障。

因此，php-src近年来对WeakMap、WeakReference、GC改进、请求上下文化API以及Fiber等能力的完善，背后都在服务同一个方向：让PHP运行时适应更复杂的应用生命周期。

5.2 编译阶段：PHP代码不是每次都从头解析

在非CLI场景中，PHP-FPM启动时会加载并执行相关配置。PHP代码进入Worker后，通常不会每次请求都完整经历词法分析、语法分析和编译。

核心组件会检查文件时间戳和缓存状态。源码没有变化时，直接复用之前保存的Opcode数组。发生变化时，再重新编译。

这正是OPcache的价值。它不是简单的“把文件放内存里”，而是把解析和编译成本从请求路径中拿走。部署时常见的“OPcache没开，代码改了也不生效”，就是缓存失效策略与开发工作流发生冲突。

从源码结构看，编译链大致可以分为Tokenizer、Lexer、Parser、AST和Compiler。Parser把源代码转换成抽象语法树，Compiler再把AST降级为Zend Engine能够执行的指令。

这比早期直接解释源代码更灵活。AST可以支撑静态分析工具、代码格式化工具和IDE服务，Opcode则给JIT、可观测性工具和性能分析留下了清晰的中间层。

Opcode还有一个经常被忽视的意义，它把“PHP语义”和“CPU执行细节”隔开了。源码编译器可以针对不同执行方式生成不同指令，而扩展也不必直接和解析器纠缠。

5.3 Zend虚拟机：它更像一台堆栈式机器

Zend Engine并不是把PHP直接编译成x86或ARM机器码。绝大多数情况下，它执行的是Opcode。

常见的Opcode包括变量获取、赋值、加减乘除、函数调用、类型检查、属性访问、数组操作、跳转和返回。它们共同构成PHP的指令集。

执行过程中，Zend Engine维护虚拟机的执行状态，包括当前执行的Opcode、返回值、操作数、函数调用信息、临时变量和异常处理状态。

传统实现大量使用虚拟机栈传递数据。例如调用函数时，参数进入栈，函数返回后结果再从栈中取出。这种设计直观，也方便编译器实现。

但PHP又必须面对对象、引用、闭包、生成器、可变参数和异常等复杂语义。如果所有东西都无差别地压进调用栈，运行开销和实现难度都会迅速上升。

Zend Engine 3之后，底层变量表示、参数传递和调用约定经历过多次优化。源码里大量关于zval、uint32_t、ZEND_CALL_*宏和内存槽位布局的细节，都是在压缩每一次函数调用的成本。

这解释了为什么PHP性能优化经常与C语言优化高度相关。业务代码里一次普通函数调用，看似只是函数语法，背后却涉及参数打包、栈帧管理、临时变量复制、引用计数调整、返回值构造和栈清理。

5.4 zval：PHP变量为什么既方便又昂贵

PHP变量没有编译期固定类型。整数、浮点数、字符串、数组、对象、布尔值和null，可以在运行期间变化。

在Zend Engine 3及之后的实现中，zval本身被设计得更紧凑。基础标量可以直接存放在值槽中，复杂类型通过引用计数指针管理。

ctypedefstruct _zval { zend_value value;uint32_t type_info;} zval;

实际定义会随版本演进，但设计思想很清楚：尽量避免每个变量都额外分配一个完整结构，降低常见标量操作的内存成本。

这里必须纠正一个常见说法。PHP并不是“所有变量都引用计数”。引用计数主要适用于需要共享生命周期的复杂值，标量值可以采用写时复制和更直接的值语义。数组、对象和字符串等结构则通常需要更精细的生命周期管理。

PHP变量赋值背后经常藏着“写时复制”。两个变量指向同一个数组时，并不会立刻复制整份数组。只有其中一个变量真正修改数组，系统才进行分离。

这让PHP代码很自然：

php$data = loadLargeArray();$copy = $data;unset($data);

但它也制造了性能陷阱：

php$copy = $data;$copy['new_key'] = 'value';

这一行可能触发整个大型数组的复制。看似简单的赋值，突然消耗大量CPU和内存。理解PHP源码的人，更容易在业务代码里少制造这种“隐形副本”。

5.5 引用计数与循环垃圾：PHP内存管理最棘手的地方

PHP对象通常带有引用计数。引用计数归零，内存就可以释放。这种方式比依赖一个完整GC周期更及时，也更适合大量短生命周期对象。

问题是循环引用。

php$a = newstdClass();$b = newstdClass();$a->b = $b;$b->a = $a;unset($a, $b);

从外部看，变量已经消失，但对象之间互相持有，引用计数无法归零。这时就需要垃圾回收器识别并回收循环结构。

PHP的GC机制会跟踪可能包含循环引用的容器，定期检查候选对象是否仍然可达。这里的关键不是“发现引用计数不为零就删除”，那会误伤仍在使用的对象，而是要区分外部引用与循环内部引用。

现代PHP不断调整GC缓冲区阈值、容器识别和内存分配策略，原因很现实。GC太积极，会浪费CPU；太保守，则会积累循环垃圾。动态语言的内存问题往往卡在这种平衡上，而不是简单的“有没有释放”。

5.6 字符串与Interned String：重复文本也有成本

PHP字符串使用zend_string结构管理。字符串通常不可变，赋值时会采用写时复制，拼接时再创建新字符串。

为了节省内存，重复出现的字符串、变量名、函数名和部分源码标识符可以驻留。Interned String让多个地方共享同一份内容，并使用额外标记区分驻留字符串。

这能降低常见场景的内存占用，但一旦业务代码不断创建动态字符串，驻留机制帮不上太多忙。日志拼接、模板渲染、大量JSON片段和缓存键，都可能成为字符串分配热点。

PHP源码中的字符串API还会处理二进制安全、NUL字节、哈希计算和内存复制。strlen看起来只是一个函数，背后可能涉及字符串长度缓存；===严格比较字符串时，又可能根据长度和内容选择不同路径。

这类基础操作未必出现在架构图里，却决定了框架的真实性能。Web开发中大量时间花在字符串、数组和哈希表上，而不是复杂算法上。

5.7 数组：PHP最像“高级语言”的数据结构

PHP数组不是简单的键值列表。它本质上有能力同时表达列表、字典、稀疏结构和混合键值。

底层通常使用HashTable管理桶、哈希值和冲突链。对于整数键，可以使用更高效的索引布局；对于字符串键，则需要计算哈希并处理冲突。

这种设计让PHP数组用起来极其顺手：

php$users = ['id' => 1001,'name' => 'Lisi','roles' => ['admin', 'editor'],];

代价是，PHP数组比固定类型语言的数组更重。数组复制、遍历、排序、序列化、递归遍历和JSON编码，都可能产生不可忽视的成本。

更微妙的是，PHP数组的复制与写时复制并不是同一回事。把数组赋给另一个变量时，可能共享底层存储；但把数组作为值语义参数传入某些函数时，调用边界可能要求独立的值副本。

因此，下面这段代码不能想当然：

phpfunctionprocess(array$items){$items[] = 'new';}$items = [];process($items);print_r($items);

函数内部修改的是按值传入的数组，外部$items仍为空。想让函数修改外部变量，可以传引用，也可以明确返回新值。

PHP 8引入了更清晰的类型和函数签名规则，也减少了大量隐式转换带来的意外。但它并没有把所有历史行为一刀切掉，因为兼容性仍然是PHP生态的资产。

5.8 函数调用：扩展接口就是性能边界

用户态PHP函数调用由Zend Engine执行。扩展函数则通过zend_function中的internal_function.handler进入C实现。

一个扩展函数通常要处理参数解析、类型转换、引用参数、返回值和错误信息。写扩展时，最容易踩的坑不是业务逻辑，而是所有权不清晰。

C扩展中，字符串、数组和对象可能需要复制，也可能只能在当前请求期间使用。开发者在接口设计上必须明确参数是否可空、字符串是否以NUL结尾、返回值是否需要复制、对象是否增加引用计数。

错误处理同样棘手。PHP有Exception，也有传统错误机制和Warning。扩展如果直接返回失败，却没有正确设置错误状态，上层代码可能拿到看似合法的错误结果。

这也是为什么一些扩展升级后会出现非常隐蔽的问题。旧扩展的内存错误可能不会立即崩溃，而是破坏堆结构，直到很久以后在完全无关的位置出问题。

5.9 Opcode缓存：PHP-FPM的关键搭档

Opcode缓存与JIT不是一回事。

OPcache主要减少解析和编译成本。JIT则尝试把热点Opcode进一步编译成本地机器码。

对于大量短请求，传统FPM加OPcache往往已经非常有效，因为每个请求执行时间不长，JIT预热和代码缓存带来的收益可能被摊薄。对于长驻Worker、计算密集型任务和高频调用路径，JIT的价值更明显。

PHP 8的JIT支持多种执行模式。它并不是简单地对每个函数生成机器码，而是需要追踪热点、分配编译内存、管理缓存，并在不同路径之间选择是否启用机器码。

这也揭示了JIT的边界。动态语言运行时的类型组合、分支路径和对象形态比静态语言丰富得多。JIT必须保守地保证优化不会破坏语义，还要控制编译代码的体积和缓存成本。

所以，“开了JIT一定更快”并不准确。请求模型、代码热点、扩展函数比例、内存限制和硬件环境都会影响结果。PHP性能调优最可靠的顺序，仍然是先处理慢SQL、缓存、序列化、网络I/O和过度抽象，再考虑JIT。

5.10 异常与Fiber：控制流开始变得更强

异常是PHP 5时代的重要能力，PHP 7又统一了大部分错误处理模型。多数致命错误和类型错误可以抛出异常，错误不再只是写到日志里。

Fiber则把生成器式的暂停能力推进了一步。Fiber可以主动挂起，也可以从外部恢复：

php$fiber = newFiber(function (): void{Fiber::suspend('processing');return'done';});echo$fiber->start();echo$fiber->resume();

它适合表达协作式任务、异步流程和结构化并发，但不会自动把阻塞I/O变成非阻塞。Fiber只是提供挂起与恢复机制，真正的调度策略、事件循环和I/O集成仍需框架或运行时承担。

这正是理解PHP现代演进的关键。PHP语言在不断吸收并发控制结构，但传统SAPI的进程模型并没有被彻底改写。Fiber、事件驱动扩展和常驻Worker可以组合，却不能混为一谈。

5.11 扩展系统：PHP生态真正的护城河

如果只能从php-src里选一个部分解释PHP为何难以替代，我会选扩展系统。

它允许C和C++代码进入PHP运行时，直接操作zval、对象、哈希表、字符串和资源。性能敏感路径可以绕开昂贵的用户态抽象，直接调用底层能力。

PDO把数据库抽象带入PHP，curl接入网络协议，OpenSSL提供加密能力，GD和ImageMagick扩展处理图像 mbstring解决多字节编码问题。Composer生态再把这些能力包装成更高层的库和框架。

扩展接口强大，也非常危险。它深入连接进程内存、请求生命周期和信号处理。普通业务代码的Bug最多影响一次请求，扩展中的内存错误可能直接破坏整个Worker。

更麻烦的是，扩展通常比PHP核心版本更长寿。企业可能几年不升级PHP，却必须继续使用某个只适配旧ABI的扩展。为了兼容性，php-src需要长期维护内部API、函数注册机制和内存模型。

于是，php-src里那些看似“旧”的宏、兼容分支和函数指针，不只是历史怀旧，它们是生态稳定性的价码。

6. 横向比较：PHP的对手不只是另一种语言

把PHP和Node.js、Python、Go或Java比较，不能只比较语法。解释器、运行时、部署模型和生态的边界都不同。

6.1 与Python相比

CPython以简洁语法、强大标准库和科学计算生态见长。PHP在Web开发中更贴近请求处理，拥有更成熟的进程管理方案，也更适合大量传统模板站点。

Python的GIL让多线程执行受到限制，但现代Python生态已经通过子进程、异步框架和解释器实现继续扩展并发能力。PHP则通过FPM进程池、Fiber、事件驱动扩展和异步框架应对类似问题。

PHP通常在纯计算任务上不占优势，但现代PHP的性能已经远非早年印象。实际Web项目中，数据库访问、网络往返和缓存命中率往往比语言基准测试更能决定体验。

PHP的优势是部署成熟，弱点是类型约束、静态分析和大型工程治理仍需要工具补强。

6.2 与Node.js相比

Node.js把JavaScript运行在V8之上，事件循环模型天然适合I/O密集型服务。PHP-FPM则擅长隔离明确的短请求。

Node.js的短板是单进程CPU密集任务容易阻塞事件循环，多进程部署又会增加内存成本。PHP-FPM通过多个Worker分摊CPU，但每个Worker都有独立运行时。

Node.js生态更偏向JavaScript全栈共享，PHP生态更强调语言、模板、框架和扩展之间的组合。Laravel、Symfony等成熟框架为PHP提供了很强的工程约束，这弥补了语言本身在大型项目治理上的不足。

对于高并发I/O，Node.js、Swoole等方案往往更直接。对于大量传统页面、后台系统和已有PHP资产，迁移到Node.js的收益未必覆盖重写成本。

6.3 与Go和Java相比

Go和Java擅长可预测的性能、明确的并发模型和稳定部署，它们在微服务、基础设施和大型分布式系统里更有优势。PHP则更适合快速交付业务功能，尤其是已有庞大Web资产和丰富CMS生态的情况。

Go的静态类型和单二进制部署降低了运维复杂度，Java的JVM生态则在大型企业系统里非常成熟。PHP必须依靠类型声明、静态分析、测试和框架规范，逐步缩小工程可靠性差距。

但反过来看，PHP的学习门槛、动态表达力和快速迭代能力，也有自己的价值。很多业务规则频繁变化，真正昂贵的不是把页面画出来，而是把需求快速验证、调整和上线。

6.4 与HHVM相比

HHVM曾是PHP性能路线上最具威胁的挑战者。它尝试用更强大的JIT和更激进的类型推断提升性能，同时支持Hack语言。

有意思的是，PHP后来走向了相似的方向。PHP 7重做执行引擎，PHP 8加入JIT，类型系统逐步加强。Facebook最终把HHVM定位成更通用的运行时平台，PHP继续以较低迁移成本稳住主流生态。

这说明PHP从来不是拒绝性能，而是不愿以破坏兼容性的方式追求性能。

6.5 与RoadRunner、Swoole等相比

这些工具并不是PHP语言本身的直接竞品，而是在改变PHP应用的运行模型。

RoadRunner利用常驻Worker和Go实现的调度层，减少传统FPM的进程启动成本。Swoole则把事件循环、网络处理和多进程管理带入PHP生态。

它们的优势是常驻进程和低延迟，代价是内存治理、扩展兼容和部署复杂度。传统PHP-FPM并不是“落后”，而是适合请求隔离明确、服务边界清晰的业务。

php-src近期围绕请求上下文化、内存管理、弱引用和Fiber的改进，正是为了缩小传统运行时与现代常驻应用之间的鸿沟。

横向看下来，PHP真正的优势不是每一项都第一，而是组合后的平衡足够好：开发效率高、Web生态成熟、部署路径多、性能可优化、存量代码庞大。

它的不足也同样明确：动态类型的工程风险、C扩展的内存安全、并发模型不统一、语言核心与框架生态之间存在历史包袱。

7. 入门路径：别从读完整个源码开始

php-src体量巨大。试图从头到尾读一遍，多数人会在目录里失去方向。更靠谱的方法，是沿着一条真实执行路径向下钻。

7.1 第一阶段：先跑起来

准备Linux开发环境，编译PHP源码，启用常用扩展。PHP官方镜像和构建系统已经提供了大量便利。

不要只执行make和make install。至少要知道：

• ./configure决定了哪些扩展和系统能力可用
• phpize用于单独构建扩展
• php-config帮助工具定位头文件与库
• 编译器路径、依赖库和运行时目录会影响最终结果

然后用CLI执行最简单的脚本，打开错误输出，观察版本、扩展列表和配置信息。

bashphp -vphp --iniphp -mphp -i

这一步看似基础，却能建立最关键的直觉：PHP不是黑盒，它是可以在本地构建、修改和观察的系统。

7.2 第二阶段：抓住四个核心对象

读php-src时，建议先抓住四个概念：

zval代表变量值，zend_string代表字符串，zend_object代表对象，zend_execute_data代表函数调用与执行上下文。

看懂它们的关系，就看懂了PHP运行时的大部分秘密。

可以重点追踪zend_execute()、execute_ex()、虚拟机循环、参数解析、返回值构造和请求清理。再去看zend_hash、zend_array、zend_refcounted与GC机制。

不要试图一次理解所有宏。Zend Engine源码为了性能、兼容和平台差异使用了大量宏，先把它们还原成普通C语义，再理解优化意图。

7.3 第三阶段：用一个简单脚本观察执行

拿下面这段代码做实验：

php<?phpfunctionadd(int$a, int$b): int{return$a + $b;}$value = add(20, 22);var_dump($value);

逐步研究：