OpenDTU项目中的内存泄漏问题分析与修复

问题背景

OpenDTU是一个用于太阳能逆变器监控的开源项目，近期在版本24.9.27中出现了严重的稳定性问题。用户报告设备会每隔约10分钟自动重启，导致累计发电量计数器丢失。经过分析，这个问题与WebSocket认证机制的内存泄漏有关。

问题现象

多位用户观察到以下现象：

1. 设备运行约10分钟后自动重启
2. 重启后累计发电量计数器归零
3. 系统可用内存(heap)随时间持续下降
4. 问题在24.5.6版本不存在，从24.9.26版本开始出现

技术分析

根本原因

问题源于ESPAsyncWebServer库的认证机制变更。在最新版本中，该库引入了Middleware架构来改进性能和内存使用，但OpenDTU的WebSocket认证实现方式未相应更新。

具体来说，当"Allow anonymous readonly access"选项关闭时，系统会不断调用setAuthentication()方法。该方法每次都会创建一个新的AuthenticationMiddleware实例并添加到处理链中，但旧的实例不会被移除。随着时间推移，这些不断累积的Middleware实例会耗尽系统内存，最终导致设备崩溃重启。

内存泄漏机制

每次调用setAuthentication()时：

1. 创建新的AuthenticationMiddleware对象
2. 设置用户名和密码
3. 将Middleware添加到WebSocket处理器
4. 标记为自动释放(_freeOnRemoval=true)

虽然理论上这些Middleware在处理完请求后会被释放，但由于WebSocket是持久连接，它们实际上会一直存在，导致内存持续减少。

解决方案

修复方法

正确的实现应遵循以下原则：

1. 使用单一的AuthenticationMiddleware实例
2. 根据配置动态添加或移除该Middleware
3. 避免重复创建Middleware对象

具体实现要点：

• 将Middleware实例作为类成员变量
• 在配置变更时调用addMiddleware()或removeMiddleware()
• 使用事件驱动方式响应配置变化，而非周期性检查

认证方式改进

修复过程中还发现认证方式可以从BASIC升级到更安全的DIGEST：

• BASIC认证：简单base64编码的"用户名:密码"
• DIGEST认证：使用MD5哈希的"用户名:域:密码"

虽然DIGEST认证计算开销略大，但它能防止密码被简单嗅探，提高了安全性。系统保持了向后兼容，仍会接受BASIC认证请求。

影响范围

该问题影响所有使用以下配置的用户：

• 运行24.9.26及以上版本
• "Allow anonymous readonly access"选项关闭
• 使用WebSocket功能(如Live View)

临时解决方案是启用"Allow anonymous readonly access"选项，完全解决方案是应用修复补丁。

技术启示

这个案例展示了几个重要的嵌入式开发经验：

1. Middleware架构：理解中间件模式及其生命周期管理至关重要
2. 内存管理：在资源受限设备上必须谨慎处理动态内存分配
3. 兼容性考虑：安全升级需要平衡新旧标准的兼容性
4. 监控机制：系统应包含内存使用监控和预警功能

通过这次问题的分析和解决，OpenDTU项目在Web安全认证和内存管理方面都得到了显著提升。