单线程无循环数据结构的Rust应用何时需要使用引用计数？

单线程场景下Rc存在不可替代的必需场景 #

排除循环引用、仅简化编码的场景外，仍有不少场景必须使用Rc才能实现合理的架构设计：

• 编译期无法确定资源存活顺序的共享场景：比如UI系统中多个视图组件绑定同一份全局样式配置、渲染管线中多个绘制节点共享同一个纹理资源，这类场景下你根本无法在编译阶段预判哪个持有方最后释放资源，强行用借用+生命周期标注要么过不了编译，要么会给整个代码库引入极其复杂的生命周期约束，后期维护成本陡增，Rc是唯一性价比合理的解决方案。
• 动态生命周期的闭包回调场景：如果你需要把同一份不可变资源传入多个动态注册的事件回调中，这些回调的销毁时机完全由运行时的事件触发逻辑决定，没有办法给所有回调标注统一的生命周期，这种场景下不用Rc根本无法实现资源的合法共享，深拷贝资源的方案在资源体积较大时完全不可行。
• 对资源引用安全性有强要求的场景：不少人会用「全局容器存储资源+索引访问」的方案替代Rc，但这种方案需要你手动维护资源的生命周期，还要额外处理索引越界、悬垂索引的问题，运行时的边界检查开销不一定比Rc低，如果你需要保证资源引用的绝对安全且不想额外写维护逻辑，Rc就是必需的选择。

高阶Rust开发中使用Rc完全不属于反模式 #

社区中“尽量避免使用引用计数”的说法，本质是针对新手遇到生命周期编译错误就无脑套Rc的不良实践，绝非否定Rc本身的价值。

Rust提供的所有权转移、借用、引用计数都是内存管理工具，没有高低级之分，只有适用场景的区别。高阶Rust开发者反而会更合理地使用Rc：在不需要共享所有权的场景优先用借用、所有权转移，在确实存在共享所有权需求的场景不会刻意规避Rc。反过来为了所谓的“更符合Rust最佳实践”硬凹无Rc的代码才是反模式——为了可以忽略的性能损耗强行引入额外的手动内存管理逻辑，不仅会提升bug概率，还会大幅降低代码的可读性和可维护性。
单线程下Rc的计数操作没有原子开销，性能损耗极低，绝大多数场景下完全可以忽略，没必要为了无意义的“纯所有权实现”做过度设计。

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