---
url: /support.md
---
# 技术支持

## 基础版

在使用框架的过程中难免会遇到问题，优先推荐在仓库提交 Issue ，你可以更详细描述问题产生的操作步骤，或者**提供最小复现**，这样做可以让更多的人参与讨论，也方便后人查阅。

* [Github Issue](https://github.com/fantastic-admin/basic/issues)
* [Gitee Issue](https://gitee.com/fantastic-admin/basic/issues)

## 专业版

购买专业版的用户会邀请到专业版的微信群，并在群内提供技术支持，必要时也请**提供最小复现**。

## 请提供最小复现

如果你(使用者)需要我(作者)帮助你解决问题，在无法准确描述复现步骤时，请提供最小复现。

> 如果你曾经因为我要求提供最小复现而感任何的不愉悦，我在这里先说声抱歉。在下面我将尝试解释这背后的理由。

### 为什么需要提供最小复现

一个好的**最小复现**可以极大地帮助我确定根本原因，并迅速地进行修复。

想象一下，如果没有最小复现，仅凭简单的描述或者一张截图或一段录屏，我甚至可能都不知道这个问题是否是由项目本身引起，或是其他因素造成的。

为了确定这一点，我可能需要花额外的时间尝试建立一个复现，或者深入你所提供的大型项目中（即非最小复现）。

这个过程可能会花费几个小时，但如果最后问题还是无法复现，或者发现根本不是项目本身的问题呢？如果每个人都用这样的方式来向我寻求帮助呢？

在我看来，**要求最小复现是在要求你与我所花费的努力尽可能公平**。

如果每个人都能在寻求帮助前，花一些时间创建一个最小复现，合集下来就能为我节省数百个小时，这甚至可以帮助你自己找到解决方案/错误，以至于不再需要向我寻求帮助（如果你知道“[小黄鸭调试法](https://zh.wikipedia.org/wiki/%E5%B0%8F%E9%BB%84%E9%B8%AD%E8%B0%83%E8%AF%95%E6%B3%95)”，那你应该能明白我的意思）。

### 如何准备一个最小复现

在大多数其他时候，你可以：

1. 使用框架源码作为复现工程，并尝试复现问题，注意除了问题本身之外，不要做其他事情。把它缩减到能够可靠地复现问题，且使用尽可能少的代码。摆脱任何与问题没有直接关系的依赖性。

2. 使用演示源码作为复现工程，演示源码提供了大量可用的示例，使用这些示例来尝试复现问题可以简化准备最小复现的难度。