NapCat-docker容器异常宕机问题分析与解决方案

问题现象

在极空间T2设备上部署NapCat 4.5.14 (ARM64)的docker容器时，用户遇到了容器运行一段时间后出现异常宕机的问题。具体表现为：

1. 反向WebSocket无法接收和发送消息
2. WebUI界面无法访问
3. 容器日志无任何错误输出
4. 需要重启容器才能暂时恢复
5. 偶尔重启时也会出现无法启动的情况

环境配置

问题发生的硬件环境为：

• 设备型号：极空间T2
• 内存：4GB
• CPU：Rockchip RK3568 (2.0GHz)
• GPU：Mali G52 (1 Core 2EE@800MHz)

软件环境为：

• NapCat版本：4.5.14 (ARM64架构)
• 容器平台：Docker
• 同时运行Koishi v1.15.0 docker镜像

问题排查过程

初步分析

最初怀疑是NapCat本身的问题，因为：

• 容器表现为无响应状态
• 日志中没有输出任何错误信息
• 需要强制重启才能恢复

深入排查

经过进一步分析发现：

1. 系统资源监控显示CPU使用率异常高
2. 检查相关进程发现Koishi容器启动了多个Chrome实例
3. 这些Chrome实例占用了大量CPU资源
4. 高CPU负载导致NapCat进程被系统终止

根本原因

问题根源在于Koishi v1.15.0 docker镜像存在一个已知bug：

• 该版本会错误地启动两份Chrome进程
• 这些冗余进程会极大地占用CPU资源
• 在资源有限的ARM设备上尤为明显
• 最终导致系统终止NapCat等关键进程

解决方案

临时解决方案

1. 将Koishi容器降级到v1.14.7版本
2. 监控系统资源使用情况
3. 设置容器资源限制

长期建议

1. 对于资源有限的ARM设备，建议：

   • 合理分配容器资源
   • 避免运行多个资源密集型服务
   • 定期检查容器健康状况

2. 对于NapCat部署：

   • 考虑使用有头(headful)版本
   • 或者尝试其他bot协议实现
   • 在资源充足的x86设备上部署

经验总结

1. 容器化部署时，资源监控至关重要
2. 版本兼容性问题在ARM架构上可能表现更明显
3. 多容器环境需要考虑服务间的资源竞争
4. 开源项目的issue跟踪是解决问题的宝贵资源

通过这次问题排查，我们认识到在嵌入式设备上部署多个容器服务时，需要特别注意资源分配和版本兼容性，避免因资源竞争导致关键服务异常。