什么是nonebot？
关于NoneBot2，我们先来引用一下官方文档的描述
NoneBot2 是一个可扩展的 Python 异步机器人框架，它会对机器人收到的事件进行解析和处理，并以插件化的形式，按优先级分发给事件所对应的事件响应器，来完成具体的功能。
除了起到解析事件的作用，NoneBot 还为插件提供了大量实用的预设操作和权限控制机制。对于命令处理，它更是提供了完善且易用的会话机制和内部调用机制，以分别适应命令的连续交互和插件内部功能复用等需求。得益于 Python 的 asyncio (opens new window)机制，NoneBot 处理事件的吞吐量有了很大的保障，再配合 WebSocket 通信方式（也是最建议的通信方式），NoneBot 的性能可以达到 HTTP 通信方式的两倍以上，相较于传统同步 I/O 的 HTTP 通信，更是有质的飞跃。
需要注意的是，NoneBot 仅支持 Python 3.7+ ，个人推荐的开发版本是3.8.10
看起来晦涩难懂？其实要点主要有以下几个：
- Nonebot2是基于python3.7及以上运行的
- 框架整体基于异步io
- 有完善的预设指令，可减轻开发者的工作强度
看到这里，你可能会大呼过瘾。如此优秀的框架已经迫不及待的想要使用了呢！
且慢且慢，请先随我一起进行学习，慢慢上手。
如果你决心想要开始nonebot之旅，先让我给你泼盆冷水
目前，QQ机器人社区处在一个十分艰难的状态下，一是由于腾讯的打压导致QQ机器人无法正常的工作，二是由于缺少足量的开发者和足够易用的工具（轮子），导致新手入门极为困难，因此如果你决定想要加入nonebot大家庭，那么你首先应该做到以下几点：
有足够的 python 基础以及足够的计算机操作系统的使用经验。
计算机使用经验这一点我无法详细说明，由于每个人的情况均有所不同，所以我也无法很好的给出结论，但只会打游戏，其他多一点（如文件格式、路径）都不会还不肯学的的是完全不行的。
python 基础方面，由于nonebot是基于asycnio的异步事件处理框架，使用难度上来说，某种程度上甚至高于一些简单的机器学习框架，而一般非专业和部分专业的大学学习的 python 课程是无法达到这个标准的，更别说零基础了。所以在玩转nonebot之前，将会有漫长的学习过程。
有足够的耐心
上文也说了，由于开发者较少，nonebot是没有足够的拿来即用的软件生态的（或者说，现在整个机器人社区都是半死不活的状态），因此一些特殊需求很有可能需要你自己动手编写插件才能够实现，这也意味着使用成本的上升。
有足够的心态
由于腾讯为了强推自家的机器人，和使用QQ机器人的黑灰产产业猖獗，导致腾讯对于野生机器人采取一棍子打死的态度，现在不光如此，甚至还想来踩上两脚。因此，你在使用机器人的时候说不定什么时候就会被 “风控” ，导致你的机器人发不出任何话，图片和其他炫酷的功能，甚至会导致你的账号冻结。因此，如果你要长期维护一个机器人，这是无法避免的问题。
如果你并没有被前方的艰难险阻劝退的话，欢迎你加入nonebot大家庭
对于这个系列教程，我会尽我最大的努力，讲晦涩难懂的知识拆分，用尽量简单的方法教会大家如果使用这个项目。
更新计划
视频部分：【零基础搭建QQ机器人】开源、免费、纯新手向的nonebot2.0.0beta版讲解
讲解一些环境配置、部署以及其他不适合使用文字表达的部分，作为纯新手入门以及文字部分的补充。
第一章：Hello World——初识NoneBot2
在本章节，你将学会安装并配置你的第一个QQ机器人实例，并且可以掌握一些部署阶段常见的bug的特征以及解决方法，与视频部分相互补充。
第二章：哈？你说啥？——基础插件编写指南
在本章节，你将学会编写最基本的文字和图片的交互的插件。
第三章：在？来张setu？——进阶插件编写指南
在本章节，你将学会使机器人能够响应更多的事件，发送更多种类的信息，以及插件间通信、定时任务框架等。
第四章：你认真读README了吗？——常用API总结
在本章节，我将梳理nonebot及gocqhttp的常用api，并附上实例。
引言（基础知识）
在正式开始教程之前，我想对以下几个概念进行说明：
初步认识前端、后端
我们先思考一下，如果让你去实现一个QQ机器人，我们需要什么样的程序？
如果你现在没有头绪，我们不妨先去看一下这个例子
- 顾客去饭店点了一份鱼香肉丝
- 服务员将你点鱼香肉丝的这件事汇报给后厨
- 后厨的厨师炒出了鱼香肉丝
- 服务员从后厨取出了鱼香肉丝
- 服务员把鱼香肉丝交给顾客
在这个过程中，顾客所接触到的人只有服务员，但服务员本身并不进行炒菜的工作，而厨师又始终不知道具体是谁哪位顾客了什么菜，那么这份菜究竟是怎么交付到这位顾客的手中的呢？
我们再回顾一下第二条与第四条，这两条中服务员与厨师进行了“交互”，通过这种方式将厨师所需要的信息进行了传递。并且将厨师处理完毕的菜交到顾客的手中。
这种结构最大的优点是高度的可替代性和稳定性，例如今天厨师A生病了就可以换用厨师B，服务员Ｃ的老婆生孩子了就可以让服务员D多干一些。而不会出现因为某个环节的部分功能缺失导致全盘崩溃。
我们将目光放回到QQ机器人上，用上述的思路重新进行思考，把顾客、服务员与厨师替换成腾讯的服务器、前端、后端。
- 前端从腾讯的服务器上接收用户的信息（或其他）
- 将信息传递给后端
- 后端对信息进行分析，调用对应的模块进行处理
- 后端将处理结果推送给前端
- 前端将处理后的结果重新发送给腾讯的服务器（或其他）
怎么样，是不是一目了然了呢？
在本篇教程中，我们使用的的前端是go-cqhttp，后端是NoneBot2，他们将很很好的完成上述的工作。
WebSocket
WebSocket是一种在单个TCP连接上进行全双工通信的协议。WebSocket使得客户端和服务器之间的数据交换变得更加简单，允许服务端主动向客户端推送数据。在WebSocket API中，浏览器和服务器只需要完成一次握手，两者之间就直接可以创建持久性的连接，并进行双向数据传输。
在go-cqhttp与NoneBot的信息交互中，我们使用的就是反向WebSocket连接，也就是说go-cqhttp会主动去寻找nonebot2的程序，并将消息通过ws推送给nonebot2，因此相对于传统的HTTP连接，这种方法明显效率更高，延迟更低。
OneBot标准
OneBot标准是一个聊天机器人应用接口标准，旨在统一不同聊天平台上的机器人应用开发接口，使开发者只需编写一次代码即可应用到多种机器人平台。
在go-cqhttp与NoneBot的信息交互中，通讯的内容是基于OneBot的标准的改版，具体可以参考go-cqhttp的文档。
我们先回顾一下前文中的饭店。
如果这个饭店是一个法餐馆，服务生是中国人而厨师是法国人，二者语言并不互通，那么还能够完成点餐的任务吗？
明显不能，所以我们会人为要求服务生与厨师都用同一种语言进行交流，而这种语言标准就可以帮助二者有效的沟通。
在两个程序的沟通中，我们需要二者能够识别对方的信息，而不同的开发者不一定会使用一样的交流方式。因此随着OneBot标准的诞生，开发者可以使用这个标准的规范化的语言，那么语言不通的问题就迎刃而解了。
工作路径（Working Directory）、相对路径与绝对路径
The directory in which you are currently working. Path names that do not start with the root directory are assumed by the operating system to start from the working directory
————该解释出自 Webopedia
简单来说，工作路径是相当于一个锚点，作为 相对路径 寻找文件的出发点。就类似于你去给别人指路（问路），一般来说会从你现在的位置作为起点进行寻路，那么这个就叫做相对路径。同理，如果现在的位置发生了改变，那么按照相同的路径来寻路自然到不了想要的目的地。
而 绝对路径 则不会受到该问题的影响，类似于从一个固定的建筑指路到目标地 ，那么只要目标地不发生改变，路线自然不会因为你现在的位置不同而出现改变。
那么，绝对路径就比相对路径好？
答案是否定的。我们不难看出，绝对路径会要求目标地点不能发生改变，而在任意一个操作系统里面，复制和转移文件都是家常便饭的操作，因此，绝对路径的基本要求很难被满足，因此基本上只会出现在一些特殊场合和自己写的简易的脚本上，而无法应对任何位置的改变。
相反，相对路径如果能保证起始位置的准确，是能够在这个整体里面路径的准确的，类似于一个规划图完全相同的游乐园里面，摩天轮的位置相对过山车的位置始终一致，而无论这座游乐园实在北京还是上海。相对于现实中建筑物需要因地制宜进行规划，计算机中一个程序的复制和传播的成本几乎不费吹灰之力，那么相同结构的程序为了能在不同计算机上进行工作，甚至是不同操作系统上进行工作，是绝对无法离开相对路径来维持其内部程序和文件之间的联系的。
那么，这个如此重要的起始位置，就是工作路径。程序会依据起始位置来进行搜索所需要的文件，那么如果起始位置跑了，自然也无法搜索到想要的程序了。
在nonebot中，工作路径位于bot.py的根目录。
在第一节中，我们会了解到vscode如何人为指定工作路径，或通过python自身来修正工作路径。