- 创建时间: (按照创建时间填写, 日-月-年)
- RFC（请求评论） PR: [代码仓名称/rfc#pr number](https://gitee.com/openharmony/repositroy-name/pulls/xxxx)
- Issue: [代码仓名称/issue number](https://gitee.com/openharmony/repository-name/issues/xxxxxx)

#（RFC 标题）

## 概括

> 提案的简要概述。

## 目的

> 为什么要这样设计和实施？支持了那些用户场景？预期的结果是什么？

## 设计细节

> 该章节包含 RFC的主要内容。

> 为大家详细阐述设计的思路：详细的背景和设计介绍更能有助于大家的理解，包括详细模块设计细节，以及如何使用模块指导，其中任何新的专业术语要有明确的定义。

## 缺点

> 为什么我们应该*不*这样做？请考虑关于此提案与现有方案和规划特性等的集成对用户的影响。

> 选择任何方案都需要权衡，请尝试在此描述相关的问题。

## 基本原理和替代方案

> 为什么这个设计在可选的设计方案中是最好的？

> 还考虑了哪些其他设计，不选择它们的理由是什么？

> 没有选择其他的设计方案会有什么影响？


## 现有技术

讨论与该提案相关的现有技术，无论是好的还是坏的。这可以包括的一些说明：

> 相同领域的中其他解决方案是如何解决这个问题。

> 是否有任何已发表的论文或重要的帖子讨论过这个问题？如果你有一些相关的论文可以参考，这可以作为更详细的理论背景。

本节旨在鼓励您作为提案者洞察其他平台的经验知识，为您的 RFC 阅读者提供更全面的了解。如果没有现有技术，无论它们是全新的还是从其他业务改造而产生，那说明您的想法很有创新性。

## 遗留问题

> 在合并之前，您希望通过 RFC 流程解决设计的哪些问题？

> 在功能稳定之前，您希望通过实施此功能解决设计的哪些问题？

> 您认为哪些相关问题超出了本 RFC 的范围，这些问题可以在未来独立于本 RFC 的解决方案解决？