configure阶段常被误认为快速实则耗时最长，因自动探测库路径和编译器特性；make慢主因是单线程与无增量构建，可用-j并发、ccache缓存及单点构建优化。
configure 阶段耗时长但常被忽略
很多人以为慢在 make，其实 ./configure 阶段就可能卡住几十秒甚至几分钟——尤其启用大量扩展（如 --with-mysqlnd、--enable-opcache）或交叉编译时，它要反复探测系统库路径、头文件版本、编译器特性。这个阶段不输出进度，容易误判为“卡死”。
实操建议：
- 用
./configure --quiet减少日志刷屏干扰判断 - 若明确环境（如已知 OpenSSL 在
/usr/local/ssl），直接加--with-openssl=/usr/local/ssl，避免自动搜索 - 禁用不用的扩展：比如不用 LDAP，就别带
--with-ldap，每个检测项都可能触发一次 pkg-config 或 find 调用
make 编译慢主因是单线程 + 无增量构建
make 默认单核编译，且 PHP 源码中大量 .c 文件依赖公共头（如 php.h），一旦改了头文件，几乎全部重编——没有类似 ccache 的缓存机制，默认就是暴力全量编译。
提速关键点：
立即学习“PHP免费学习笔记（深入）”；
- 强制并发：
make -j$(nproc)（Linux）或make -j$(sysctl -n hw.ncpu)（macOS），但注意内存占用会翻倍，16G 内存下-j8是较稳上限 - 装
ccache并启用：export CC="ccache gcc"，首次仍慢，后续修改源码重编可快 3–5 倍；注意清理缓存用ccache -C，不是make clean - 避免反复
make clean && make：PHP 的make clean会删掉所有 .o 文件，连没改过的也重编；调试阶段优先用make main/php_cli.o && make sapi/cli/php单点构建
换编译器效果有限，Clang 不一定比 GCC 快
GCC 12+ 和 Clang 14+ 在 PHP 这类 C 代码上生成的二进制性能差异通常 php_printf 直接调用）会报错中断，还得加 -Wno-implicit-function-declaration 临时绕过。
真实收益场景极少：
- 仅当你用 LTO（Link Time Optimization）且目标机器 CPU 较新时，Clang +
-flto=thin可能略快于 GCC-flto - 调试体验更好：Clang 错误提示更准，但这是开发效率，不是编译速度
- 别碰 ICC（Intel C++ Compiler）：对 PHP 支持差，configure 经常失败，官方根本不测试
真正影响最终耗时的隐藏环节：test 和 install
很多人只计时到 make 结束，但 make test（运行 1.2w+ 个单元测试）可能比编译还久；make install 若目标路径在 NFS 或慢盘上，cp 大量小文件也会拖慢。
日常开发应跳过它们：
- 确认编译成功后，直接用源码目录下的
sapi/cli/php运行脚本，无需 install - 跑测试用
make test TESTS="tests/basic/001.phpt"指定单个用例，别全量 - 如果非装不可，用
make INSTALL_ROOT=/tmp/staging install先装到内存盘再 rsync，比直装到 /usr/local 快得多
最易被忽略的是 configure 的隐式依赖探测和 make 的头文件敏感性——改一行 main/php.h 就等于让整个 PHP 重编，这不是并发数或编译器能解决的。控制好扩展粒度、善用 ccache、按需构建，比换工具链实在得多。
