先把结论放在前面：Fragment 通信方案的历史是一条"从松耦合到紧耦合再回到解耦"的弯路，最终答案只有三个——Fragment Result API 适合一次性结果回传、共享 ViewModel 适合状态共享、事件总线只留给跨模块解耦的场景。这题的考点不在 API 名字，而在你知不知道每种方案把耦合藏到了哪里。这篇围绕Fragment 通信演进展开：先把概念立住，再把机制讲透，最后落到项目里怎么用。一条时间线：五套方案与它们的代价第一代：FragmentToFragment接口回调。宿主 Activity 手工实现接口并分发。这是 2013 年前后的主流，问题立刻出现——通信方必须知道接收方是谁，getActivity() as OnDataReady这种强转满天飞，接口一多就无法维护。第二代：setFragmentResultListener（本质是startActivityForResult的 Fragment 版本）。通信双方通过requestCode字符串配对，由 FragmentManager 暂存结果，在接收方回到STARTED时才投递。这个设计有两个关键性质值得讲：结果在接收方不可见时会被暂存而不是丢弃、结果只投递一次。它奠