• 开始时间：（填上今天的日期，YYYY-MM-DD）
• 目标主要版本：（2.x 或 3.x）
• 引用 issue：（填写现有的 issue，如果有的话）
• 实现的 PR：（留一个空白）

摘要

对该功能的简要解释。

基本范例

如果建议涉及到一个新的 API 或者修改 API，需要包含一个基本的代码例子。如果不适用，则忽略此部分。

动机

我们为什么要这样做？它支持什么用例？预期的结果是什么？

请专注于解释动机，这样如果这个 RFC 不被接受，可以利用这个动机来开发其他的解决方案。换句话说，例举你要解决的制约因素，而不要把它与你心目中的解决方案耦合得太紧密。

具体设计

这就是 RFC 的主要内容。对设计进行足够详细的解释，让熟悉 Vue 的人能够理解，让熟悉实现的人能够实现。这里应该涉及到具体细节和边沿案例，并包括如何使用该功能的例子。任何新的术语都应该在这里定义。

缺点

我们为什么不应该这样做？请考虑：

• 实现成本，包括代码大小和负责程度；
• 建议的功能是否能在用户空间中实现；
• 对教人使用 Vue 的影响；
• 该功能与其他现有或者计划中的功能的整合；
• 迁移现有 Vue 应用程序的成本（是否是一个破坏性的改变？）

选择任何路径都需要权衡。尝试在这里确定它们。

备选方案

还考虑了哪些其他设计？不这样做的影响是什么？

采纳策略

如果我们实施了这个建议，现有的 Vue 开发者应该如何采用它？这是一个破坏性的改变吗？我们可以写一个 codemod 吗？我们能为它所替代的原始 API 提供一个运行时的适配器吗？这将如何影响 Vue 生态系统中的其他项目？

没有解决的问题

可选的，但建议用于初稿。设计的那些部分仍是待定（TBD）？