Flutter：如何通过RiverPod实现BackendAPIClass与AppSettingsClass全局访问？

问题描述 #

我编写了AppSettingsClass用于存储应用设置，包含getBackendURL()、setBackendURL()等方法，将backendURL、最近登录用户及访问令牌存储在SharedPreferences中，构造函数需接收SharedPreferences实例为参数。

另有独立的BackendAPIClass处理后端API通信，需读取/修改AppSettingsClass管理的最近登录用户和访问令牌。

应用所有页面需使用BackendAPIClass，部分页面需直接操作AppSettingsClass的值。

想请教：

• 确保所有页面可访问BackendAPIClass的最佳方式是什么？将其实现为Provider是否合理？若可行，哪种RiverPod Provider最适配？
• 若BackendAPIClass作为Provider，如何确保它能访问AppSettingsClass？是将AppSettingsClass也实现为Provider，还是将其作为BackendAPIClass的成员变量更合适？

解决方案 #

一、BackendAPIClass的全局访问方案 #

把BackendAPIClass实现为RiverPod Provider完全合理，这是Flutter中全局共享服务类的标准实践，能让所有页面便捷获取实例，还能自动处理依赖关系。

最适配的RiverPod Provider类型是基础Provider：因为BackendAPIClass是无状态的服务类（核心职责是封装API调用逻辑，本身不需要响应式状态变化，依赖的状态由AppSettingsClass管理）。如果后续BackendAPIClass需要持有可变状态（比如请求加载状态），再换成StateNotifierProvider即可，现阶段基础Provider足够满足需求。

二、BackendAPIClass与AppSettingsClass的依赖处理 #

推荐将AppSettingsClass也实现为RiverPod Provider，让BackendAPIClass的Provider依赖它，原因如下：

• 职责解耦：AppSettingsClass专注本地存储操作，BackendAPIClass专注API通信，各自作为独立Provider，便于单独测试和维护。
• 全局可访问：需要直接操作AppSettingsClass的页面，可直接获取其Provider实例，无需通过BackendAPIClass中转。
• 依赖自动管理：RiverPod会自动处理依赖关系，当AppSettingsClass的实例更新（比如修改了token），BackendAPIClass能随时拿到最新的设置数据。

具体实现示例

1. 先定义SharedPreferences和AppSettingsClass的Provider：

// 初始化SharedPreferences的Provider
final sharedPreferencesProvider = FutureProvider<SharedPreferences>((ref) async {
  return await SharedPreferences.getInstance();
});

// AppSettingsClass的Provider，依赖SharedPreferences
final appSettingsProvider = Provider<AppSettingsClass>((ref) {
  final prefs = ref.watch(sharedPreferencesProvider).requireValue;
  return AppSettingsClass(prefs);
});

2. 定义BackendAPIClass的Provider，依赖AppSettingsClass：

final backendApiProvider = Provider<BackendAPIClass>((ref) {
  final appSettings = ref.watch(appSettingsProvider);
  return BackendAPIClass(appSettings);
});

3. 页面中使用示例：

// 获取BackendAPIClass实例并调用API
final api = ref.watch(backendApiProvider);
api.fetchUserData();

// 直接操作AppSettingsClass
final settings = ref.watch(appSettingsProvider);
settings.setBackendURL("https://new-api.example.com");

不推荐的方案：将AppSettingsClass作为BackendAPIClass的成员变量

这种做法会带来两个问题：

• 耦合度高：需要直接操作AppSettingsClass的页面，只能通过BackendAPIClass间接调用，增加了不必要的依赖。
• 依赖更新不及时：当AppSettingsClass的依赖（比如SharedPreferences）变化时，BackendAPIClass的实例无法自动更新，需手动处理，容易引发错误。

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