我已经学到了许多技巧，可以在不使用的情况下“摆脱” Rust的限制unsafe。例如：
Option::unwrapRefCell可能还有其他我忘记的事情。
在这种情况下，对正确性的特定方面的责任从编译器转移到程序员。那些本应是编译错误的事情变得很恐慌，程序员应该只是“知道他们的逻辑是正确的”。
紧急情况比破坏内存更好，但是考虑到Rust的品牌是一种完全安全的语言，我认为这些“陷阱门”将以某种方式（在类型系统，文档或其他方式中）进行正式识别，以便于识别。程序员应该知道何时使用快捷方式并承担额外的责任。
是否存在这种区别？甚至只是文档中某处的明确列表？我的思维模式是否错误，使这种事情变得不必要了？
不，没有正式的区别。
相信您在问是否有效果系统。尽管编译器开发人员已经讨论了一段时间，但从长远来看，这是否真正是有益的还是有害的尚无共识。
“绕开” Rust的限制
这些“无处可逃”。这些方法本身可以确保满足要求。
从编译器转移到程序员
我不同意这种评估。责任已经从编译时间转移到了运行时间，但是编译器和库代码仍然确保维护安全性。
使用
unsafe
不安全的代码确实将责任转移给了程序员。但是，该程序员将构建其他程序员可以使用的安全抽象。理想情况下，它们使用在编译时检查的工具来构建抽象，从而有助于减少运行时错误。
Rust的品牌是一种完全安全的语言
对正确性的特定方面负责
是的，Rust打算成为一种内存安全的语言，这并不意味着用Rust编写的代码是正确的。品牌强调记忆安全性；其他人则认为这意味着“无法崩溃”之类的事情，但是我们不能阻止所有错误的解释。
也可以看看：