提交 issue 必读（除非你并不需要解决问题）

[tangjinzhou]

当你提交不合格issue后又补充了复现示例，如果长期没有得到回复，可以尝试新建合格 issue。
因为一旦被标记为不合格issue，即便你后续更改为了合格的issue，也会有可能错过我们的审核查看。

所以建议您在第一时间提交合格的issue，合格的issue，合格的issue，合格的issue，合格的issue，合格的issue，合格的issue，合格的issue，合格的issue，合格的issue，合格的issue，合格的issue，合格的issue，合格的issue，合格的issue，合格的issue.............

如何提交 issue？（耐心看完，除非你并不需要解决问题）

1、确保反馈的版本是你本地使用的版本
2、尝试新版本是否已经修复了你的问题，如果你不想升级，就只是想解决问题，我们也没有办法
3、一定要提供有效的复现，不提供复现，我也不知道是你的代码问题，还是我们的组件问题，纯属浪费大家时间
4、彼此尊重，不符合规范的 issue，会被直接关闭

所谓『重现』，就是一段可以运行并展示一个 bug 如何发生的代码。

文字是不够的

如果你遇到一个问题，但是只提供了一些文字描述，我们是不可能修复这个 bug 的。首先，文字在描述技术问题时的表达难度和不精确性；其次，问题的真实原因有很多可能，它完全有可能是一个你根本没有提及的因素导致的。重现是唯一能够可靠地让我们理解问题本质的方式。

重现必须是可运行的

截图和视频不是重现。它们仅仅证明了 bug 的存在，但却不能提供关于 bug 是如何发生的信息。只有可运行的代码提供了完整的上下文，并让我们可以进行真正的 debug 而不是空想和猜测。当然，在提供的重现的前提下，视频或是 gif 动画可以帮助解释一些比较难用文字描述的交互行为。

重现应当尽量精简

有些用户会直接给我们一整个项目的代码，然后希望我们帮忙找出问题所在。此类请求我们通常不予接受，因为：

你对你的项目的代码结构可能已经非常熟悉，但我们并不是。阅读、运行、分析一个完全陌生的项目是极其耗费时间和精力的。

由于涉及了大量业务代码，问题可能是你的代码错误，而不是 antd 的 bug 所导致的。

一个最小化的重现意味着它精确地定位了 bug 本身 - 它应当只包含能够触发 bug 的最少量的代码。你应当尽可能地剔除任何跟该 bug 无关的部分。

如何提供一个重现

除非你的 bug 只有在构建工具下才能重现，否则我们建议通过点击 此处 for vue2、 此处 for vue3 创建一个 codesandbox 或者提供一个最小化的 GitHub 仓库。请确保选择准确的版本。

[tangjinzhou]

当你提交不合格issue后又补充了复现示例，如果长期没有得到回复，可以尝试新建合格 issue。
因为一旦被标记为不合格issue，即便你后续更改为了合格的issue，也会有可能错过我们的审核查看。

所以建议您在第一时间提交合格的issue，合格的issue，合格的issue，合格的issue，合格的issue，合格的issue，合格的issue，合格的issue，合格的issue，合格的issue，合格的issue，合格的issue，合格的issue，合格的issue，合格的issue，合格的issue.............