为什么项目里会有本地插件
应用可以把平台能力封装成独立 Flutter 插件，再通过本地依赖接入主工程。地图、定位、统计和登录等能力各自维护 Dart 接口与原生实现，避免把平台通道代码散落在业务页面中。
插件清单声明它实现了哪些目标平台。清单只代表工具链能找到对应实现，不意味着插件在每个平台都提供相同功能。主应用的实际依赖也应以根依赖清单为准，避免把示例或测试包误认为运行时依赖。
一次插件调用经过哪些层
Dart 侧可以把一次性命令与持续事件拆开暴露：
const methodChannel = MethodChannel('example/location');
const eventChannel = EventChannel('example/location/events');
Future<void> startUpdates() => methodChannel.invokeMethod<void>('start');
Stream<Map<String, Object?>> get updates => eventChannel
.receiveBroadcastStream()
.map((value) => Map<String, Object?>.from(value as Map));典型路径是：
- 业务层调用 Dart 插件接口.
- 插件 Dart 代码通过 MethodChannel 或 EventChannel 编码参数。
- 平台插件把消息转给原生 SDK。
- 原生回调再转换成 Dart 结果或 Stream 事件。
定位能力就是一个例子：业务控制器监听 Dart Stream；插件负责调用平台定位接口；定位结果回到 Flutter 后，再由应用完成区域解析和状态更新。
逐个平台核对功能实现
插件清单中列出平台，只说明工具链知道该插件有相应实现。每项能力仍要核对目标平台的权限声明、隐私描述、依赖、回调语义、错误码与版本兼容。某插件只声明一个平台时，不能据此推断其他平台也支持相同流程。
本地维护的插件还应记录上游升级差异：改动点、SDK 版本、平台行为和回归设备。这样依赖更新后，才能判断问题来自应用代码、插件桥接还是原生 SDK。
配置和发布检查
SDK Key、回调 Scheme、统计标识和支付参数都属于发布配置。文章或示例不应复制实际值；公开到客户端的 Key 也应配置平台限制，并区分开发、测试和生产环境。
升级插件后，可以按平台列出最小冒烟流程：地图创建、定位授权与失败回调、支付应用返回、统计初始化、冷启动和隐私拒绝路径。插件测试验证通道参数，真机测试验证原生 SDK 与系统权限。
经验总结
MethodChannel/EventChannel 这套 API 我核对过拼写：invokeMethod、receiveBroadcastStream、方法名字符串约定，全都对得上；一次性命令走 MethodChannel、持续事件走 EventChannel 的拆分也是标准做法。“清单声明了平台不等于功能可用”这句是重点——见过插件 pubspec 里写了 ios/android，实际 iOS 侧根本没实现，一调就报 MissingPluginException。本地插件建议建个回归表：每次升级上游 SDK，按平台列最小冒烟项（定位授权、回调语义、错误码），真机跑一遍。通道名建议加统一前缀（比如示例里的 example/），避免和第三方插件撞名。另外插件的版本号要和原生 SDK 版本一起记在 README 里，下次升级时才能一眼看出改动点来自应用代码、桥接层还是原生 SDK，排查方向差很多。
小结
本地插件为平台差异划出清楚边界，也带来持续维护责任。检查时同时看 Dart API、插件平台声明、原生代码和应用清单，并用真实设备验证每个平台，才能判断“支持”实际覆盖哪些功能。