使用companion object存储Fragment的Bundle是否可行？

技术上你可以把Bundle存在companion object里实现需求，但这是非常糟糕的实践，完全不推荐在正式项目里这么做。

• 生命周期完全不匹配：companion object是全局静态单例，生命周期和整个App进程一致，和Fragment实例完全解绑。如果你同一个Fragment类创建多个实例（比如不同内容的详情页），后创建的实例会直接覆盖companion object里存储的Bundle，先创建的Fragment返回时会读到错误数据，这类问题排查成本极高。
• 内存泄漏风险：Bundle中如果携带大对象、或者间接持有Activity/View引用，当Fragment已经被销毁时，静态区持有的引用会导致相关资源无法被GC回收，积累多了很容易触发OOM。
• 进程恢复场景失效：当App退到后台被系统回收内存后，用户再切回App时，companion object里存储的所有数据都会被清空，此时Fragment恢复时读取空数据很容易直接崩溃，且系统无法帮你自动恢复这部分数据。

你观察到的“跳转其他Fragment再返回，原Fragment数据丢失”，本质是你把数据只存在了Fragment的View生命周期相关的域里——Fragment压入返回栈时，只会销毁View层级（走onDestroyView回调），Fragment实例本身和它的成员变量是完全保留的，根本不需要你在其他Fragment持有Bundle来回传数据：

• 网络请求返回的数据直接存在Fragment自身的成员变量中即可。在onCreateView/onViewCreated渲染时先判断成员变量是否有缓存数据，有就直接渲染，没有才触发网络请求。
• Fragment的初始化参数请始终通过官方的arguments传入，这个Bundle是系统帮你持久化维护的，哪怕进程被杀重建Fragment，arguments里的数据也会自动恢复，不需要你手动在其他页面持有。
• 如果是多个同导航栈Fragment需要共享的数据，使用绑定宿主Activity的共享ViewModel即可，ViewModel的生命周期长于栈内的单个Fragment，返回时数据自然留存，配置变更（比如转屏）时也会自动保留数据，不会有泄漏风险。
• 轻量的UI状态数据可以通过onSaveInstanceState或者Compose中的rememberSaveable存储，系统会在View重建时自动帮你恢复。

额外提醒：除非你要定义全局常量或者静态工具方法，否则不要随便在companion object里存和页面/业务实例相关的状态数据，几乎一定会出问题。

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