用 .memgraph 命令行证据定位并验证 iOS…

当需要抓取或分析 iOS .memgraph、排查内存泄漏、堆增长、持久内存上升、所有权路径或做匹配抓取对比时，用命令行工具建立可复现的寿命边界与所有权证据。

适用场景

解决思路

1. 在抓取前先定义寿命边界：明确哪个对象应当消失、哪个事件结束其有效生命（例如 EditorViewModel 应在关闭编辑器并完成待保存工作后 deinit）。
2. 记录一条确定性流程：1) 启动或恢复已知状态；2) 可选抓取基线图；3) 执行功能流程；4) 跨过预期释放边界；5) 等待合法的异步清理；6) 抓取流程后图。
3. 保持构建、模拟器/设备、数据、Malloc Stack Logging 设置和重复次数稳定；Malloc Stack Logging 会增加分配回溯但带来开销，只能比较相同设置下的运行。
4. 抓取图时不要猜测进程：对运行中的 Simulator 应用使用技能自带脚本，先 mkdir -p /tmp/myapp-memory，再 mkdir /tmp/myapp-memory/run-01（若目录已存在必须失败，重试要用新 run 名），然后运行 python3 scripts/capture_sim_memgraph.py --bundle-id com.example.MyApp --output-dir /tmp/myapp-memory/run-01 --pretty > /tmp/myapp-memory/run-01/capture.json。
5. 当有多个 Simulator 启动时传入 --udid；该脚本只接受唯一精确的 launchd label 和 PID，零个或多个匹配都视为错误；它运行宿主机 leaks --outputGraph 命令，保留 stdout/stderr 并写入 manifest；不要用 pgrep | head -1 或子串匹配替代。
6. 注意抓取会挂起进程，不要用抓取延迟作为性能数据。
7. 保留原始输出并构建有界摘要：用 jq -er 'select(.status == "captured") | .memgraph | select(type == "string" and length > 0)' /tmp/myapp-memory/run-01/capture.json 取出 MEMGRAPH，test -s "$MEMGRAPH" 校验，然后运行 python3 scripts/summarize_memgraph.py "$MEMGRAPH" --artifact-dir /tmp/myapp-memory/run-01/analysis-raw --app-image 'MyApp|MyFeatureKit' --trace-limit 3 --group-by-type --pretty > /tmp/myapp-memory/run-01/analysis.json。
8. 从保留的抓取报告中读取确切的图路径，不要猜测带时间戳的文件名；摘要脚本会创建专用原始产物目录并拒绝复用，运行 leaks --list，只解析其文本的保守子集；--app-image 只标记候选行，不证明所有权；--trace-limit 运行有界的 leaks --traceTree=<address> 查询；当聚合根路径比单个泄漏地址更有用时加 --reference-tree；配合 --group-by-type 时该 reference-tree 查询在同一次调用中分组。
9. leaks 退出状态 0 和 1 仍可分析；主状态大于 1 则摘要失败，可选查询失败会被保留并警告为不可用，但不丢弃有效的主摘要。
10. Apple 未将这些文本格式发布为稳定的机器 schema；把解析警告当作检查原始产物的理由，而不是放宽解析器直到输出想要的答案。
11. 从应用自有的泄漏类型或分配栈开始寻找第一个可操作的边：检查泄漏对象图和 Malloc Stack Logging 回溯（若有）、对引用某地址的对象做有界 --traceTree=<address>、用 --groupByType 压缩重复类型并暴露被保留的负载、当责任地址不明确时用 --referenceTree 做自顶向下视图、以及源码中应用控制的第一个强边。
12. 不可达的自循环在 traceTree 中可能没有活根；此时使用分组泄漏图加源码验证，或把行为缩减为隔离复现；绝不要编造图中不存在的根路径。
13. 当 leaks 为空时调查增长：使用匹配的基线与流程后图，定位增长区域，比较对象类型，再把可疑地址回溯到应用自有的边；证据目标是同一寿命内持续的可达增长，而不是更低的 RSS 或单个大快照；仅在此空泄漏分支加载 references/reachable-growth.md，其中包含有序的 vmmap、heap、leaks、malloc_history 查询及其依赖日志的替代方案。
14. 修复并验证同一寿命：优先采用最窄的所有权修正——断开非预期的强边、取消拥有该对象的工作、移除观察者、限制/驱逐缓存、或在最后一次使用后释放大缓冲区；当引用可能合法变为 nil 时用 weak，只有在证明寿命保证时才用 unowned。
15. 重复完全相同的流程；当同一应用自有类型/路径消失，或可归因于它的前后增长在多次运行中被消除时，修复才成立；仅 RSS 降低、图文件变小或总泄漏数减少不构成证明。
16. 按证据决策：应用类型出现在根循环中时检查两条强边和分配栈；泄漏地址无根时检查分组循环证据并隔离流程；活根保留已关闭功能状态时沿路径找到第一个应用自有的边；零泄漏但 malloc 反复增长时对比基线/流程后堆对象；框架对象占主导时找到应用创建的拥有者、输入或调用频率；增长稳定在已记录边界时先测试驱逐/压力行为再修改。
17. 避免常见错误：因 leaks 一次返回零就宣称无泄漏；从模糊列表中选第一个 PID 或 Simulator；只在对比的一侧启用 Malloc Stack Logging；把解析器尽力而为的类型列当作 API 保证；把巨大的 reference tree 粘进报告却不找应用边；不推理寿命就给每个闭包加 [weak self]；仅凭图大小、RSS 或总数变化就宣称成功而不证明目标寿命和所有权路径。
18. 按审查清单核对：对象和预期释放边界明确；基线与流程后图使用相同构建、运行时目标、数据状态、确定性流程、清理等待、重复次数和 Malloc Stack Logging 设置；Simulator、bundle identifier、进程 label 和 PID 无歧义；原始图和原始命令输出被保留；当前已安装工具帮助确认版本敏感的命​​令形态；泄漏、可达增长、预期缓存和碎片化被区分；发现命名了应用自有类型/分配和可信路径；缺失类型元数据或保守扫描器限制被披露；修复改变了一个所有权/寿命原因；验证重复相同流程和证据查询。

适用边界 · 注意事项

• 当主要任务是交互式 Xcode Memory Graph Debugger 或 Instruments 的图形与分配时间线时，改用 debugging-instruments 技能。
• 仅在运行时证据已定位寿命或路径之后，才用源码审查怀疑闭包捕获；不要一开始就靠源码猜测。
• 不要用 pgrep | head -1 或子串匹配选择进程，也不要在多个 Simulator 启动时不传 --udid。