https://stackoverflow.com/questions/44081272/how-to-resolve-lifetime-error-for-mutable-reference-in-rust

这个可能有帮助？

并且你 Foo 那个例子，给 set_i 的 mutable borrow 一个和 foo 一样的生命周期，也会报错，跟你的代码情况一样

因为你 listen_radio() 的 borrow 生命周期和 home_theater 是一样长的，borrow checker 认为你的 mutable borrow 没结束，你调换一下 listen_radio() 和 stop_radio() 的调用顺序就不报错了啊

@wpyfawkes 联动屁股 2 ？

@skygure 额，居然是欧洲国家，在 2 个欧洲国家上过班且在很多国家出过差的表示，看了你前边那个很长的回复，如果我说你去了也没有很大改观呢？当然，还是支持你去看看，Good Luck

@imn1 我就是那么干的

@Ritr 也不一定，提离职涨薪的戏码经常上演，资源有限时肯定优先短期内最需要安抚的人，领导主观的判定这个人虽然重要但是暂时不需要安抚，发现错了再补救

首先我遇到完全一样的情况，领导也说是上边分配的，但是上边连我们人都认不全，楼主也很清楚这是一个台阶，而领导需要一个台阶很明显是因为楼主并不是上边有些人回复的“自认为是骨干“。至于为什么要这么做，看我上一条回复

在某大厂新组建的项目团队，遇到同样的情况，只能说领导并不认为你做的事情是最有价值的，也有可能领导是为了之后的工作铺路，比如我们那个项目凉了之后就只能帮别的组做做杂活，项目启动时需要的技术骨干不是短期安抚目标。