编译 PHP 扩展前必须安装三类依赖：PHP 开发包（php-dev 或 php-devel）、构建工具（autoconf/automake/libtool）及扩展特有库（如 libhiredis-dev）；phpize 用于生成匹配目标 PHP 版本的 configure 脚本，需确保其 PHP API 版本与 php -i 一致；configure 须指定 --with-php-config 和必要路径参数；.so 文件须放至 extension_dir 并在 php.ini 中正确启用，注意加载顺序与 ABI 兼容性。
源码编译 PHP 扩展前必须装哪些依赖
缺依赖是编译失败最常见原因，不是“找不到 phpize”就是“configure: error: not found”，本质是开发头文件和构建工具没到位。
以主流 Linux 发行版为例，核心要装三类：
-
php-dev（Debian/Ubuntu）或php-devel（CentOS/RHEL）——提供phpize、php-config和 PHP 内部头文件（如php.h），没它连第一步都走不了 -
autoconf、automake、libtool——PHP 扩展 configure 脚本由 autoconf 生成，缺它们会报autoreconf: command not found - 对应扩展的外部依赖，比如编译
redis扩展需libhiredis-dev（Ubuntu）或hiredis-devel（CentOS）；编译gd需libpng-dev、libjpeg-dev等
phpize 是什么，为什么每次都要用它
phpize 不是编译器，而是为扩展生成 configure 脚本的“预处理器”。它读取当前 PHP 安装路径、ABI 版本、扩展目录位置，确保后续 ./configure 能对上号。
常见误区：用系统自带 PHP 的 phpize 去编译为另一个 PHP（比如自己编译的 PHP 7.4）写的扩展，结果 make install 后 php -m 看不见，或者启动时报 undefined symbol。解决方法只有一个：用目标 PHP 对应的 phpize，通常在 /path/to/php/bin/phpize。
立即学习“PHP免费学习笔记（深入）”；
验证方式：phpize --version 输出的 PHP API 版本（如 20190902）必须和 php -i | grep "PHP API" 一致。
configure 参数怎么选才不翻车
多数扩展默认只启核心功能，但有些选项一漏就直接编译失败，或运行时报错。
-
--with-php-config=/path/to/php/bin/php-config：强制指定配置工具路径，避免找错 PHP 安装；不加可能误用系统 PHP 的头文件 -
--enable-xxx类开关（如--enable-opcache）一般不用手动开，因为 opcache 是内建模块，源码里已存在；但像--enable-redis-igbinary这种需额外支持的就得显式打开 - 路径类参数如
--with-openssl-dir=/usr/local/ssl，当 OpenSSL 不在标准路径时必须指定，否则 configure 通过但运行时报SSL routines:OPENSSL_internal:UNKNOWN_SSL_PROTOCOL
编译完的 .so 文件放哪、怎么加载
执行 make install 后，最终的 .so 文件默认放在 extension_dir 指向的目录（可通过 php -i | grep extension_dir 查）。但只是放对位置还不够：
- 确认
php.ini中已启用extension_dir，且值正确（绝对路径，末尾不加斜杠） - 在
php.ini里加一行extension=redis.so（注意不是完整路径，除非你用extension=/full/path/redis.so） - 如果扩展依赖其他 so（如
igbinary.so必须在redis.so前加载），顺序不能错；ini 中靠前的先加载 - 改完 ini 必须重启 PHP-FPM 或 Apache，
php -m只反映 CLI SAPI，不能代表 Web 环境
最容易被忽略的是 ABI 兼容性：同一个 .so 文件不能跨 PHP 主版本使用（如 PHP 8.1 编译的 mongodb.so 无法在 PHP 8.2 下加载），错误信息通常是 undefined symbol: zend_new_interned_string 这类内部函数名不匹配。
