flutter-package-development

Flutter 包开发

将可复用的包视为由独立项目使用的版本化契约。除非用户要求迁移，否则请保留 SDK 版本范围、包架构、支持的平台和发布惯例。

预检

检查 pubspec.yaml、公开导出、示例、测试、平台目录、CI、变更日志和使用方。 选择满足需求的最小方案：

• 对于可复用的纯 Dart 逻辑，使用 Dart 包。
• 对于不含原生代码的可复用组件，使用 Flutter 包。
• 需要原生平台实现时，使用插件或 FFI 包。
• 只有在平台由不同团队独立负责或发布节奏不同，足以证明拆分多个包合理时，才使用联合插件。

不要仅仅因为可以复用代码，就把应用专属桥接代码转换成包。

按需阅读参考资料

• 阅读公开 API 和包质量，了解导出、弃用、语义化版本控制和使用方兼容性。
• 阅读插件和联合插件，了解平台接口、注册、FFI 和联合架构。
• 阅读发布准备，了解试运行检查、pub.dev 清单和发布验证。

职责边界

• flutter-platform-integration 负责应用侧原生代码和底层通道／FFI 机制。
• flutter-dependency-upgrades 负责在应用中升级使用方的包。
• flutter-build-release 负责应用商店和二进制构建，不负责发布 pub 包。

验证

格式化代码、运行分析和测试，并在所有声称支持的平台上运行示例夹具。 如果工作范围包含发布准备：

• 运行 dart pub publish --dry-run，并检查所有输出、警告和包含的文件。试运行通过并不能证明兼容性或已获授权。
• 未经用户明确授权，绝不发布、打标签或创建发行版。附带条件的许可（“如果试运行通过就发布”）不适用于试运行后所做的更改：展示最终差异和试运行结果，然后再询问是否发布。
• 如果缺少工具或仓库访问权限，请提供可执行的审查计划，并明确针对元数据、许可证、变更日志和试运行输出的通过／失败标准，而不要捏造结果。

资料来源

• 开发包和插件
• 发布包
• 包布局惯例