这几年在 PHP 圈子里最容易被反复拿出来讨论的一个话题就是有国内开发者进入了 PHP 语言的官方开发组。很多人看到这条消息的第一反应是牛逼第二反应是跟我有什么关系。我的看法是关系大了。因为它把一个很模糊的问题摆到了台面上——你写的 PHP 教程、你学的 PHP 知识到底是停留在会用还是已经摸到了引擎这一层。大多数所谓的 PHP 教程讲到框架、讲到 Composer、讲到设计模式就结束了再往下的 Zend 引擎、zval 结构、opcode、扩展开发基本是一片空白。而能不能进入官方开发组拼的恰恰就是这片空白里的东西。这篇内容我打算做两件事一是把PHP 官方开发组这个听起来很遥远的东西拆开讲清楚它的权限模型、晋升路径和真实门槛二是给出一条从写业务代码到能读能改 PHP 内核的实操路线包含具体的代码、编译参数、调试手段和踩坑记录。不管你是刚学 PHP 半年的新手还是写了五六年业务代码的老手下面这些内容里至少有三分之一是你之前没系统接触过的。1. 官方开发组的权限模型比想象中更工程化很多人对加入官方开发组的理解是某种荣誉称号好像是个奖章挂上去就完事了。实际完全不是。PHP 的代码仓库是一个典型的开源协作体它的权限是分层级的每一层级对应的是具体的操作能力和责任范围跟你是不是名人没有半点关系。搞清楚这套模型你才能判断自己离那个位置还差多远以及差的是能力还是流程。1.1 从提交 PR 到拥有合并权限中间隔了什么最底层是普通贡献者。你发现问题、写补丁、提 PR这个阶段任何人都能做不需要申请也不需要介绍人。往上走一层是在某个子系统里积累了足够多的、被合并的高质量提交并且开始参与 code review这时候社区里会有成员认识你、信任你的判断。再往上一层才是拥有提交权限的开发者也就是通常所说的官方开发组成员这个身份一般需要现有成员提名然后经过内部讨论和投票确认。所以整个路径的核心不是考试而是长期、稳定、可被检验的交付记录。我见过不少人卡在第一步就想跳到第三步路径是这样的写了个很大的重构 PR涉及十几个文件然后被 review 打回来一半改了两轮之后人就没影了。这种做法的问题在于大 PR 的评审成本极高维护者要花几个小时甚至几天才能看明白你的意图而他们的时间是被大量 issue 和 PR 稀释过的。真正高效的路径恰恰相反先从一个明确的 bug 修复开始最好是带复现脚本的那种改动控制在几十行以内附上 phpt 测试这样一次 review 的沟通成本很低合并率反而高。提示在 php-src 里提 PR先在 issue 列表里找带 Bug 标签且没有 assignee 的条目成功率比拍脑袋提新功能高一个量级。新功能要走 RFC 流程周期以月计。1.2 应用层熟手和内核贡献者之间的真实差距我用一句话概括这个差距应用层解决的是这段代码怎么写内核层解决的是这段代码在机器上发生了什么。举个最常见的例子$a $b;这一行。应用层的理解是赋值没什么可说的。但如果你知道 PHP 7 之后 zval 是直接内嵌在结构体里的、zend_string是带引用计数并且写时复制的你就会明白这里发生的是引用计数加一而不是内存拷贝也就明白了为什么在循环里对大数组做赋值不会立刻 OOM但如果你在循环里对它做了一次写操作那一瞬间就会触发整个数组的分离复制。这个认知差异会直接体现在你写的代码质量上。我做过一个很典型的重构某段业务逻辑每秒要处理几千次请求里面有个函数把一个大数组作为参数传进来函数内部对数组做了array_shift。从应用层看这个函数只是删除第一个元素没什么成本。但实际每次调用都会触发一次完整的数组复制因为传进来的数组还有别的引用写时复制被触发。把array_shift换成用索引遍历、把结果输出到新的小数组QPS 直接涨了将近四成代码行数还少了两行。下面这张表是我自己总结的用来判断一个人处于哪一层你可以对照看看层级判断标准典型症状应用层会用框架、会写业务逻辑出问题先百度报错信息运行时层理解 GC、引用计数、opcache 机制能解释为什么unset不总是释放内存扩展层能写 C 扩展、能读php-src/ext下的代码遇到段错误会看 core dump内核层理解 zval、HashTable、opcode、VM 执行流程能改引擎行为并跑通全量测试从应用层走到运行时层靠读文档和看博客就够了。从运行时层走到扩展层需要你动手编译一次 PHP、写一个能跑通的扩展。从扩展层到内核层需要你耐着性子读Zend/目录下的源码从zend_execute.c开始。这三道坎每一道都会筛掉大部分人。2. 把 PHP 教程读到能改引擎的程度得补哪几块市面上绝大多数 PHP 教程的结构是一样的变量、类型、运算符、流程控制、函数、数组、面向对象、然后直接跳到框架。这套结构对入门是有效的但它有一个致命的断层——在数组和面向对象之间缺了一整层关于PHP 到底是怎么跑起来的的内容。这个断层不补你写十年业务代码对性能的直觉也建立不起来。2.1 从语法会写到知道每条语句的代价我先给你一个具体的方法拿一个你熟悉的脚本用opcache的调试能力把它编译出来的 opcode 打印出来。在 CLI 环境下可以这样跑php -d opcache.enable_cli1 \ -d opcache.opt_debug_level0x10000 \ -r $arr [3,1,2]; sort($arr); echo implode(,, $arr);你会看到类似ASSIGN,INIT_FCALL,SEND_VAL,DO_FCALL,ECHO这样的指令序列。第一次看会很懵但只要你把每个 opcode 对应到源码语句上两三次之后你就会形成一种读代码时能隐约看到底下指令流的直觉。这种直觉非常值钱因为它让你在写代码的当下就知道哪一行开销大。再往下走一步你要理解zval的结构。PHP 7 之后的核心结构大概长这样struct _zval_struct { zend_value value; /* 8 字节联合体装 int/double/指针 */ union { struct { ZEND_ENDIAN_LOHI_4( zend_uchar type, zend_uchar type_flags, zend_uchar const_flags, zend_uchar reserved) } v; uint32_t type_info; } u1; union { uint32_t var_flags; uint32_t next; uint32_t cache_slot; uint32_t lineno; uint32_t num_args; } u2; };关键点在于zend_value是个联合体整型、浮点、指针共用同一块 8 字节空间类型信息放在u1.v.type里。这就解释了为什么 PHP 7 比 PHP 5 省内存——PHP 5 的 zval 是堆上单独分配的一个变量至少几十字节还带一次内存分配PHP 7 的 zval 直接内嵌在 HashTable 的 bucket 里整数和小字符串都不需要额外分配。理解了这一点你写循环时的思维方式会变。2.2 第一个能编译通过的扩展比想象中短理论讲再多不如跑一遍。写一个最小可用的 PHP 扩展代码量其实很少。先建目录ext/hello写config.m4PHP_ARG_ENABLE([hello], [whether to enable hello support], [AS_HELP_STRING([--enable-hello], [Enable hello support])], [yes]) if test $PHP_HELLO ! no; then PHP_NEW_EXTENSION(hello, hello.c, $ext_shared) fi然后是hello.c#ifdef HAVE_CONFIG_H #include config.h #endif #include php.h PHP_FUNCTION(hello_greet) { zend_string *name; zend_long times 1; ZEND_PARSE_PARAMETERS_START(1, 2) Z_PARAM_STR(name) Z_PARAM_OPTIONAL Z_PARAM_LONG(times) ZEND_PARSE_PARAMETERS_END(); for (zend_long i 0; i times; i) { php_printf(Hello, %s\n, ZSTR_VAL(name)); } } ZEND_BEGIN_ARG_WITH_RETURN_TYPE_INFO_EX(arginfo_hello_greet, 0, 1, IS_VOID, 0) ZEND_ARG_TYPE_INFO(0, name, IS_STRING, 0) ZEND_ARG_TYPE_INFO_WITH_DEFAULT_VALUE(0, times, IS_LONG, 0, 1) ZEND_END_ARG_INFO() static const zend_function_entry hello_functions[] { PHP_FE(hello_greet, arginfo_hello_greet) PHP_FE_END }; zend_module_entry hello_module_entry { STANDARD_MODULE_HEADER, hello, hello_functions, NULL, NULL, NULL, NULL, NULL, 0.1.0, STANDARD_MODULE_PROPERTIES }; #ifdef COMPILE_DL_HELLO ZEND_GET_MODULE(hello) #endif编译方式有两种。如果你想单独编译成 so进入ext/hello目录执行phpize然后./configure --with-php-config$(which php-config)再make。如果想直接编进 PHP 二进制就在 php-src 根目录的configure里加上--enable-hello后重新编译。前一种方式迭代快后一种方式调试方便我一般是先单独编 so 验证逻辑需要 gdb 跟进引擎内部的时候再走整编。跑通之后加一个.phpt测试文件这是提 PR 的必备项--TEST-- hello_greet() 基本调用 --EXTENSIONS-- hello --FILE-- ?php hello_greet(world, 2); ? --EXPECT-- Hello, world Hello, world这三块东西加起来不到一百行但它涵盖了扩展开发的全部核心机制函数注册、参数解析、返回值、模块入口、构建脚本、测试框架。你把这套流程走一遍再回头看ext/standard/下的代码就不会完全陌生了。2.3 读源码的顺序我建议反着来大部分人会建议从main/main.c开始读理由是那是入口。我不这么看。main.c里大量是初始化、配置解析、SAPI 分发对新手来说信息密度太低、关联太散读着读着就迷失了。我的建议是从你最喜欢的那个内置函数倒着读。比如你天天用array_map那就去ext/standard/array.c里找PHP_FUNCTION(array_map)看它怎么解析参数、怎么遍历 HashTable、怎么构造返回值、在异常情况下怎么清理内存。这一路读下来你会自然接触到ZEND_HASH_FOREACH_VAL宏、zend_call_function、array_init_size这些高频 API而且是在一个你完全理解其业务语义的场景下接触的理解成本极低。读完三五个内置函数之后再往Zend/zend_execute.c走去理解ZEND_DO_FCALL怎么找到函数、怎么分配栈帧、怎么执行。最后再回来看main.c那时候你会发现它其实很直白。3. 一个补丁从提交到合入中间要过几道关很多人写好了代码卡在 PR 环节反复被打回最后不了了之。问题往往不在代码本身而在于不了解这个项目的评审偏好和硬性约束。PHP 的评审标准是相当严格的甚至可以说是保守的理解这一点对提高合并率至关重要。3.1 什么改动需要走 RFC什么改动直接提这是个必须先判断的问题判断错了会浪费大量时间。经验法则是改变语言语义、新增语法、修改内置函数的返回值或异常行为、废弃 API这几类必须走 RFC。RFC 是在单独的仓库里写的写完之后要在邮件列表上讨论周期通常不少于两周然后由有投票权的成员投票通过之后才能动代码。反过来纯粹的性能优化、bug 修复、文档完善、测试补充这些直接提 PR 就行不需要 RFC。我在实践中发现一个细节即使是性能优化如果它改变了某个边界情况下的行为比如极值输入、非法参数评审者也会要求你先说清楚这个改变是否可接受。所以提这类 PR 的时候最好在描述里主动把边界情况列出来说明行为没有变化能省掉一轮来回。提示不要在同一个 PR 里混装重构和功能改动。评审者无法区分哪部分是行为不变的整理、哪部分是真正的新逻辑结果就是整个 PR 被搁置。3.2 CI 与向后兼容是两道硬门槛PHP 的 CI 覆盖面很广Linux 各个发行版的基础镜像、Windows 的 MSVC 构建、多个版本的依赖库组合、还有一轮专门跑内存检查的作业。本地能跑通不代表 CI 能过最常见的原因是你在 Linux 上写的代码用了某些只有 GCC 支持的扩展语法MSVC 直接编不过或者你依赖的某个头文件在旧版本系统上没有。我踩过的一个坑是用了__attribute__((unused))在 Linux 上一点问题没有Windows 构建直接报错。解决办法是用 PHP 自己定义的宏在Zend/zend_portability.h里有一整套跨平台的封装写扩展的时候优先用这些不要直接写编译器相关的属性。向后兼容这一条更硬。PHP 有一个明确的版本策略破坏性改动只能进大版本小版本里连某个函数的返回值从 false 变成 null这种改动都不接受。所以你在写补丁的时候凡是涉及返回值、异常类型、参数默认值的地方都要先问一句这个改动会不会让现有的用户代码行为发生变化会的话这个补丁大概率只能等到下一个大版本或者需要加一个开关。3.3 评审里最常被打回的几类问题我整理了下面这张表基本覆盖了新手 PR 的高频翻车点问题类型具体表现修改方式缺少 arginfo新函数没有类型声明PHP 8 下反射拿不到参数信息补ZEND_BEGIN_ARG_*宏缺少测试只有代码没有 phpt在ext/xxx/tests/下补用例含异常分支内存泄漏提前 return 的路径上没释放临时变量统一走goto清理段或用zend_try命名不一致新函数用了驼峰社区惯例是下划线按同文件既有风格命名NEWS 未更新新功能没写变更日志在NEWS对应版本段补一行文档缺失新函数没有对应的 XML 文档在 doc 仓库补一份PR 里关联其中内存泄漏是最容易被 CI 抓到、也最容易被忽略的。PHP 的 CI 里有一轮是带内存检测跑的你的扩展只要有一条提前返回的路径漏了释放就会红。养成每个emalloc都要在脑内配对一次efree的习惯比事后用工具查要高效得多。4. 写扩展时踩过的坑以及怎么把问题钉死这一段是我最想分享的部分因为它是文档里基本不会写、但实际动手一定会遇到的内容。扩展开发的痛苦不在于 C 语言本身而在于你的代码运行在一个有垃圾回收、有引用计数、有异常跳转的宿主环境里任何一次疏忽都可能表现为跑一百次正常第一百零一次段错误。4.1 引用计数为什么你的扩展一压测内存就涨先看一段看起来毫无问题的代码PHP_FUNCTION(concat_twice) { zend_string *s; ZEND_PARSE_PARAMETERS_START(1, 1) Z_PARAM_STR(s) ZEND_PARSE_PARAMETERS_END(); zend_string *tmp zend_string_concat2(ZSTR_VAL(s), ZSTR_LEN(s), ZSTR_VAL(s), ZSTR_LEN(s)); RETURN_STR(tmp); }问题出在RETURN_STR(tmp)上。这个宏在把tmp塞进返回值之后还会对它的引用计数做一次处理而zend_string_concat2返回的是新分配的、引用计数为 1 的字符串。RETURN_STR内部会把返回值初始化成这个字符串但不会替你把那次额外的引用减掉。正确写法是用RETURN_STR(tmp)前先确认这条路径上的所有权语义或者直接用RETVAL_STR(tmp)配合手动递减。这类问题在单次请求里看不出来因为请求结束时内存池整体回收了。但只要在常驻进程环境比如配合某个常驻运行的模式下压测内存就会缓慢爬升非常难抓。我的做法是开发阶段一律用USE_ZEND_ALLOC0关掉 PHP 自己的内存管理器让 valgrind 接管USE_ZEND_ALLOC0 valgrind --leak-checkfull --show-leak-kindsdefinite \ php -d extensionmodules/hello.so /tmp/test.php关掉 Zend 内存池之后所有分配都走系统mallocvalgrind 才能看清每一次分配和释放。这个开关是排查扩展内存问题的第一把钥匙比任何静态分析工具都直接。4.2 参数解析的正确姿势以及几个反直觉的细节ZEND_PARSE_PARAMETERS_START这套宏看起来很简单但里面有几个细节容易翻车。第一个是可选参数的位置Z_PARAM_OPTIONAL之后的所有参数都视为可选如果你把必选参数写在了它后面编译期不报错运行时行为是错的而且错得很隐蔽。第二个是类型宽松Z_PARAM_LONG接受整型但如果你传了个浮点在某些版本下会被静默转换如果你希望严格报错需要配合zend_parse_arg_long的严格模式或者在 arginfo 里声明类型之后依赖引擎层的检查。第三个细节是异常安全。参数解析失败时宏内部会直接return这时候你之前分配的任何资源都泄漏了。所以一个稳妥的写法是把所有分配动作放在参数解析之后解析失败时你手上什么都没有也就不存在清理问题。这个顺序看起来是常识但我 review 过的代码里至少有三成是先分配再解析的。还有一点值得强调PHP 8 之后命名参数和arginfo强绑定。如果你的函数没写arginfo调用方就不能用命名参数调用它而且反射相关的工具链也拿不到参数名。写arginfo的成本就是几行宏但它决定了你的扩展能不能融入现代的 PHP 生态。4.3 段错误的定位链路按这个顺序走段错误最让人头疼的地方是现场消失得太快。我的排查顺序是这样的第一步用调试版本重新编译./configure --enable-debug这一步会把优化等级降下来很多优化导致的假死会直接消失同时ZEND_ASSERT会生效能在更早的位置发现问题。第二步用 gdb 跑gdb --args sapi/cli/php -d extensionmodules/hello.so /tmp/crash.php (gdb) run (gdb) bt full栈回溯出来之后重点看两件事崩溃点在不在你的扩展里以及上一层调用是不是来自 Zend 虚拟机。如果崩溃点在zend_hash_*或者_emalloc里八成是你传了个非法指针或者已经被释放的 zend_string 进去。如果崩溃点在zend_execute里通常是你返回了一个类型和 arginfo 声明不匹配的值。第三步如果 gdb 看不出来就把可疑区域缩到最小。我常用的办法是写一个只调用这一个函数的最小 php 脚本配合十六进制输出把入参和出参都打印出来。段错误有九成是用了已经释放的内存或者越界写破坏了相邻结构把范围缩到一个函数内之后肉眼也能看出来。5. 不同起点的学习路线别走一样的路最后想聊聊路线问题。我见过太多人拿着同一份PHP 进阶路线图从第一页开始啃啃到内核那章就停了。问题不在于毅力而在于路线的起点没有和自己的现状对齐。下面按两种典型情况分别说。5.1 只会写业务代码先把这三件事补上如果你现在的状态是能用框架快速做出功能但说不清为什么这么写更快那你不需要马上碰 C 语言。先把三件事做扎实。第一件是把 PHP 的错误体系和异常体系彻底搞清楚包括各种错误级别在什么情况下触发、set_error_handler的边界在哪、finally和析构的先后顺序。这一块的知识在实际排查线上问题时命中率极高。第二件是把 opcache 和实际部署的关系摸清楚。很多人线上开了 opcache 但从来没看过opcache_get_status()的输出不知道缓存命中率是多少、不知道opcache.max_accelerated_files设小了会怎样、不知道代码更新之后为什么有时候不生效。这些都是很实际的问题搞明白之后你对PHP 是解释型语言所以慢这种说法会有自己的判断。第三件是建立一个性能基线。拿你自己项目里最慢的一个接口用xhprof或者自带的分析工具跑一遍把耗时分布画出来看看时间到底花在数据库、序列化、还是某个循环上。我做过这件事之后最大的收获是很多我以为是PHP 慢的问题实际上是数据库查询没走索引。没有基线就没有优化方向这一条比读十篇内核文章都有用。5.2 想往内核走前三个月该怎么排如果你确定要往深处走我的建议是三个月为一个周期目标和产出都要具体。第一个月把 PHP 从源码编译通过能跑通make test能单独编译一个扩展并加载成功。这个月不需要理解任何原理就是把工具链跑顺把编译不过这类问题全部消灭掉。第二个月选一个子系统把它的代码通读一遍产出一份自己的笔记。我建议从ext/standard/string.c或ext/standard/array.c开始因为这两个文件的函数你天天用语义完全清楚读起来只需要关注它怎么实现的而不是它是干什么的。读完挑一个函数试着做一点小优化哪怕只是把重复的strlen调用提到循环外面然后跑全量测试确认没坏。第三个月去 issue 列表里找一个带复现脚本的 bug修掉它提 PR跟完整个 review 流程。这个月最重要的产出不是那个补丁本身而是你走通了一次完整的协作链路怎么写测试、怎么写变更说明、怎么回应评审意见、CI 红了怎么定位。走通一次之后第二次、第三次的成本会断崖式下降。至于最终能不能走到拥有提交权限那一步说实话这个不完全取决于技术水平还取决于你能不能长期稳定地投入。我个人的观察是能长期留下来的人往往不是因为技术最强而是因为他们找到了一个自己真正关心的子系统愿意持续在上面花时间。技术是可以补的持续投入这件事补不了。最后分享一个我觉得特别有用的小习惯每读一段 php-src 的代码就顺手把它对应的用户态写法写成一个 phpt 测试。这样做有两个好处一是强迫你确认自己真的看懂了行为二是这些测试文件积累下来就是你自己的知识库。我在排查一个数组排序稳定性的问题时就是靠半年前随手写的一个测试文件快速确认了行为边界。这种积累的复利效应比任何速成路线都可靠。