不一定，但强烈建议；选“1”仅卸载面板、保留LNMP环境，选“2”则清除面板及全部运行环境（含MySQL等），且不区分服务是否正在使用，操作前须备份数据并确认依赖关系。
执行 sh bt-uninstall.sh 前必须手动卸载 Nginx/MySQL/PHP 吗？
不一定，但强烈建议。官方脚本选“1”时只删面板，不碰运行环境；选“2”会连带清除 LNMP 组件，但不会区分你是否还在用这些服务——比如你网站正跑在面板装的 MySQL 上，选“2”就直接丢库。
常见错误现象：脚本执行完发现网站打不开、mysql -u root -p 报错拒绝连接、nginx 命令失效。这不是脚本没卸干净，而是你忘了提前导出数据或确认依赖关系。
- 如果只是换管理工具（比如切到 cPanel 或纯命令行），选“1”，再单独停用并卸载各组件
- 如果准备重装系统或彻底清空环境，选“2”，但务必先备份
/www/wwwroot/和数据库 - 脚本不处理 systemd 服务残留（如
bt.service），CentOS 7+/Ubuntu 16.04+ 用户需额外执行：systemctl disable bt && systemctl reset-failed bt
/www 目录为什么总被遗漏？它和宝塔到底什么关系？
/www 是宝塔默认创建的根目录，但不是安装路径的一部分——所有卸载方式（包括官方脚本）都跳过它。里面存着你的网站文件、日志、SSL 证书、备份包，甚至可能有你手动放进去的其他项目。
容易踩的坑：直接 rm -rf /www 会连带删掉你迁走后忘了改路径的站点，或者别人部署的非宝塔应用。更危险的是，有些用户把 MySQL 数据目录软链到 /www/server/data，删 /www 就等于删库。
- 先检查归属：
ls -ld /www看是不是 root:root，再ls -l /www/快速扫一眼有没有wwwroot、backup、server这些典型子目录 - 若确认无业务数据，用
rm -rf /www；若有，至少保留/www/wwwroot和/www/backup，其余可删 - 别忽略
/www/.user.ini和/www/.htaccess，它们可能影响后续 Web 服务行为
定时任务、环境变量、Shell 别名这些隐形残留怎么找？
宝塔安装时会往 crontab -e、/etc/profile、~/.bashrc 里写东西，卸载脚本完全不管这些。它们不会报错，但可能悄悄拉起旧进程、污染 PATH、或让 bt 命令还能敲出来。
典型症状：which bt 仍有输出；env | grep -i bt 返回非空；crontab -l 里还有 */5 * * * * /www/server/panel/pyenv/bin/python 这类行。
- 删定时任务：
crontab -e，删所有含bt、panel、/www/server/的行 - 查环境变量：
grep -r "bt\|panel\|/www" /etc/profile /etc/bash.bashrc ~/.bashrc 2>/dev/null，逐个编辑删除相关 export 行 - 清理 Shell 别名：
grep -r "alias bt=" /etc/profile ~/.bashrc 2>/dev/null，删掉对应行
为什么 ps aux | grep bt 还能看到残留进程？
因为宝塔的 Python 后台进程（panelMain.py、task.py）可能被 systemd 或 supervisord 拉活，也可能你 kill 掉后又被 crontab 重启了。单纯 killall python 不可靠，还可能误杀其他服务。
正确做法是顺藤摸瓜：先看进程树，再定位启动源。别指望一次清完，得配合前面几步一起做。
- 查真实父进程：
ps -ef | grep -E "(bt|panel)"，注意 PID 和 PPID 列 - 若 PPID 是 1，说明被 systemd 托管，查
systemctl list-units --type=service | grep -i bt，然后systemctl stop xxx.service && systemctl disable xxx.service - 若 PPID 是某个 cron 进程，说明定时任务没清理干净，回上一节处理
- 删完记得
kill -9残留 PID，再ps aux | grep -E "(bt|panel)"确认为空
真正麻烦的从来不是卸载命令本身，而是那些散落在 crontab、profile、systemd、进程树里的“幽灵引用”。它们不报错，但会让新装的面板冲突、让 netstat -tlnp 显示奇怪端口、甚至让 reboot 后自动复活。动手前先 ls /www 和 crontab -l 看两眼，比盲目 rm -rf 安全得多。
