尧图网站建设 
Flower Hub 应用发布完全指南从 pyproject.toml 元数据到flwr app publish实战【免费下载链接】flowerFlower: A Friendly Federated AI Framework项目地址: https://gitcode.com/GitHub_Trending/flo/flower本指南以 Flower 框架官方的《Publish an App on Flower Hub》How-to 文档为主体结合当前仓库中flwr app publish命令的真实实现源码系统讲解如何把一个联邦学习应用Federated App发布到 Flower Hub。你将掌握Simulation 与 Deployment 双运行时的应用兼容写法、pyproject.toml元数据与 FAB 格式版本fab-format-version的配置规则、发布时的文件收集/过滤/校验机制以及从注册账号、flwr login supergrid到flwr app publish的完整发布流程。Flower Hub 发布什么Project 与 FAB 的关系Flower Hub 是 Flower 框架的联邦 AI 应用分发平台支持应用的发现、分发、运行与去中心化验证。当你运行flwr app publish时上传的是你的完整项目project源码而不是预先构建好的.fab文件Flower Hub 会在服务端根据上传内容构建 FABFlower App Bundle。源码中可以看到这一逻辑的直接实现flwr app publish通过 multipart 请求把每个文件逐个 POST 到${FLWR_SUPERGRID_API_URL}/hub/apps/publish端点并在请求体中附带flwr_version元数据见 publish.py。这意味着两类内容需要分清Project发布物完整源码包含.gitignore、.editorconfig等开发环境文件供他人浏览、克隆和在此基础上二次开发是事实来源source of truthFAB运行时产物从 project 派生出的运行时优化子集用于一次联邦训练/推理任务。另外注意flwr app publish的上传过滤规则与flwr build的 FAB 打包规则相关但不完全相同二者分别由发布校验和服务端构建两套逻辑把关。第一步构建一个可发布的应用同时兼容 Simulation 与 Deployment 双运行时你的应用应当在不修改任何代码的前提下同时运行于 Simulation仿真与 Deployment部署两种运行时。实现方式是把数据加载逻辑按模式区分而训练逻辑保持完全一致。推荐的模式判断方法是读取context.node_config如果其中同时存在partition-id和num-partitions两个键说明应用运行在 Simulation 模式否则为 Deployment 模式。官方文档给出的标准写法如下app.train() def train(msg: Message, context: Context): Train the model on local data. batch_size context.run_config[batch-size] if ( partition-id in context.node_config and num-partitions in context.node_config ): # Simulation Engine: partition data on the fly partition_id context.node_config[partition-id] num_partitions context.node_config[num-partitions] trainloader, _ load_sim_data( partition_id, num_partitions, batch_size ) else: # Deployment Engine: load demo or real user data data_path context.node_config[data-path] trainloader, _ load_local_data(data_path, batch_size) # Training logic continues identically for both modes仓库内的真实示例与这一写法完全一致例如 quickstart-pytorch 的 client_app.py 同样从context.node_config读取partition-id与num-partitions进行数据分区。配套的数据准备建议Simulation 模式使用 Flower Datasets 在运行时动态切分数据Deployment 模式使用 CLI 命令flwr-datasets create生成演示数据参见仓库中 datasets 目录下 flwr-datasets 的 CLI 实现若应用依赖外部提供的数据则需在 README 中说明获取方式与格式要求。README 必须写清楚的内容应用 README 应明确记录Simulation预期需要多少个虚拟 SuperNode以及是否需要修改 Flower ConfigurationDeployment如何使用flwr-datasets create生成合成数据若依赖外部数据说明用户如何获取以及数据格式要求。第二步完善应用元数据pyproject.toml发布前应用的元数据必须完整且准确。元数据定义在pyproject.toml中Flower Hub 会用它来展示和标识你的应用。[project] 段的必需字段字段说明name应用唯一名称。必须以字母开头且只能包含字母、数字和连字符version当前发布版本号description应用的简短摘要发布时源码会校验其非空且不超过 200 字符见 publish.pylicense适用的软件许可证[tool.flwr.app] 段的字段字段说明publisher你的 Flower 账号用户名必须与账号一致fab-format-version可选省略时默认为0flwr-version-target仅当fab-format-version 1时必填完整示例来自官方文档[project] name my-federated-app version 0.1.0 description Federated training for medical image classification. license { file LICENSE } dependencies [flwr1.28.0] [tool.flwr.app] publisher your-username # Must match your Flower account username fab-format-version 1 flwr-version-target 1.28.0仓库中一个真实发布应用的配置可作为参考见 hub/apps/quickstart-pytorch/pyproject.toml它声明了publisher flwrlabs、fab-format-version 1、flwr-version-target 1.37.0并通过[tool.flwr.app.components]与[tool.flwr.app.config]补充了运行组件与默认超参数。license 字段的三种合法格式Flower Hub 接受以下形式的[project].license# SPDX identifier (string) license Apache-2.0 # Inline text license { text Apache-2.0 } # File reference (must be at the project root) license { file LICENSE } # or license { file LICENSE.md }规则如下file与text不能同时设置若使用license.file文件名必须是LICENSE或LICENSE.md源码常量APP_PUBLISH_ALLOWED_LICENSE_FILES (LICENSE, LICENSE.md)明确定义见 constant.py引用的许可证文件必须真实存在且包含在flwr app publish上传的文件集合中。源码会在上传前逐一校验file与text冲突、文件名不合法、文件不存在、被.gitignore或排除规则过滤掉都会直接抛出错误终止发布见 publish.py。兼容性说明对 legacy 应用Flower Hub 仍接受字符串与内联文本形式的 license但对于fab-format-version 1必须使用license { file LICENSE }或license { file LICENSE.md }。⚠️ 特别注意name与description会在 Flower Hub 上公开展示应确保清晰、描述性强、便于发现其中name在首次发布后不可修改发布前务必确认最终名称。第三步理解 FAB 格式版本fab-format-versionfab-format-version在[tool.flwr.app]中声明它定义了构建 FAB 时适用哪些构建期规则使 Flower 可以在不破坏 legacy 应用的前提下演进 FAB 格式同时允许新应用通过声明更新的格式版本启用新能力。详细机制可参见仓库中的 fab-format-version.rst。Flower 当前识别以下两种版本缺失fab-format-version或 0legacy 行为不强制要求新版字段如果应用在flwr依赖中声明了可用的闭区间下界如flwr1.28.0Flower 可以推导出最低 Flower 版本供 Flower Hub 在发布时使用fab-format-version 1严格校验对 Flower 版本兼容性与许可证文件处理做严格校验。版本 1 的强制要求对于fab-format-version 1应用必须声明[project].dependencies中的flwr依赖且使用形式的闭区间下界例如flwr1.28.0[tool.flwr.app]中的flwr-version-target根目录级许可证文件引用[project].license.file且该文件必须包含在最终 FAB 中。最小 Flower 版本由flwr依赖的闭区间下界推导得出例如dependencies [flwr1.28.0]推导出最小版本1.28.0。目标 Flower 版本flwr-version-target标识应用预期面向的 Flower 版本必须大于或等于推导出的最小版本。例如[tool.flwr.app] fab-format-version 1 flwr-version-target 1.28.1Flower Hub 如何使用这些元数据发布时服务端构建 FAB 会校验声明的格式版本并推导兼容性元数据这影响两个用户侧流程flwr app publish非法的 FAB 格式声明会在发布时直接失败flwr new publisher/app与flwr run publisher/appHub 会先依据应用的兼容性元数据拒绝不兼容的 Flower 版本再下载与运行应用参见 how-to-use-app-from-hub.rst。第四步理解发布时哪些文件会被上传flwr app publish会从应用目录收集文件、过滤、校验最后才向 Flower Hub 发送。整个流程的实现位于 publish.py可分为三个阶段。收集文件Flower 递归遍历应用目录不跟随符号链接源码中os.walk以followlinksFalse遍历并跳过 symlink 文件见 utils.py。深度超过10 个目录层级的文件不会被收集MAX_DIR_DEPTH 10见 constant.py超深会抛出AppPathDepthError并提示通过.gitignore排除无关文件。过滤文件允许的文件类型APP_PUBLISH_INCLUDE_PATTERNS定义于 constant.py**/*.py Python source files **/*.toml TOML configuration files **/*.md Markdown documentation **/*.yaml YAML configuration files **/*.yml YAML configuration files (alternate extension) **/*.json JSON data files **/*.jsonl JSON Lines data files /.gitignore Root-level gitignore file **/.editorconfig Editor configuration files /LICENSE Root-level license file /LICENSE.md Root-level license file (Markdown)始终排除的路径APP_PUBLISH_EXCLUDE_PATTERNS.flwr/** Flower internal directory .venv/** **/__pycache__/** Python bytecode cache类型过滤之后还会应用你的.gitignore规则。任何在这一阶段被丢弃的文件都会打印警告让你清楚看到哪些内容被排除源码中通过Skip: path黄色警告逐条输出见 publish.py。整个过滤管线在 filter_paths_for_publish 中实现先匹配 include 规则再取反匹配 exclude 与 gitignore 规则。校验文件集就绪后Flower 先检查每个文件是否为合法 UTF-8再验证文件数量最多1,000 个MAX_FILE_COUNT单文件不超过1 MBMAX_FILE_BYTES总大小不超过10 MBMAX_TOTAL_BYTES。以上常量均在 constant.py 中定义。全部通过后会输出✅ Validation passed以及文件数与总字节数任一检查失败都会在发送前抛出错误并中止发布。此外如果过滤后没有任何文件匹配同样会报错终止Nothing to upload。第五步创建 Flower 账号在 flower.ai 官网右上角点击Sign Up并按照指引注册。务必保证注册的用户名与pyproject.toml中[tool.flwr.app].publisher定义的用户名一致。以组织名义发布官方组织账号尚未正式支持当前做法是创建标准用户账号用组织名称作为用户名例如flwrlabs在个人资料中更新对应的 Logo 与描述。官方说明组织账号在正式支持推出后将会迁移。第六步登录并发布安装 Flower CLIpip install flwr登录 SuperGridflwr login supergrid该命令会打开浏览器窗口用你的 Flower 账号完成身份认证。要登录 SuperGrid预期你的 Flower Configuration 中存在一个名为superlink.supergrid、地址为api.flower.ai的 SuperLink 连接——安装 Flower 后默认应已存在。源码中还隐含一条安全约束登录要求启用 TLS若连接配置中insecure被设置为trueflwr login会直接拒绝见 login.py。发布应用flwr app publish your-app-pathflwr app publish上传的是项目文件源码 元数据而非预构建的.fab文件Flower Hub 在服务端根据上传内容构建 FAB。若应用使用fab-format-version 1服务端构建时会校验 Flower 版本元数据与许可证文件要求。发布成功后源码会输出绿色提示 Upload successful见 publish.py。查看你的应用发布完成后你的应用将出现在https://flower.ai/apps/account_name/app_name/发布后申请可信审查如果你希望应用发布后由可信审查者验证参见 how-to-sign-hub-apps.rst。发布新版本已发布的应用无法从 Flower Hub 移除但你可以通过发布更新版本引入改进、新功能或缺陷修复。流程修改应用源码更新pyproject.toml中[project]段的version字段。例如当前版本为0.1.00.1.1缺陷修复补丁发布0.2.0新功能次版本发布1.0.0重大变更主版本发布。更新版本号后使用同一命令发布新版本flwr app publish your-app-path新版本会与旧版本并列存在用户可按需引用并运行特定版本。发布前自检清单对照官方文档与源码校验逻辑发布前逐项确认✅ 应用可在 Simulation 与 Deployment 两种运行时下不修改代码运行通过context.node_config的partition-id/num-partitions判断✅ README 说明了虚拟 SuperNode 数量Simulation与数据生成/获取方式Deployment✅pyproject.toml的[project]字段完整name、version、description、license[tool.flwr.app]的publisher与账号一致✅ 若使用fab-format-version 1已声明flwrx.y.z依赖、flwr-version-target与根目录LICENSE/LICENSE.md文件✅ 目录深度不超过 10 层文件数量 ≤ 1000、单文件 ≤ 1 MB、总量 ≤ 10 MB且全部为 UTF-8 编码✅name已最终确定发布后不可更改description清晰且不超过 200 字符。完成以上全部步骤后你的联邦学习应用就正式上线 Flower Hub可供社区发现、复用与二次开发共同促进联邦 AI 生态的成长。【免费下载链接】flowerFlower: A Friendly Federated AI Framework项目地址: https://gitcode.com/GitHub_Trending/flo/flower创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Flower Hub 应用发布完全指南：从 pyproject.toml 元数据到 `flwr app publish` 实战
Flower Hub 应用发布完全指南从 pyproject.toml 元数据到flwr app publish实战【免费下载链接】flowerFlower: A Friendly Federated AI Framework项目地址: https://gitcode.com/GitHub_Trending/flo/flower本指南以 Flower 框架官方的《Publish an App on Flower Hub》How-to 文档为主体结合当前仓库中flwr app publish命令的真实实现源码系统讲解如何把一个联邦学习应用Federated App发布到 Flower Hub。你将掌握Simulation 与 Deployment 双运行时的应用兼容写法、pyproject.toml元数据与 FAB 格式版本fab-format-version的配置规则、发布时的文件收集/过滤/校验机制以及从注册账号、flwr login supergrid到flwr app publish的完整发布流程。Flower Hub 发布什么Project 与 FAB 的关系Flower Hub 是 Flower 框架的联邦 AI 应用分发平台支持应用的发现、分发、运行与去中心化验证。当你运行flwr app publish时上传的是你的完整项目project源码而不是预先构建好的.fab文件Flower Hub 会在服务端根据上传内容构建 FABFlower App Bundle。源码中可以看到这一逻辑的直接实现flwr app publish通过 multipart 请求把每个文件逐个 POST 到${FLWR_SUPERGRID_API_URL}/hub/apps/publish端点并在请求体中附带flwr_version元数据见 publish.py。这意味着两类内容需要分清Project发布物完整源码包含.gitignore、.editorconfig等开发环境文件供他人浏览、克隆和在此基础上二次开发是事实来源source of truthFAB运行时产物从 project 派生出的运行时优化子集用于一次联邦训练/推理任务。另外注意flwr app publish的上传过滤规则与flwr build的 FAB 打包规则相关但不完全相同二者分别由发布校验和服务端构建两套逻辑把关。第一步构建一个可发布的应用同时兼容 Simulation 与 Deployment 双运行时你的应用应当在不修改任何代码的前提下同时运行于 Simulation仿真与 Deployment部署两种运行时。实现方式是把数据加载逻辑按模式区分而训练逻辑保持完全一致。推荐的模式判断方法是读取context.node_config如果其中同时存在partition-id和num-partitions两个键说明应用运行在 Simulation 模式否则为 Deployment 模式。官方文档给出的标准写法如下app.train() def train(msg: Message, context: Context): Train the model on local data. batch_size context.run_config[batch-size] if ( partition-id in context.node_config and num-partitions in context.node_config ): # Simulation Engine: partition data on the fly partition_id context.node_config[partition-id] num_partitions context.node_config[num-partitions] trainloader, _ load_sim_data( partition_id, num_partitions, batch_size ) else: # Deployment Engine: load demo or real user data data_path context.node_config[data-path] trainloader, _ load_local_data(data_path, batch_size) # Training logic continues identically for both modes仓库内的真实示例与这一写法完全一致例如 quickstart-pytorch 的 client_app.py 同样从context.node_config读取partition-id与num-partitions进行数据分区。配套的数据准备建议Simulation 模式使用 Flower Datasets 在运行时动态切分数据Deployment 模式使用 CLI 命令flwr-datasets create生成演示数据参见仓库中 datasets 目录下 flwr-datasets 的 CLI 实现若应用依赖外部提供的数据则需在 README 中说明获取方式与格式要求。README 必须写清楚的内容应用 README 应明确记录Simulation预期需要多少个虚拟 SuperNode以及是否需要修改 Flower ConfigurationDeployment如何使用flwr-datasets create生成合成数据若依赖外部数据说明用户如何获取以及数据格式要求。第二步完善应用元数据pyproject.toml发布前应用的元数据必须完整且准确。元数据定义在pyproject.toml中Flower Hub 会用它来展示和标识你的应用。[project] 段的必需字段字段说明name应用唯一名称。必须以字母开头且只能包含字母、数字和连字符version当前发布版本号description应用的简短摘要发布时源码会校验其非空且不超过 200 字符见 publish.pylicense适用的软件许可证[tool.flwr.app] 段的字段字段说明publisher你的 Flower 账号用户名必须与账号一致fab-format-version可选省略时默认为0flwr-version-target仅当fab-format-version 1时必填完整示例来自官方文档[project] name my-federated-app version 0.1.0 description Federated training for medical image classification. license { file LICENSE } dependencies [flwr1.28.0] [tool.flwr.app] publisher your-username # Must match your Flower account username fab-format-version 1 flwr-version-target 1.28.0仓库中一个真实发布应用的配置可作为参考见 hub/apps/quickstart-pytorch/pyproject.toml它声明了publisher flwrlabs、fab-format-version 1、flwr-version-target 1.37.0并通过[tool.flwr.app.components]与[tool.flwr.app.config]补充了运行组件与默认超参数。license 字段的三种合法格式Flower Hub 接受以下形式的[project].license# SPDX identifier (string) license Apache-2.0 # Inline text license { text Apache-2.0 } # File reference (must be at the project root) license { file LICENSE } # or license { file LICENSE.md }规则如下file与text不能同时设置若使用license.file文件名必须是LICENSE或LICENSE.md源码常量APP_PUBLISH_ALLOWED_LICENSE_FILES (LICENSE, LICENSE.md)明确定义见 constant.py引用的许可证文件必须真实存在且包含在flwr app publish上传的文件集合中。源码会在上传前逐一校验file与text冲突、文件名不合法、文件不存在、被.gitignore或排除规则过滤掉都会直接抛出错误终止发布见 publish.py。兼容性说明对 legacy 应用Flower Hub 仍接受字符串与内联文本形式的 license但对于fab-format-version 1必须使用license { file LICENSE }或license { file LICENSE.md }。⚠️ 特别注意name与description会在 Flower Hub 上公开展示应确保清晰、描述性强、便于发现其中name在首次发布后不可修改发布前务必确认最终名称。第三步理解 FAB 格式版本fab-format-versionfab-format-version在[tool.flwr.app]中声明它定义了构建 FAB 时适用哪些构建期规则使 Flower 可以在不破坏 legacy 应用的前提下演进 FAB 格式同时允许新应用通过声明更新的格式版本启用新能力。详细机制可参见仓库中的 fab-format-version.rst。Flower 当前识别以下两种版本缺失fab-format-version或 0legacy 行为不强制要求新版字段如果应用在flwr依赖中声明了可用的闭区间下界如flwr1.28.0Flower 可以推导出最低 Flower 版本供 Flower Hub 在发布时使用fab-format-version 1严格校验对 Flower 版本兼容性与许可证文件处理做严格校验。版本 1 的强制要求对于fab-format-version 1应用必须声明[project].dependencies中的flwr依赖且使用形式的闭区间下界例如flwr1.28.0[tool.flwr.app]中的flwr-version-target根目录级许可证文件引用[project].license.file且该文件必须包含在最终 FAB 中。最小 Flower 版本由flwr依赖的闭区间下界推导得出例如dependencies [flwr1.28.0]推导出最小版本1.28.0。目标 Flower 版本flwr-version-target标识应用预期面向的 Flower 版本必须大于或等于推导出的最小版本。例如[tool.flwr.app] fab-format-version 1 flwr-version-target 1.28.1Flower Hub 如何使用这些元数据发布时服务端构建 FAB 会校验声明的格式版本并推导兼容性元数据这影响两个用户侧流程flwr app publish非法的 FAB 格式声明会在发布时直接失败flwr new publisher/app与flwr run publisher/appHub 会先依据应用的兼容性元数据拒绝不兼容的 Flower 版本再下载与运行应用参见 how-to-use-app-from-hub.rst。第四步理解发布时哪些文件会被上传flwr app publish会从应用目录收集文件、过滤、校验最后才向 Flower Hub 发送。整个流程的实现位于 publish.py可分为三个阶段。收集文件Flower 递归遍历应用目录不跟随符号链接源码中os.walk以followlinksFalse遍历并跳过 symlink 文件见 utils.py。深度超过10 个目录层级的文件不会被收集MAX_DIR_DEPTH 10见 constant.py超深会抛出AppPathDepthError并提示通过.gitignore排除无关文件。过滤文件允许的文件类型APP_PUBLISH_INCLUDE_PATTERNS定义于 constant.py**/*.py Python source files **/*.toml TOML configuration files **/*.md Markdown documentation **/*.yaml YAML configuration files **/*.yml YAML configuration files (alternate extension) **/*.json JSON data files **/*.jsonl JSON Lines data files /.gitignore Root-level gitignore file **/.editorconfig Editor configuration files /LICENSE Root-level license file /LICENSE.md Root-level license file (Markdown)始终排除的路径APP_PUBLISH_EXCLUDE_PATTERNS.flwr/** Flower internal directory .venv/** **/__pycache__/** Python bytecode cache类型过滤之后还会应用你的.gitignore规则。任何在这一阶段被丢弃的文件都会打印警告让你清楚看到哪些内容被排除源码中通过Skip: path黄色警告逐条输出见 publish.py。整个过滤管线在 filter_paths_for_publish 中实现先匹配 include 规则再取反匹配 exclude 与 gitignore 规则。校验文件集就绪后Flower 先检查每个文件是否为合法 UTF-8再验证文件数量最多1,000 个MAX_FILE_COUNT单文件不超过1 MBMAX_FILE_BYTES总大小不超过10 MBMAX_TOTAL_BYTES。以上常量均在 constant.py 中定义。全部通过后会输出✅ Validation passed以及文件数与总字节数任一检查失败都会在发送前抛出错误并中止发布。此外如果过滤后没有任何文件匹配同样会报错终止Nothing to upload。第五步创建 Flower 账号在 flower.ai 官网右上角点击Sign Up并按照指引注册。务必保证注册的用户名与pyproject.toml中[tool.flwr.app].publisher定义的用户名一致。以组织名义发布官方组织账号尚未正式支持当前做法是创建标准用户账号用组织名称作为用户名例如flwrlabs在个人资料中更新对应的 Logo 与描述。官方说明组织账号在正式支持推出后将会迁移。第六步登录并发布安装 Flower CLIpip install flwr登录 SuperGridflwr login supergrid该命令会打开浏览器窗口用你的 Flower 账号完成身份认证。要登录 SuperGrid预期你的 Flower Configuration 中存在一个名为superlink.supergrid、地址为api.flower.ai的 SuperLink 连接——安装 Flower 后默认应已存在。源码中还隐含一条安全约束登录要求启用 TLS若连接配置中insecure被设置为trueflwr login会直接拒绝见 login.py。发布应用flwr app publish your-app-pathflwr app publish上传的是项目文件源码 元数据而非预构建的.fab文件Flower Hub 在服务端根据上传内容构建 FAB。若应用使用fab-format-version 1服务端构建时会校验 Flower 版本元数据与许可证文件要求。发布成功后源码会输出绿色提示 Upload successful见 publish.py。查看你的应用发布完成后你的应用将出现在https://flower.ai/apps/account_name/app_name/发布后申请可信审查如果你希望应用发布后由可信审查者验证参见 how-to-sign-hub-apps.rst。发布新版本已发布的应用无法从 Flower Hub 移除但你可以通过发布更新版本引入改进、新功能或缺陷修复。流程修改应用源码更新pyproject.toml中[project]段的version字段。例如当前版本为0.1.00.1.1缺陷修复补丁发布0.2.0新功能次版本发布1.0.0重大变更主版本发布。更新版本号后使用同一命令发布新版本flwr app publish your-app-path新版本会与旧版本并列存在用户可按需引用并运行特定版本。发布前自检清单对照官方文档与源码校验逻辑发布前逐项确认✅ 应用可在 Simulation 与 Deployment 两种运行时下不修改代码运行通过context.node_config的partition-id/num-partitions判断✅ README 说明了虚拟 SuperNode 数量Simulation与数据生成/获取方式Deployment✅pyproject.toml的[project]字段完整name、version、description、license[tool.flwr.app]的publisher与账号一致✅ 若使用fab-format-version 1已声明flwrx.y.z依赖、flwr-version-target与根目录LICENSE/LICENSE.md文件✅ 目录深度不超过 10 层文件数量 ≤ 1000、单文件 ≤ 1 MB、总量 ≤ 10 MB且全部为 UTF-8 编码✅name已最终确定发布后不可更改description清晰且不超过 200 字符。完成以上全部步骤后你的联邦学习应用就正式上线 Flower Hub可供社区发现、复用与二次开发共同促进联邦 AI 生态的成长。【免费下载链接】flowerFlower: A Friendly Federated AI Framework项目地址: https://gitcode.com/GitHub_Trending/flo/flower创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考