chatgpt回复你这句：

这个说法在某些上下文中有一定道理，但不能一概而论地说“不要用 shared_ptr”。我们可以拆开来看：

? 这个说法有合理之处：
shared_ptr 确实会造成所有权不清晰

shared_ptr 是共享所有权的智能指针，多个对象都可以持有它的副本，这就使得“谁负责释放资源”变得模糊。

在复杂系统中，很容易出现循环引用（比如 A 拿 B 的 shared_ptr，B 也拿 A 的），导致内存泄漏。

在调试资源生命周期时，shared_ptr 也不如 unique_ptr 直观。

资源生命周期控制复杂

如果滥用 shared_ptr，程序结构就变得像“垃圾回收”，缺乏明确的资源释放时机，降低性能，增加 bug 风险。

某些架构下更推荐组合使用 unique_ptr + 明确责任管理

比如：构造函数注入、工厂模式、RAII 等。

? 但完全说“不要用 shared_ptr”是不合理的：
shared_ptr 设计出来就是为了解决需要多个地方持有资源的场景，比如：

观察者模式：多个观察者都需要访问同一个对象。

资源缓存系统：资源由多个子系统共享，自动引用计数释放。

任务系统/图调度系统：多个任务可能持有对同一资源的引用。

合理使用 shared_ptr 并不会降低代码质量，关键是：

明确其使用目的（必须共享才用，不要用来“偷懒”传对象）

注意避免循环引用（可以用 weak_ptr 打破环）

? 最佳实践建议：

场景    推荐使用
唯一所有权、明确责任    unique_ptr（优先）
需要共享资源    shared_ptr
可能打破循环引用    weak_ptr
短生命周期对象    裸指针或引用传参，不持有

总结一句话：
架构师的出发点是好的，但“完全不用 shared_ptr”是走向另一个极端。关键是 清晰设计所有权语义，而不是完全禁止某种工具。

如果你愿意，可以贴你们项目中遇到的例子，我可以帮你分析这个地方该用什么指针更合适。

【 在 tortelee 的大作中提到: 】
: 我们的架构强烈要求我们不要用sharedptr，因为他导致，所有权不清晰。能不用，就别用。
--
FROM 114.254.115.*