卸载php后php -v仍能运行，说明存在手动编译安装残留（如/usr/local/bin/php）或多个版本共存；需用which php、update-alternatives --list php等定位并清理二进制、配置及环境变量。
卸载 PHP 后 php -v 仍能运行？说明没清干净
Linux（尤其是 Debian/Ubuntu 或 CentOS/RHEL）上用包管理器卸载 PHP，比如 apt remove php 或 yum remove php，往往只删了主包，不碰配置、扩展、二进制软链和用户安装的版本。所以 php -v 还在输出，甚至版本还是旧的——大概率是 /usr/local/bin/php 或 ~/bin/php 这类手动编译安装的残留。
- 先查真实路径：
which php和ls -la $(which php)，看它是不是指向/usr/local/bin/php或某个源码编译路径 - 检查是否多个版本共存：
update-alternatives --list php（Debian/Ubuntu）或alternatives --display php（RHEL/CentOS），有输出就说明系统级切换机制还在管着 -
/etc/php/目录通常不会被包管理器自动删掉，里面全是配置文件，得手动确认是否要保留
删 /usr/local/bin/php 前先确认它是不是你编译装的
很多教程教人直接 make install 装 PHP 到 /usr/local，但没留卸载记录。这时候不能盲目 rm -rf /usr/local/bin/php，万一别的服务（比如某个老旧脚本、自建 CI 工具）依赖这个路径就炸了。
- 用
php --ini看加载的配置路径，如果显示Loaded Configuration File: /usr/local/lib/php.ini，基本坐实是源码安装 - 进源码解压目录（如果你还留着），执行
make uninstall—— 但多数 PHP 版本根本不提供这目标，只能靠make -n install | grep 'cp\|ln'反推装了哪些文件 - 更稳妥的做法：把
/usr/local/bin/php重命名为php.bak，再试运行关键业务脚本；没报错再删
/etc/php/ 和 /var/log/php* 删不删？看你的使用场景
这些目录不是“残留”，而是可能被其他 PHP 实例（比如 Docker 容器、Snap 包、或另一个未卸载的 SAPI）继续读取。直接 rm -rf /etc/php 可能让后续重装 PHP 失败，因为新包会尝试覆盖而非重建配置。
- 如果确定不再用任何 PHP，且没自定义过
php.ini，可以删：rm -rf /etc/php/ /var/log/php* /var/lib/php/sessions/ - 如果只是换版本（比如从 7.4 升 8.2），
/etc/php/7.4可以留着备查，但/etc/php/8.2配置要重新生成，别指望复用 -
/var/lib/php/sessions/权限通常是www-data:www-data或apache:apache，删之前确保 Web 服务已停，否则重启后可能因权限不对导致 session 写失败
macOS 上用 Homebrew 卸载 PHP，brew uninstall php 不等于清零
Homebrew 默认只卸载当前激活的版本（比如 php@8.2），但 php@8.1、php@7.4 这些老版本可能还在 brew list 里躺着，而且 /opt/homebrew/etc/php/ 下的配置不会动，~/.zshrc 里写的 export PATH="/opt/homebrew/bin:$PATH" 也照常生效。
立即学习“PHP免费学习笔记（深入）”；
- 查所有 PHP 相关包：
brew list | grep php，逐个brew uninstall - 删配置前先备份：
mv /opt/homebrew/etc/php ~/php-etc-backup，避免重装时丢失自定义 opcache 或 upload 设置 - 检查 shell 配置：
grep -n 'php' ~/.zshrc ~/.bash_profile，删掉手动加的 PATH 或 alias 行，否则which php还会找到旧二进制
删完记得验证：开个新终端，运行 php -v、which php、php --ini 三连。只要任一命令还能输出，就说明还有东西没动到。这种清理没有“一键到底”的方案，本质是逆向还原当初怎么装上去的。
