调试时发现两个对象死活不释放内存？
shared_ptr循环引用这个坑多少人踩过。
上周写代码时就遇到struct A和B互相持有对方的shared_ptr，内存直接泄漏。
循环引用简直是shared_ptr的致命陷阱。
两个对象各持有一个指向对方的shared_ptr，引用计数永远降不到零。
资源卡在内存里释放不掉，程序跑久了内存直接爆炸。
网上随便搜一圈全是血泪案例，连2025年7月的新文章还在强调这事。
解决方案其实特简单：把其中一个shared_ptr换成weak_ptr。
weak_ptr不增加引用计数，闭环立马打破。
比如struct B改成weak_ptr指向A，析构时计数正常归零。
用weak_ptr时记得调用lock()获取临时shared_ptr访问对象，安全又省心。
还有个坑是原生指针重复管理。
比如用同一个new出来的指针初始化两个智能指针，一个释放了另一个就变野指针。
2024年就有文章警告过这种骚操作，现在还有人中招。
记住：一个裸指针只交给一个智能指针管。
unique_ptr其实更省心。
独占式管理没循环引用问题，性能开销也小。
非要用共享所有权时再掏shared_ptr。
对了，容器里塞shared_ptr也得小心，对象互相引用照样泄漏。
见过更骚的操作吗？
把this指针直接塞给shared_ptr。
2025年5月的解决方案里明确说要改用enable_shared_from_this，否则分分钟重复析构。
智能指针不是魔法棒，用错了照样崩。
性能敏感场景谨慎点。
shared_ptr维护引用计数肯定比裸指针慢，高频创建销毁时差距明显。
但比起手动管理内存泄漏的风险，这点开销多数情况值得付。
内存安全可比那点纳秒重要多了。
说到底shared_ptr是好东西，但得带着脑子用。
循环引用问题十年如一日地坑人，改个weak_ptr就能解决的事，别头铁硬刚。
写完代码跑个内存检测工具，比熬夜调试强多了。