在问题出现时连续观察 5 到 10 分钟。确认同一个进程是否持续占用 CPU 或内存、交换空间是否持续增加、磁盘是否长时间繁忙，以及哪个挂载点真正接近用满。load average、已用内存或一次温度读数都不能单独说明原因。
按这个顺序排查
- 1
先确认问题和触发条件
记下问题发生在登录后、打开某个应用后、系统更新、软件包升级、编译、虚拟机或同步任务期间，还是在空闲状态也会出现。短时后台任务结束后自动恢复，不应直接当成故障。
- 2
找出持续占用的进程
在 CoreRobin、系统监视器或 top 中查看进程。如果同一进程连续几分钟占用较高，并且卡顿同时存在，它才更值得关注。优先从应用自身正常退出；不要因为进程名称陌生就结束守护进程或桌面会话组件。
- 3
看可用内存和交换空间
Linux 会利用空闲内存做文件缓存，所以“已用内存很多”通常不等于内存不足。更应关注可用内存是否持续很少、交换空间是否不断增加，以及某个进程的占用是否持续增长。
- 4
确认真正变满的挂载点
根目录、/home、容器数据和外置磁盘可能位于不同文件系统。先查看每个挂载点的可用空间，再扫描对应路径；不要把其他磁盘的空间或目录大小混进系统盘结论。
- 5
重启后复现，再检查最近变化
如果问题重启后回来，检查最近更新的软件包、内核、显卡驱动、桌面扩展、登录启动项和常驻服务。一次只回退或停用一项，并保留恢复方法。
这些数字要放在一起看
它反映一段时间内可运行或等待的任务数量，还要结合 CPU 核心数、进程状态和实际卡顿判断。短时升高可能只是系统正在完成工作。
不同内核、主板和硬件驱动公开的温度来源不同，有些设备不会提供可读传感器。CoreRobin 读取不到可靠数据时会显示“不可用”，不会用估算值替代。
Linux 内核文档说明 /proc/loadavg 提供 1、5、15 分钟负载，/proc/meminfo 中的 MemAvailable 用于估计在不发生交换的情况下还能启动多少应用。 查看 Linux 内核文档
GNOME 系统监视器同样建议按 CPU 或内存排序进程，并结合资源趋势判断。 查看 GNOME 系统监视器指南
按挂载点和路径清理
- 先确认是 /、/home、容器目录还是其他挂载点接近用满。
- 优先检查下载目录、旧安装包、日志、浏览器缓存、虚拟机、容器镜像和回收站，但先确认它们是否仍在使用。
- 卸载软件包应使用发行版的软件管理器；不要手动删除 /usr、/var/lib 或不认识的系统目录。
- 使用 CoreRobin 时先扫描对应路径并查看权限缺口。放入清理篮不会立即删除，永久删除前仍会重新扫描并要求确认。
GNOME 建议先查看文件系统的可用空间，再用磁盘使用分析器定位具体目录；删除后还要清空回收站，空间才会真正释放。 查看 GNOME 存储指南
Linux 版目前是早期预览
Linux 安装包已经通过自动构建和启动检查，但发行版、桌面环境、权限模型和传感器驱动组合很多，实机覆盖仍有限。AppImage 适合直接试用，Deb 包适合 Debian、Ubuntu 及相关发行版；遇到缺失指标时，请连同发行版、内核版本和硬件信息一起反馈。