Safari 内存占用高，先检查标签页、扩展和具体网站

Safari 排在内存列表前面，不代表它一定出了问题，先记下打开了什么、Mac 用起来有没有卡顿，再一次只改一个标签页或扩展，能重复得到改善才有参考价值，退出所有应用后数字暂时变小，说明不了原因。

把内存数字放回使用场景

Apple 的活动监视器内存指南解释了内存压力、压缩内存和交换空间，在活动监视器的内存页面记下 Safari 相关进程，同时看压力图和 Mac 是否响应顺畅。

空闲内存不是唯一值得看的状态，Apple 也介绍了系统用暂时闲置的内存缓存文件来改善性能，占用高但浏览顺畅，和持续出现压力、操作卡住是不同的现象，图表本身另看内存压力说明。

这些现象都不能直接证明内存泄漏，对比时尽量保持网页、操作和测试时长一致，不拿空闲窗口和正在工作的网页应用比较。

别只看 Safari 这一行

WebKit 架构文档介绍了网页运行在 WebContent 进程中，与应用本身及共享的网络进程分开，所以只看名为 Safari 的一行，可能漏掉一部分占用。

记下活动监视器实际显示的名称，如果某一行显示网站名称，就把它当成线索，与对应页面做对比，不把它当成每个标签页都固定对应一个进程的证明。

测试前先保存可疑网页里没完成的工作，在 Safari 内关掉页面，比直接终止不熟悉的辅助进程更容易做出有意义的对比。

减少标签页，先保留需要的内容

Apple 介绍了关闭单个标签页的方法，从不再需要的页面开始，留下怀疑的网站，重复同一个操作，同时看内存和响应是否变化。

其他 Safari 窗口和使用中的标签页组也要列出来，Apple 的标签页组指南介绍的是整理网页，不是测量内存，不能按一个组里有多少标签页，推断它当前用了多少 RAM。

减少打开的内容后如果有改善，下次只打开当前任务需要的页面，如果单独打开同一个网站就能复现，接下来围绕该网站排查，不去删除无关浏览数据。

分开测试扩展和无痕窗口

Apple 的 Safari 排障步骤包括停用扩展和测试无痕窗口，改动前先记下哪些扩展正在启用，测试结束才知道怎么恢复。

1. 保存工作，在 Safari 浏览器设置里停用扩展，再测试同一个页面。
2. 如果有改善，逐个重新启用扩展，每次都做同样的对比。
3. 另用 Shift-Command-N 打开无痕窗口，测试同一个网站。
4. 测完恢复原来的扩展选择，已经确认有问题的扩展除外。

无痕窗口里变好只是线索，不是诊断结论，登录状态、已存数据和扩展权限都可能不同，先核对这些差别，不直接认定网站已经恢复正常。

Apple 的同一页面介绍了无痕测试有效后，移除受影响网站数据的方法，做之前准备好登录信息，和扩展测试分开进行，磁盘缓存的处理另看浏览器存储指南。

不让标签页一直累积

Apple 当前的标签页设置指南列出了自动关闭标签页的时间，一天、一周或一个月，也可以手动关闭，找设置前先核对指南的版本选择与自己安装的 Safari。

如果当前版本有这个选项，先保存以后还要用的链接，再选时间间隔，改回手动可以停止之后的自动关闭，但找不回已关闭标签页里没保存的工作，找不到选项就手动关闭，不照 iPhone 的设置路径操作。

核对改善是否持续

用同样的网页和扩展选择，再做一次原来的浏览任务，记下卡顿是否回来、涉及哪个网站，以及在类似操作中内存是否持续上涨。

如果始终是一个网站触发，保留这些信息交给网站开发者，Apple 的排障页面也介绍了通过 macOS 更新获取 Safari 更新，换浏览器可以用来对比，但 Chrome 的辅助进程名称和行为另看 Chrome 辅助进程指南。

Mole 在这里能做什么

Mole Mac 状态页的进程列表可以按内存排序，对比应用的内存占用，它会归并能识别所属应用的进程，也包括归属于该应用的 WebKit 进程，因此应用行不是 Safari 标签页列表，改动在 Safari 内做，Mole 用来对比应用层面的内存。

常见问题

Safari 内存高就一定有问题吗？

单个占用数字证明不了故障，结合内存压力、操作是否顺畅，以及同样浏览任务的前后表现，再判断干预有没有帮助。

无痕窗口更流畅，就说明是扩展的问题吗？

不能，网站存储数据和登录状态也可能不同，扩展要单独测试，测完恢复原来的选择。

想减少 RAM 占用，要清 Safari 磁盘缓存吗？

磁盘空间变多不能证明内存问题解决了，先定位页面或扩展，再用同样的任务重新对比。