最稳妥做法是将 /etc/default/apport 中的 enabled=0，因其仅禁用崩溃收集与弹窗，不影响系统日志及更新机制；删包或停服务易引发依赖冲突或功能异常。
直接改 /etc/default/apport 里的 enabled=0 就能永久禁用弹窗，这是最稳妥、影响最小的做法。删服务或 purge 包反而可能干扰系统更新和日志机制。
为什么改 enabled=0 是首选
Apport 的配置文件 /etc/default/apport 是它的开关中枢。设为 enabled=0 后，它不会收集崩溃数据，也不会触发 UI 弹窗，但底层服务仍存在，不影响其他 systemd 或日志组件运行。
-
sudo service apport stop只是临时停用，重启即恢复 -
sudo apt purge apport会删掉整个包，某些 Ubuntu 版本（如 22.04+）的ubuntu-desktop元包可能依赖它，卸载后下次apt upgrade可能意外重装或报冲突 - 修改配置后无需重启系统，只需确保服务没在运行：
sudo systemctl stop apport（可选，保险起见）
操作步骤：编辑配置并确认生效
终端里执行以下命令即可完成：
sudo nano /etc/default/apport
把文件里这行：
enabled=1
改成：
enabled=0
保存退出（nano 是 Ctrl+O → 回车 → Ctrl+X）。然后手动停一次服务避免残留进程：
sudo systemctl stop apport-
sudo systemctl disable apport（防止未来被其他服务拉起）
不用重启，下次程序崩溃就不会再弹 System program problem detected。
误删 /var/crash/ 文件不能解决问题
有人试过 sudo rm -rf /var/crash/*，确实能清掉旧报告，但只要 Apport 还开着，新崩溃立刻生成新 .crash 文件，并在下次登录时集中弹窗 —— 这就是为什么只清目录治标不治本。
- 清目录适合配合
enabled=0使用，作为收尾清理 - 注意：
/var/crash/下的文件权限通常是root:whoopsie，普通rm可能失败，得加sudo - 某些桌面环境（如 GNOME）还会缓存未上报的崩溃提示，改完配置后建议登出再登录一次
改完后仍有弹窗？检查是否被其他服务激活
极少数情况下，第三方工具（比如某些 Snap 应用、自定义脚本或远程管理工具）会绕过 enabled 设置，直接调用 apport-cli 或写入 /var/crash/。如果改完配置还弹窗：
- 运行
ps aux | grep apport看是否有残留进程 - 检查
systemctl list-unit-files | grep apport，确认状态是disabled而非enabled - 留意是否刚装过开发工具（如
build-essential），某些调试环境会临时启用 Apport
真正麻烦的不是改配置，而是改完忘了 disable 服务或漏了登出刷新——这两个动作不做，弹窗可能隔天又冒出来。
