智能指针在大多数现代c++项目中可以替代原始指针，但在特定边界情况下仍需谨慎使用。1. 与第三方库交互时可能需要原始指针，因为许多旧库接口要求传入或返回裸指针，此时可通过get()获取但不可手动delete；2. shared_ptr存在循环引用导致内存泄漏的风险，建议用weak_ptr打破循环；3. 在性能敏感场景下需权衡智能指针的开销，必要时可选用更轻量的手段；4. 自定义删除器虽提升灵活性但也增加复杂度，建议尽量使用默认删除器或保持其简单明了。
智能指针在大多数现代C++项目中确实可以替代原始指针，但在某些边界情况下仍需谨慎使用。
C++引入智能指针（如unique_ptr、shared_ptr和weak_ptr）的初衷就是为了解决内存泄漏、悬空指针等问题。它们通过自动管理资源生命周期，大大提升了代码的安全性和可维护性。然而，这并不意味着我们可以完全抛弃原始指针。
1. 与第三方库交互时可能需要原始指针
很多旧的C或C++库接口设计时并未考虑智能指针，仍然要求传入原始指针或者接受裸指针作为输出参数。比如调用标准C库函数fopen返回的是FILE*，又或者某些图形API要求传入void*类型的缓冲区地址。
在这种情况下，我们通常需要从智能指针获取原始指针：
-
shared_ptr.get()或unique_ptr.get()可以拿到内部指向的对象 - 但要特别注意：不要将这些原始指针用于手动delete，否则会破坏智能指针的管理机制
如果你必须传递一个原始指针给外部API，并且该API可能会保存这个指针（例如注册回调），那你就要格外小心生命周期的问题了。
2. 循环引用导致内存泄漏（shared_ptr常见问题）
shared_ptr通过引用计数来管理对象的生命周期，但如果两个对象互相持有对方的shared_ptr，就会形成循环引用，导致引用计数永远不为0，从而无法释放内存。
举个例子：
struct B;
struct A {
std::shared_ptr<B> b_ptr;
};
struct B {
std::shared_ptr<A> a_ptr;
};这种结构一旦创建出来，A和B之间就形成了强引用环。解决办法是把其中一个改为weak_ptr，因为weak_ptr不会增加引用计数。
所以建议：
- 在涉及对象图结构或多层嵌套引用时，优先考虑是否可能出现循环依赖
- 如果存在潜在风险，及时用
weak_ptr打破循环
3. 性能敏感场景下需权衡开销
虽然智能指针带来的内存安全非常有价值，但它也不是没有代价的。
-
shared_ptr的引用计数操作是原子性的，在多线程环境下会有一定性能损耗 - 频繁创建和销毁
shared_ptr可能导致内存碎片或额外的CPU开销
在对性能极度敏感的代码段，比如高频调用的内层循环、实时渲染引擎、底层网络传输等场景中，有时我们会选择更轻量的手段（比如栈上对象、静态数组或手动管理的原始指针），前提是能确保逻辑清晰、生命周期可控。
当然，这种情况较少，除非你真的遇到了性能瓶颈，否则不建议过早优化而放弃智能指针的优势。
4. 自定义删除器带来灵活性也增加了复杂度
智能指针支持自定义删除器，这是一个非常强大的功能。例如你可以让它管理不是new出来的内存，而是通过mmap分配的区域，或者是某个系统资源（如文件句柄、socket描述符）。
但这也带来了新的复杂性：
- 删除器类型不同会导致
shared_ptr不能赋值给另一个删除器不同的同类型指针 - 如果删除器本身有状态或捕获了上下文，容易引起意外行为
使用时建议：
- 尽量使用默认删除器（即
delete） - 如果必须自定义，保持删除器无状态或简单明了
- 文档化你的删除器逻辑，避免后续维护踩坑
基本上就这些需要留意的地方。智能指针确实是现代C++推荐的主流做法，但在实际开发中还是要根据具体场景灵活判断。
