composer clear-cache 不清除 PHP 扩展编译缓存，仅清理 ~/.composer/cache（或 %APPDATA%\Composer\Cache）下的 files/、repo/、vcs/ 目录；PHP 扩展编译产物（如 .o、.lo 文件）需进入源码目录手动清理，或执行 make distclean、git clean -xdf；APCu 运行时缓存须重启 PHP-FPM 或调用 apcu_clear_cache()；临时解压目录（sys_get_temp_dir()）也不受 clear-cache 影响，需单独清理。
Composer 本身不管理 PHP 扩展的编译缓存
你运行 composer clear-cache 或 composer cache-clear，它只动 ~/.composer/cache（或 %APPDATA%\Composer\Cache）下的 files/、repo/、vcs/ 目录，和 PHP 扩展的编译产物完全无关。PHP 扩展（比如 redis.so、igbinary.so）的编译缓存由构建工具链控制：通常是 phpize + ./configure + make 过程中产生的 .o、.lo、.libs/ 等中间文件，存在源码目录里，Composer 根本看不见。
清理 PHP 扩展编译缓存得进源码目录手动操作
如果你从源码编译过某个扩展（如 pecl install redis 底层也是走这一套），它的编译残留通常在扩展源码根目录下。常见位置和清理方式：
- 删掉整个构建目录：
rm -rf ./modules ./libs ./build/ .libs/ *.o *.lo *.la config.status config.log - 重置 configure 状态：
./buildconf --force（需有autoconf）再删config.h和config.cache - 最稳妥的方式是重新解压原始 tar 包，或
git clean -xdf（如果用 git 克隆的源码）
注意：make clean 通常只清 .o，不删 config.h 或 config.status，改了 --with-xxx 参数后直接 make 可能沿用旧配置——必须 make distclean 或彻底重来。
APCu 缓存类映射不是“编译缓存”，但容易被混淆
有些用户把 "apcu-autoloader": true 生成的 APCu 键值当作“扩展缓存”。这不是编译产物，而是运行时缓存，清理方式是：
- 重启 Web 服务器（
systemctl restart php-fpm或apache2） - 或调用
apcu_clear_cache()（需在 PHP 脚本中执行，且 APCu 配置允许 CLI 访问） -
composer dump-autoload --apcu不会清 APCu，只是重新生成映射并写入 APCu
这类缓存跟扩展编译过程无关，也无需进源码目录操作。
真正要查的是 /tmp 或 sys_get_temp_dir() 下的临时 ZIP
Composer 下载包时会把 .zip 解压到系统临时目录（sys_get_temp_dir()），路径类似 /tmp/composer_abc123/ 或 C:\Users\XXX\AppData\Local\Temp\composer_xyz789\。这些目录不会被 clear-cache 清理，但可能堆积大量残留解压内容，尤其在 CI/CD 失败后。
- 查位置：
php -r "echo sys_get_temp_dir();" - Linux/macOS 清理：
find $(php -r "echo sys_get_temp_dir();") -name 'composer_*' -type d -mtime +7 -exec rm -rf {} + - Windows 建议用
forfiles或 PowerShell 筛选日期后删除，避免误删其他临时文件
这个目录里的内容最接近“指定模块相关临时产物”，但它仍是 Composer 下载解压阶段的副产品，不是 PHP 扩展本身的编译缓存。
