快速结论
如果 Mac 上的 Google Chrome Helper (Renderer) 占用较多内存，先打开 Chrome 的 更多（⋮）→ 更多工具 → 任务管理器，按 内存 排序，确认任务名称后再处理。先保存相关页面中的工作。
同时查看 活动监视器 → 内存 → 内存压力。单个进程占用很大不等于存在故障，应结合持续压力、卡顿以及相同操作下是否反复增长判断。
找出占用内存的标签页或扩展
第一步：在 Chrome 中确认任务
Chrome 任务管理器会列出页面、子框架、扩展等任务。记下名称与内存读数；需要与活动监视器对应时，右键点击列标题，启用 进程 ID（Process ID）。
PID 代表进程，不与标签页一一对应：多个任务可能共用一个 Renderer，一个标签页也可能使用多个 Renderer。Chrome 与活动监视器的内存统计方式不同，读数不必完全相等。
第二步：保存工作，每次只改一项
不需要的页面应先保存内容，再正常关闭标签页。怀疑扩展时，在 扩展程序 → 管理扩展程序 中禁用它，然后重复原来的操作。
只有明确要终止任务时才使用 结束进程。它可能让标签页显示错误，并不一定关闭标签页；共享该进程的任务也可能受影响，未保存内容可能丢失。
第三步：比较结果
尽量保持其他标签页和应用不变。观察操作后的任务读数、内存压力与流畅度，必要时重复原操作。
| 观察结果 | 下一步 |
|---|---|
| 关闭页面后压力下降、响应改善 | 单独重开该页面，比较相同操作 |
| 多次禁用某扩展后都有改善 | 保持禁用，并检查更新或替代方案 |
| 关闭一个标签页后仍占用较高 | 检查共享进程、其他任务和后台活动 |
| 重复某操作时内存持续增长 | 记录规律进一步调查，不能仅凭趋势确认泄漏 |
Google Chrome Helper (Renderer) 是什么？
Chrome 将浏览器工作分配给多个进程。Renderer 处理网页内容，GPU、网络和其他辅助任务可以在另外的进程中运行。Renderer 并不是所有 Helper 类型的统称。
不存在固定的“一标签页一进程”规则。一个标签页中的框架可能分布在不同 Renderer 中，部分标签页或框架也可能共享 Renderer。应结合任务名称与 PID 判断，不要只数 Helper 行数。参见 Chromium 架构说明。
减少反复出现的内存压力
- 关闭不再使用的高负载页面，禁用不需要的扩展。
- 检查 设置 → 性能 → 内存节省程序（Memory Saver）。符合条件的非活动标签页可以停用，再次访问时重新加载；部分活动会阻止停用，节省量取决于实际任务。
- 更新 Chrome 和相关扩展，再重复相同的检查。
- 如果重启只短暂有效，记录再次引发占用增长的操作。
没有适用于所有网页的内存上限。参见 内存压力与内存泄漏的区别。
什么时候需要 ProcXray？
用 Chrome 任务管理器查任务名称；需要跨浏览器比较进程、检查启动参数或观察重复操作时的资源历史时，再使用 ProcXray。
--type=renderer 等参数能帮助辨别进程类型，但不能可靠地提供标签页标题、URL 或扩展身份。窗口拾取器定位可见窗口所属的应用，不会将浏览器窗口直接对应到某个 Renderer。
截图选中的是 Google Chrome 主进程，PID 1984，而不是下面的 Renderer。图表显示内存短暂上升后回到接近原值。这张已有截图展示的是瞬时变化，不能证明泄漏，也不是修复前后的对比。
Safari 和其他浏览器
Safari 可从活动监视器的内存标签页开始，保存工作后逐个关闭可疑页面；Web Inspector 可用于深入检查某个页面。不要把 Chrome 的任务名称、进程分配方式和菜单照搬到 Safari。
其他 Chromium 浏览器应使用自身任务管理器并核对其文档，菜单路径与可用列可能不同。
常见问题
可以安全结束 Google Chrome Helper 吗？
先确认任务并保存工作。结束 Renderer 可能影响一个或多个页面；结束其他 Helper 可能影响浏览器服务。对不需要的页面，优先正常关闭标签页。
为什么关闭标签页后内存还在增长？
其他任务可能仍在使用该进程，后台工作和缓存也可能保留。用相同任务对比趋势及内存压力；图表能提供调查线索，确认泄漏还需要更多证据。
Safari 一定比 Chrome 省内存吗？
不能一概而论。应在同一台 Mac 上比较相同页面、扩展和操作，并结合响应速度、内存压力，而不是单个进程读数。