内存泄漏是怎么发生的
你有没有遇到过这种情况：电脑用着用着越来越卡，任务管理器里某个程序的内存占用一路飙升，明明只开了一个文档，内存却涨到了几个GB？这很可能就是内存泄漏在作怪。
内存泄漏指的是程序在运行过程中申请了内存空间，但用完后没有正确释放，导致这部分内存一直被占用。时间一长，可用内存越来越少，系统自然就变慢甚至崩溃。
常见引发内存泄漏的场景
比如你在写代码时，频繁创建对象却忘了清理。像在循环中不断 new 一个新对象，却没有引用指向它，垃圾回收机制也无能为力。再比如事件监听没解绑，DOM 元素删了，但绑定的回调还在后台挂着，照样吃内存。
办公软件插件也是重灾区。有些 Excel 插件或浏览器扩展，在加载大量数据后不释放缓存，关掉表格后内存还是不降，这就是典型的泄漏表现。
怎么发现内存泄漏
打开任务管理器或活动监视器，观察目标程序的内存使用曲线。如果长时间运行后内存只增不减，基本可以怀疑有泄漏。开发环境下可以用 Chrome DevTools 的 Memory 面板做快照比对，或者用 Visual Studio、Java 的 JProfiler 这类工具追踪对象分配。
对于 Web 应用，可以在控制台手动触发垃圾回收（仅限测试），然后看内存是否回落。回不去，那就得查代码了。
常见的修复方法
先从代码逻辑入手。检查是否有全局变量无意中保留了大量数据引用。比如本该是局部作用域的对象，却被挂到了 window 或 global 上，生命周期就被无限延长了。
定时器和事件监听要特别注意。用 setInterval 启动的任务，记得在适当时候调用 clearInterval。事件绑定后，页面销毁前必须手动 removeEventListener。
const handler = () => { console.log('tick'); };
setInterval(handler, 1000);
// 销毁时别忘了清掉
// clearInterval(intervalId);
// removeEventListener('click', handler);在使用资源密集型操作时，比如处理大文件或图像，尽量分块处理，处理完立刻置为 null，帮助垃圾回收器识别可回收区域。
语言层面的注意事项
JavaScript 虽然有自动垃圾回收，但闭包用不好就会形成意外引用。Python 中的循环引用也需要 weakref 来辅助清理。C++ 就更不用说了，new 出来的对象必须配对 delete，否则铁定泄漏。
使用智能指针（如 shared_ptr、unique_ptr）能大幅降低出错概率。现代语言设计已经考虑了这些问题，关键是要养成规范习惯。
上线后的监控也不能少
生产环境可以通过 APM 工具（如 Sentry、New Relic）监控内存趋势。设置阈值告警，一旦某服务内存异常增长，立刻通知排查。别等到用户投诉“系统卡死”才去查。
定期重启服务也是一种无奈但有效的兜底手段。比如某些老系统没法彻底修漏，那就每天凌晨自动重启，暂时缓解问题。