Flutter使用GetX路由传参是否为最佳实践？对性能内存有何影响？

一、是否属于合理开发实践 #

使用GetX（包括Provider、GoRouter等同类框架）的路由arguments传递实体类数据属于常规且合理的开发实践，但需要注意适用边界：

• 适合传递体积小、生命周期和页面绑定的临时数据，你场景里的单个商品基础信息完全符合使用要求
• 不适合传递超大对象（比如超过几百KB的长列表、完整二进制文件）、全局共享数据，这类数据更适合存放在全局状态管理容器中，路由只传唯一标识（比如商品ID），目标页再从全局容器取数据或者重新发起请求拉取
• 你当前的示例代码存在一个小优化点：没有做类型校验，建议补充显式类型转换，避免后续参数结构调整后出现空安全或者类型异常，调整后参考代码如下：

final s = Get.arguments[0] as Service; // 提前定义好Service实体类的结构和类型

如果想要更高的容错性，也可以做兜底逻辑：路由只传service的id，目标页拿到id后如果发现arguments没有完整数据，再调用接口拉取一次即可。

二、对性能、RAM占用的负面影响 #

正常使用场景下（比如传递单个商品这类小对象）几乎不会产生可感知的负面影响，原因如下：

• GetX的arguments本质是存储在框架内部的缓存容器中，只是对原对象做了一次引用传递，不会额外复制对象占用内存，除非你主动对对象做深拷贝后再传递
• 对应页面销毁后，GetX会自动清理该路由关联的arguments缓存，不会出现内存泄漏问题
• 只有当你传递超大对象、或者连续跳转几十个页面每个都携带超大对象时，才会出现RAM占用过高的问题，这种场景本身就不符合路由传参的使用规范，属于使用方式错误，并非框架设计问题。

补充优化建议 #

如果你传递的商品信息后续可能在多个页面使用，建议把拉取到的商品列表存储在全局的GetX Controller中，路由只传serviceId，目标页拿到id后去Controller里读取对应商品信息，优势如下：

• 路由栈中不会重复存储同一个商品对象的引用，内存占用更低
• 如果商品信息有更新，所有用到的页面可以自动同步，不需要每个页面单独处理更新逻辑
• 避免进程被系统杀掉后重建时，路由arguments丢失导致页面报错的问题（Android后台杀进程、iOS内存不足杀进程的场景下，路由恢复时arguments会丢失，仅传id的话可以重新拉取数据恢复页面）

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