内存上涨可能来自正常缓存预热，也可能来自对象长期被引用、未释放的资源或任务堆积。直接重启能暂时恢复，却无法说明问题来源。诊断应结合负载与对象生命周期。
先观察增长模式
记录启动、稳定负载、流量下降后的内存变化，以及是否伴随队列和请求积压。工作集、托管堆和容器统计的含义不同，不应把所有内存数值混为一谈。
查找无边界的数据保留
缓存键、静态集合、事件订阅和未完成任务都值得检查。判断数据是否有过期、数量限制和释放路径。对象仍被正常引用时，垃圾回收无法知道业务已经不需要它。
采集诊断数据要控制影响
根据运行环境选择计数器、跟踪或转储，评估数据规模、暂停和敏感信息风险。先在可控环境熟悉流程，避免故障现场临时执行不了解的重型采集。
验收修复后的长期行为
用相同负载与足够观察窗口验证内存趋于可解释状态，同时检查延迟和错误。仅比较重启后一小段时间，不能证明泄漏已经消除。
常见问题：限制容器内存能解决泄漏吗？
限制可以约束影响范围，但可能导致进程被终止；根因仍需通过引用与生命周期分析处理。
技术参考：微软：.NET 与 OpenTelemetry。具体接口与配置请结合使用版本核对。
将评估落实到你的系统
如果你的团队正遇到类似问题，可以从一条关键业务路径开始，整理现状、证据与约束，通过系统架构诊断明确优先级、候选方案和验证范围。