结构清晰心智模型简单，和压榨性能，有时候就是矛盾的。你说的这个方式，把共享的可变资源搞成独立模块甚至搞到数据库里面去，就会慢啊。在性能敏感的场景下，跑一个东西，也许就是10秒和十分钟的区别呢
【 在 wolfgang (狂云) 的大作中提到: 】
: 标 题: Re: 请教个rust基本问题，Rc<RefCell<T>>有啥坏处？
: 发信站: 水木社区 (Tue Dec 14 10:14:06 2021), 站内
:
: 虽然已经过了好多天，不过我也想参与讨论这个问题。
:
: 依我浅见，虽然楼主关注的重点是Rc<RefCell<T>>，但我却想
: 关注所有权树这个东西。我的看法是，所有权树、&、immutability，
: 这些是好东西，也是螃蟹书想要表达的。它们好就好在，节省心智
: 开销，把复杂性收束在代码的局部。
:
: 如果使用Rc<Refcell<T>>，即便不考虑weak指针循环引用之类的问题，
: 那也是把一定量的数据开放给了大半个项目，乃至开放给了全局，
: 项目的各个部分都有可能访问到各个部分。这样表面上看起来方便，
: 但其实复杂性变大以后就很麻烦了。
:
: immutability是好东西，进而&也要好于&mut。那么如果好几个主体
: 要访问修改同一个东西该怎么办呢？那么它往往就已经不是同一个东西了，
: 可以拷贝成多个“不可变的数据副本”，让多个主体去访问。
: 这样虽然会增大内存开销，但是只要此类数据本体尺寸不大就还是好用的。
:
: 那么如果数据尺寸很大，以及大家都一定要修改同一个核心版本该怎么办
: 呢？这时候实际上就应该用数据库（包括SQL的和non-SQL的）或者消息队
: 列去管理了。
:
: 那么如果这种数据又非常地特殊，只有这个项目的领域知识里存在，该怎
: 么办呢？那么我想，首先其实不能被SQL表达的领域数据是……比较少见
: 的，往往即便有多年经验的老码农，也不见得能真正理解到SQL表达能力
: 的极限。其次，这时候要做的是把项目拆分成好几个进程，其中管理一
: 个“大家都要访问、读写、讲究高频访问效率”的庞大复杂单一核心数
: 据结构，这本身就是一个项目的独立模块，是要能接受连接请求的，连接
: 池之类的技术都要用进去。这才对得起它的复杂程度，而不是仅仅用Rc
: 来“让大家都能访问它”。
:
: 总之，我的看法是，
:
: 1. 正常情况下，使用&。连&mut都要尽量节制。
: 2. 需要共享的数据，应该把不可变的数据作为参数来相互传递
: 3. 对于需要多方访问、修改的复杂数据，使用数据库
: 4. 连数据库都难以表达的核心复杂高性能数据，安排开发一个单独的
: 子项目，作为独立模块进程来管理
:
: 实际上在很多情况下，我就连写java都是这么干的。例如“不可变的
: 数据作为参数来传递”，背后就是data-object的设计模式罢了。
:
:
: 【 在 beep (菜Ｍ.喵星耗子) 的大作中提到: 】
: : 团队正在迁往rust，有两种关于数据结构风格的意见：
: : 1. 按照螃蟹书的风格建议，既然使用了rust，就需要先费心根据需求设计好所有权树，尽量少用Rc<RefCell<T>>，多用&和&mut解决问题
: : 2. 因为业务需求变化不可预测，现在设计的所有权树不一定适应将来的需求，比如一个所有权树的根，将来要变成Rc多个主体拥有，哪个主体先死都不一定，那么现在就尽量多使用Rc<RefCell<T>>，其实就是把rust当作python来用，大部分重要的数据结构变量都进堆，都用Rc保证可
: : ...................
:
: --
: 热二定律比动量守恒更高
: 它告诉我们世界的原初是恨
:
: 爱, 就是对恨的战斗!
:
:
: ※ 修改:·wolfgang 于 Dec 14 11:45:01 2021 修改本文·[FROM: 101.93.22.*]
: ※ 来源:·水木社区 mysmth.net·[FROM: 101.93.22.*]
--
修改:wolfgang FROM 101.93.22.*
FROM 123.120.160.*