别担心，新手刚接触内存泄漏排查时遇到这种情况太正常了！我来一步步帮你拆解问题，找到后续的方向：

为什么只看到‘：’而不是具体代码？ #

这大概率是**符号化（Symbolication）**的问题——Instruments没办法把内存地址对应到你项目里的具体代码和方法名。解决方法很简单：

• 先检查项目的Build Settings：确保Debug Information Format设置为DWARF with dSYM File（Debug和Release模式都要配置）；
• 运行或归档项目时，不要删除生成的dSYM文件（它和.app包绑定在一起，归档后在~/Library/Developer/Xcode/Archives路径下能找到）；
• 在Instruments里，点击顶部菜单File > Symbols，手动添加你的dSYM文件路径；
• 实在不行，重启Instruments、Xcode甚至你的测试设备，有时候就是小bug导致符号化失败。

系统库（UIKit/CoreFoundation/Malloc Blocks）的泄漏能修复吗？ #

大部分情况下，纯系统库的泄漏不是你的锅——苹果的框架本身很少有内存泄漏，除非是特定版本的系统bug。但很多标注在系统库的泄漏，其实是你的代码错误使用API间接导致的：

• 比如UIKit的泄漏，可能是你没有正确释放UI对象（比如循环引用导致ViewController无法触发deinit），或者没有移除UI相关的通知/观察者；
• CoreFoundation的泄漏，往往是你用了CF开头的对象（比如CFStringCreate、CFArrayRetain），但忘记调用CFRelease来释放；
• Malloc Blocks的泄漏，要看具体是什么类型的块——如果是你自己创建的对象（比如自定义Model、ViewController），那肯定是你的代码有问题；如果是系统内部的块，那可能不用管。

后续排查的具体步骤 #

1. 先搞定符号化，看到自己的代码 #

按照上面的方法解决符号化问题后，勾选Hide System Libraries就能看到你项目里的具体方法了——这是排查的基础，不然根本不知道哪里出问题。

2. 取消Hide System Libraries，看完整调用栈 #

即使系统库的代码你改不了，完整的调用栈能帮你找到“源头”：比如调用栈的最顶部（靠近你的代码部分），哪个方法触发了系统API导致泄漏？比如你在某个按钮点击方法里创建了一个UIView，但没有正确管理它的生命周期，那这个方法就会出现在调用栈里。

3. 排查常见的内存泄漏原因 #

从高频问题入手，逐个排查：

• 循环引用：检查闭包有没有加[weak self]/[unowned self]，delegate属性是不是用weak修饰；
• CF对象未释放：搜索项目里的CFRetain、CFCreate，确保每个创建/保留的CF对象都对应调用了CFRelease；
• 通知/观察者未移除：在deinit方法里，移除所有你添加的NotificationCenter观察者；
• Timer强引用：如果用了Timer.scheduledTimer(withTimeInterval:)，记得用block版本并捕获weak self，或者在合适的时机调用invalidate()；
• 全局缓存/单例：检查全局缓存、单例里是不是持有了大量对象，有没有及时清理的逻辑。

4. 用Xcode的Memory Graph Debugger辅助 #

这是比Instruments更直观的工具：运行项目后，点击Debug栏里的“内存图表”图标（看起来像三个圆圈），就能看到所有存活的对象，点击对象可以查看它的引用链——谁在持有它？找到那个不该持有的引用，问题就解决了。

5. 逐步缩小范围 #

如果泄漏太多，先注释掉部分功能代码，重新运行测试，看泄漏是否消失——这样能快速定位到是哪部分代码导致的问题，再深入排查。

内容的提问来源于stack exchange，提问作者RoshUn