本质是libzip头文件缺失，需安装libzip-devel（centos系）或libzip-dev（debian系），而非手动编译libzip源码，否则易与宝塔内置版本冲突导致运行时错误。
ZipArchive 编译报错 fatal error: zipconf.h: No such file or directory
这个错误本质是 libzip 头文件缺失，不是 PHP 扩展本身的问题。宝塔默认不装 libzip-devel（或 libzip-dev），而 phpize 编译 zip 扩展时必须找到 zipconf.h。
常见表现：执行 make 时直接中断，提示找不到 zipconf.h 或 zip.h。
- CentOS / Rocky / AlmaLinux 系统：运行
yum install -y libzip-devel - Ubuntu / Debian 系统：运行
apt-get install -y libzip-dev - 不要先删系统自带的
libzip—— 新版宝塔依赖它，强行yum remove libzip可能导致面板异常 - 装完后验证：
find /usr -name zipconf.h 2>/dev/null，应返回类似/usr/include/zipconf.h的路径
为什么不能跳过 libzip-devel 直接编译 zip 扩展
zip 扩展不是纯 PHP 代码，它依赖 libzip 库提供的 C 接口。没有 libzip-devel，./configure 就无法生成正确的编译规则，make 必然失败。
你看到的“下载 libzip-1.2.0 源码编译安装”方案，在当前（2026 年）多数宝塔环境里反而容易出问题：
- 手动编译的
libzip默认装到/usr/local，但 PHP 配置可能只认系统路径/usr - 容易和宝塔内置的
libzip冲突，引发undefined symbol: zip_source_buffer_create类运行时错误 -
pkg-config路径没设对的话，./configure会静默忽略 libzip，直到make才报错
确认 zip.so 是否真被加载成功
即使 make install 成功、php.ini 加了 extension = zip.so，也不代表生效。必须验证：
- 检查扩展是否在 PHP 模块列表里：
/www/server/php/73/bin/php -m | grep zip（把73换成你实际版本） - 确认
php.ini路径正确：/www/server/php/73/bin/php --ini，确保写入的是 Loaded Configuration File 对应的那个文件 - 重启服务用
service php-fpm-73 reload，不是restart—— reload 不中断已有请求，更安全 - 写个测试脚本：
<?php var_dump(class_exists('ZipArchive'));，输出bool(true)才算真正可用
PHP 7.3 和 7.4 的 zip 扩展路径差异
路径写错是静默失败的高发原因。宝塔不同 PHP 版本的源码目录不共享，必须严格匹配：
- PHP 7.3：
cd /www/server/php/73/src/ext/zip/ - PHP 7.4：
cd /www/server/php/74/src/ext/zip/ - 别漏掉
/src/ext/zip/这层 —— 宝塔的php-src是解压在/src下的，不是直接放在/ext -
phpize和php-config也必须用对应版本的二进制：/www/server/php/74/bin/phpize，不能混用
最麻烦的点其实是：libzip-devel 装了、路径对了、命令也没敲错，但因为 php.ini 实际加载的是另一个配置文件（比如某个站点单独指定的 ini），导致 extension 行根本没读进去 —— 动手前先 php --ini 看清楚。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
