Flutter中何时使用Shared Preferences？临时业务数据选传参还是持久化存储？

场景方案选择：页面传参 vs Shared Preferences #

该场景优先选择页面传参，不建议使用Shared Preferences存储服务类型，原因如下：

• 你需要留存的服务类型属于单次下单流程内的临时数据，用户完成下单/中途退出流程后数据就自动失效，Shared Preferences是持久化存储方案，定位是存储需要跨App重启、跨多次使用场景留存的数据（比如登录状态、全局主题偏好），如果把临时数据存入Shared Preferences，你还需要额外做清理逻辑，反而容易出现脏数据问题：比如用户中途退出流程，下次进入下单页还残留上一次选择的服务类型，不符合产品预期。
• 页面传参的逻辑更直观，数据生命周期和整个下单流程完全绑定，流程结束销毁页面时数据自动释放，不需要额外维护。你提到的secondScreen("electricity")方式完全适用，如果担心多页面层层透传参数太繁琐，也可以用ModalRoute.of(context)?.settings.arguments做统一路由传参，或者用轻量状态管理方案（如Provider、Riverpod）在流程范围内共享数据，避免层层传参的冗余代码。
• 只有当你需要做体验优化，希望用户下次进入下单页时默认选中上次选择的服务类型时，才需要用到Shared Preferences存储该数据，且需要和流程内的临时传参逻辑配合，不能完全依赖持久化存储做流程内的数据传递。

Shared Preferences最佳使用时机总结 #

• 适合存储：跨App重启需要留存的长期数据（用户登录态、全局主题设置、语言偏好、用户自定义全局配置）、需要跨多个不同业务模块访问的全局配置类数据
• 不适合存储：单次业务流程的临时数据、敏感明文数据（比如密码、用户隐私数据，Shared Preferences为明文存储，敏感数据需用flutter_secure_storage替代）、大量结构化数据（此类数据建议用本地数据库如Isar、Hive存储）

Flutter专业代码开发建议 #

• 路由传参做类型安全封装：不要直接裸传字符串/数字，尽量用实体类封装参数，避免类型不匹配导致的运行时异常：

// 定义参数实体类
class OrderCreateParams {
  final String serviceType;
  final bool isUrgent;
  final String problemDesc;

  OrderCreateParams({
    required this.serviceType,
    this.isUrgent = false,
    this.problemDesc = '',
  });
}
// 跳转时传参
Navigator.of(context).pushNamed(
  '/urgentConfirm',
  arguments: OrderCreateParams(serviceType: 'electricity'),
);
// 目标页面取参数
final params = ModalRoute.of(context)?.settings.arguments as OrderCreateParams;

• 合理控制状态范围：不是所有数据都需要存入全局状态管理，单业务流程内的共享数据可以带自动销毁逻辑的状态管理，比如Riverpod的autoDispose修饰符，流程结束后自动销毁状态，避免内存泄漏和脏数据。
• 持久化操作统一封装：不要直接在业务代码里调用Shared Preferences原生方法，封装成单例工具类统一做数据校验、异常处理，减少重复代码：

class SpUtil {
  static late final SharedPreferences _prefs;
  // App启动时统一初始化
  static Future<void> init() async {
    _prefs = await SharedPreferences.getInstance();
  }
  // 封装对应业务的读写方法
  static Future<bool> saveLastServiceType(String type) => _prefs.setString('last_service_type', type);
  static String? getLastServiceType() => _prefs.getString('last_service_type');
}

// 主函数初始化
void main() async {
  WidgetsFlutterBinding.ensureInitialized();
  await SpUtil.init();
  runApp(const MyApp());
}

• 多步骤流程聚合处理：你提到的多步下单场景可以直接用Stepper组件实现，或者封装在同一个父页面内用PageView切换步骤，所有步骤的数据都存在父页面的状态中，完全不需要跨页面传参，逻辑更聚合，也方便做步骤回退的交互处理。

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