准备新的开发组文档，初步手机端访问支持

原来的在docs/devdocs/_legacy目录下面

docs/devdocs/_legacy/09-培训/01-git/01-概览.md

@@ -0,0 +1,44 @@
+# 概览Git
+这里是git的一个简短教程
+## 目录
+本教程的目录。。。
+
+1. 介绍-做为版本控制系统的git
+
+    - 什么是版本控制系统(VCS)?
+    - git是如何进行版本控制的？
+
+2. git的基础概念
+
+    - 新建一个git仓库
+    - 跟踪文件，暂存文件
+    - 提交commit
+    - 分支(branch)介绍
+    - 合并-merge与rebase
+        - cherry-pick
+    - HEAD和相对引用
+
+3. 远程仓库
+
+    - clone和origin
+    - 远程分支是什么
+    - fetch , pull & push !
+
+4. 托管平台
+
+    - github
+    - gitlab
+    - gitea
+
+5. 高级
+
+    - GUI
+        - git-gui
+        - vscode上的一些扩展
+        - lazygit
+    - 自建git服务
+        - gitea
+    - 参考
+        - pro git
+        - learngitbranching.js.org
+

docs/devdocs/_legacy/09-培训/01-git/02-介绍-做为版本控制系统的git/01-vcs.md

@@ -0,0 +1 @@
+# 什么是版本控制系统(VCS)?

docs/devdocs/_legacy/09-培训/01-git/02-介绍-做为版本控制系统的git/02-gitintroduction.md

@@ -0,0 +1 @@
+# git是如何进行版本控制的？

docs/devdocs/_legacy/09-培训/01-git/03-git的基础概念/01-新建一个git仓库.md

@@ -0,0 +1 @@
+# 新建一个git仓库

docs/devdocs/_legacy/09-培训/01-git/03-git的基础概念/02-跟踪文件，暂存文件.md

@@ -0,0 +1 @@
+# 跟踪文件，暂存文件

docs/devdocs/_legacy/09-培训/01-git/03-git的基础概念/03-提交commit.md

@@ -0,0 +1 @@
+# 提交commit

docs/devdocs/_legacy/09-培训/01-git/03-git的基础概念/04-branch.md

@@ -0,0 +1 @@
+# 分支(branch)介绍

docs/devdocs/_legacy/09-培训/01-git/03-git的基础概念/05-HEADandRefrences.md

@@ -0,0 +1 @@
+# HEAD和相对引用

docs/devdocs/_legacy/09-培训/01-git/03-git的基础概念/05-MergeAndMore.md

@@ -0,0 +1 @@
+# 合并-merge与rebase

docs/devdocs/_legacy/09-培训/01-git/04-远程仓库/01-CloneOrigin.md

@@ -0,0 +1 @@
+# clone和origin

docs/devdocs/_legacy/09-培训/01-git/04-远程仓库/02-remotebranch.md

@@ -0,0 +1 @@
+# 远程分支是什么

docs/devdocs/_legacy/09-培训/01-git/04-远程仓库/03-fetchpullpush.md

@@ -0,0 +1 @@
+# fetch , pull & push !

docs/devdocs/_legacy/09-培训/01-git/05-托管平台/01-github.md

@@ -0,0 +1 @@
+# github

docs/devdocs/_legacy/09-培训/01-git/05-托管平台/02-gitlab.md

@@ -0,0 +1 @@
+# gitlab

docs/devdocs/_legacy/09-培训/01-git/05-托管平台/03-gitea.md

@@ -0,0 +1 @@
+# gitea

docs/devdocs/_legacy/09-培训/01-git/06-高级/01-gui.md

@@ -0,0 +1 @@
+# GUI

docs/devdocs/_legacy/09-培训/01-git/06-高级/02-selfhosted.md

@@ -0,0 +1 @@
+# 自建Git服务

docs/devdocs/_legacy/09-培训/01-git/06-高级/03-references.md

@@ -0,0 +1 @@
+# 参考

docs/devdocs/_legacy/09-培训/02-Web后端/01-Web后端的简单介绍.md

@@ -0,0 +1,213 @@
+# Web后端的简单介绍
+这篇文章将带你学习构建一个Web后端的简单知识;作为一篇基础的教程，我们在教程里不会太多涉及诸如缓存，消息队列等高级内容，而是专注于基础的部分;我们也不会在一开始就涉及到具体的编程语言代码，而是将这篇文章作为一个理论性的介绍.你可能至少需要了解一些计算机的基础知识，比如html等，才可以了解文章中的一些概念.
+
+## Web的历史
+进行Web后端开发，首先需要知道Web的一些概念，实际上，“后端”这个概念不是一开始就存在的，随着人们对互联网需求的不断复杂化，后端的概念才出现了，我们首先来了解Web的发展历史
+
+### 静态网页
+互联网最开始只有静态网页，所谓“静态”，指的是网页中的内容是完全固定的，在服务器端存储了内容固定的html,css，或者是其他的什么文件，用户访问网页，就是通过互联网查看这些固定的文件。在这种情况下，你访问一个网站，从本质上更像是访问远端计算机上的某个文件夹
+
+例如，如果要建立一个网站，那就在你的电脑上安装一个HTTP服务器（比如apache,nginx），在软件的设置里指定你电脑上的某个文件夹为网站的根文件夹，然后去买一个域名（网址的意思），把域名的DNS绑定到你电脑的IP地址上，那么其他人在浏览器上输入你的域名，就可以访问根文件夹下面的内容了。比如，在根文件夹下面放一个`index.html`,那访问域名时，浏览器就会默认显示这个文件的内容，可以在下面放一些图片，比如根文件夹下面有：
+`/foo.jpg`和`/subfolder/bar.jpg`，那么别人在浏览器上面输入`http://yourdomain.com/foo.jpg`和`http://yourdomain.com/subfolder/bar.jpg`就可以访问到对应的文件。
+
+这种方法很原始，但是如果需求不是很大的话，你也可以使用这种静态网页，你现在正在看的文章，其实就是一个静态的网页
+
+这些访问都是通过HTTP协议来进行的，在这里，我们需要详细介绍HTTP协议，以及HTTP协议的方法：
+
+#### HTTP协议
+HTTP（HyperText Transfer Protocol，即超文本传输协议）是一个网络客户端（比如浏览器）和服务端（比如服务器，当然普通的电脑也可以）之间沟通的协议，让浏览器可以对服务器上的某个文件进行操作（最常见，也是大家最熟悉的用途就是获取这个文件，然后显示出来～），我们上面举的例子，包括我们日常浏览网站的本质，就是在获取服务器上面的内容(实际上HTTP协议可以做的不止这些，下面会讲到)
+
+一个完整的HTTP通信包含了请求和回应,请求有客户端发起，回应是服务端返回给客户端
+
+##### HTTP的请求
+严谨地说，一个HTTP请求包含请求头(HTTP Request Header)和请求体(Request Body)，一个HTTP的请求头主要包含了：
+- 目标网站:资源存在的网站，例如`example.org`
+- URL,用于指定需要操作的是哪一个文件，例如`example.org/hahaha.txt`
+- 方法，用于指定操作，即对URL指定的资源进行什么操作，比如访问这个文件
+- 自定义参数：前面说的URL和方法都是通过键值对的形式存在于请求头上的，作为请求头的参数（键值对就是形如`a=b`的表达式）你也可以自定义一些键值对在请求头里，这表现为附加在URL之后的一系列键值对，通过?开头，&分割，例如`example.org/hello.html?locale=zh-CN&custom=wuwuwu`,这就告诉服务器:两个参数：`locale=zh-CN,custom=wuwuwu`，这些参数是可选的，自定义的参数可以用于被后端解析，现在不理解也没关系，关于URL参数的话题我们在之后谈
+- cookie:cookie是服务器放在浏览器里的一些临时缓存，可以干一些事情，当然需要有这个东西才会在请求头里带着，我们也以后再谈
+
+对于某些方法，需要在请求时向服务器夹带一些东西，请求体就是装载这些东西的
+
+
+###### HTTP方法
+HTTP方法定义了这个请求具体要对指定的文件做什么，其中：
+- GET:获取指定的资源
+- POST:上传指定的资源
+- PUT:更新指定的资源，如果没有就创建一个
+- PATCH:修改指定的资源
+- DELETE:删除指指定的资源
+- HEAD:和GET差不多，但是只要求服务器返回回应头，可以用在试探文件的大小上，来判断文件的更新情况，从而决定下一步操作
+
+我们日常使用浏览器，比如在地址栏中输入`baidu.com`,其实就是在对这个地址做GET请求，一般用户使用浏览器，自己是不能做出除了GET之外的请求的，但是其他请求在现代的网站中被经常使用，这其实是前端脚本在工作，以后会解释
+
+如果使用某一些方法的话，需要上传一些东西，那么这些东西就需要放在请求体里面，比如POST等
+
+##### HTTP的响应
+其实回应也分为回应头和回应体，回应头主要包含：
+- 状态码：针对请求的回应有对应的状态，比如，如果GET请求没有问题，成功返回的话就返回200 OK状态码，如果找不到请求里对应的文件就会返回`404 Not Found`
+- 内容格式:向浏览器说明回应体（若有）是什么格式的,文本文件的编码设置等，比如html文件？图片？这决定了浏览器如何对待这些文件
+- 内容的大小：返回所请求资源的大小（若有）
+
+回应体就是包含了回应的主体内容了，如果是GET请求的话，那么就回应了所GET文件的内容，如果是其他请求的话，可能也会没有回应体，具体看使用的方法
+
+##### 一个例子
+`GET`方法从服务器获得一个资源，我们在浏览器的地址栏输入一个地址时，就是在对这个URI做`GET`请求，前面的例子也是通过`GET`方法来进行的。
+
+比如，发送`GET developer.zsxyww.com/test/test.txt`,那么就会把我们服务器上的test.txt这个文件发过来
+
+`POST`方法向服务器上传一个资源，例如使用某个客户端发送`POST http://example.org/someprogram.exe`，在request body里面带上你的这个文件，那么`example.org`网站的根目录下就会多出一个叫做`someprogram.exe`的文件
+
+除了上面介绍的这些方法，还有`DELETE`,`PATCH`等方法，分别对应了删除，修改一个资源，你可以在你的电脑上通过`curl`等程序，或者通过浏览器控制台来进行常规的`GET`之外的方法请求
+
+:::tip 提示
+
+httpbin.org 这个网站可以让你试验HTTP协议的方法
+
+:::
+
+不管使用的是什么方法，HTTP协议传输的对象都是一些固定静态的文件，这些文件的内容是什么就是什么，不会变化，这样的网页就叫做静态网页。
+
+### 动态网页
+这样的网页是不能满足大家对互联网的需求的，举例子来说：淘宝上有数不清的商品在售卖，如果淘宝为每一个商品都在服务器目录下面创建一个html文件，好让大家通过访问`http://taobao.com/someproduct.html`来查看商品信息，那这个工作量就非常大了，还有一些更重要的问题：这样的网页，基本上没有交互的功能，我们希望用户可以点击按钮就能购买商品，商家填写表单就能上传商品
+
+#### CGI
+这些都是静态互联网无法解决的问题，所以程序员们开发了一个叫CGI(Common Gateway Interface,通用网关接口)的技术，这种技术在用户请求网站的内容时，让一个脚本劫持用户的请求，返回给用户一个脚本动态生成的html文件，比如，如果用户想知道报名数据库里面目前所有的报名人员，发送`GET http://example.org/allVolunteer.html`，CGI程序发现给本机请求`allVolunteer.html`这个文件，并且程序的代码里写了：如果接受到对`/allVolunteer.html`的请求，那就去查找数据库里面的全部报名人员，并将返回结果插入到一个模板html文件中。程序返回这个文件，于是，用户就受到了CGI程序动态产生的html.
+
+虽然CGI现在很少见了，但是将一个发送到服务器的地址请求劫持到脚本（函数）上是现代动态网站的常用思路。
+
+#### JavaScript
+除了服务器，浏览器也在为适配动态网站而更新。在1995年，网景公司的员工发明了一种编程语言，叫做"JavaScript",这是对当时新兴的Java和Java Applet的回应，这种语言最大的特点就是它被设计在浏览器中运行，并且可以调用相关接口来操作页面html，css内容和进行HTTP请求，他们让自己家的网景浏览器率先支持了这种编程语言(这个浏览器就是火狐浏览器的前身)，这极大的提高了浏览器对于动态网页的支持。
+
+#### AJAX(Asynchronous JavaScript and XML)
+尽管是在浏览器里的语言，但是作为一个完整编程语言的JavaScript还是非常强大的，在有了操作DOM,发起HTTP请求的能力后，JavaScript,搭配一些后端的程序，可以做到CGI传统动态页面没有办法做到的功能：动态更新用户html页面上的内容。传统的后端CGI,可以动态生成html,但是这个html生成之后到用户的手里还是不会变化的，而JavaScript作为一个编程语言,通过运行在用户浏览器,可以操作html内容和发起HTTP请求，便可以自己异步地对服务器发送一些请求，依据这些内容便可以部分改变用户浏览器所显示的HTML,CSS，只需要浏览器重新渲染一遍就行了，这种技术就叫做AJAX,Asynchronous JavaScript and XML
+
+AJAX与传统动态页面的不同点是：在获取新数据时，不是刷新全部的页面，而是让JavaScript操作页面的部分内容。同时，后端也不是返回html，而是返回一些可以被JavaScript理解的序列化数据（例如纯文本、XML,JSON等），前端的脚本根据这些数据，来操作用户的html
+
+
+##### 例子
+比如，在浏览我们的wiki网站时（虽然我们的wiki是静态网页），你会发现页面的大部分元素都是重叠的，比如页面最上面的导航栏，sidebar,页脚等，样式也是一样的，在切换不同的页面时，每次获取html都要重新获取这些重复的部分，这样就造成了一些浪费，如果使用AJAX技术，那么只需要第一次打开网站的时候加载这些框架性的元素，然后再加载一个JavaScript脚本，点击sidebar的时候，就将那个文章的内容本身拿过来，然后替换掉原有的页面内容，这样就更加节省，这种部分更新页面内容，而不重新加载整个页面的技术，就叫做AJAX
+
+再举一个例子,比如我们的报名系统有一个查询功能，如果输入的用户在数据库存在的话，返回这个用户的全部信息，如果不存在，那么要给用户显示一条错误信息，这种信息如果要单独给用户发送一个新页面的话，是很麻烦的，用户端的体验也不好，我们希望在按下查询按钮之后直接在原来的页面旁边显示服务器返回的结果，如果没有AJAX技术，那么我们只能把用户的当前页面重新发过去，但是把查询结果也放里面，因为传统没有JavaScript的网页没有办法对数据进行一些简单的操作，只是被动的渲染html.css文件，而AJAX技术就允许我们直接把返回的数据本身发送到客户端，而且发送的数据也不止局限于HTML,CSS,而可以是一个XML,JSON,或是直接返回状态码，让客户端脚本负责解析这些数据，并将这些数据变成浏览器其他部分可以直接渲染的文件
+
+当一个URL不是返回一个HTML数据，而是返回一些不是给用户本人准备的数据时，当这些路径不止于接受GET请求时，这些路径就和我们传统静态网站的URL，代表一个文件时所表现的路径有所不同了
+
+这些后端路径不是给用户设计的，通过浏览器直接访问这些地方大概会返回一些用户难以读懂的代码，他们是给JavaScript,或者另一种程序设计的，这种路径就叫做web API，他们是两个程序通过HTTP交互的地方，而不是人机交互的界面，我们先举一个例子，再解释这个问题
+
+:::tip 提示
+
+AJAX技术在今天已经非常常用了，以至于很多人都意识不到他们在使用AJAX技术
+
+:::
+
+##### 一个AJAX报名系统的例子
+下面举一个例子，来详细说明AJAX的工作原理：用户需要通过一个网页进行某项活动的报名，填写个人信息，然后点击网页上的提交按钮，服务端会返回报名的结果，成功还是失败，与传统的方法不同，服务器返回信息时不是重新返回一个HTML,而是让浏览器直接在原有的界面上（比如提交按钮的下面）显示报名的状态
+
+用户通过浏览器输入地址，使用`GET`方法发起对`http://example.org/submit.html`的请求，服务器获得请求后，在root目录下面找到submit.html文件,浏览器得到文件后开始解析渲染这个文件，发现这个html在头部又要求浏览器向服务器获取`submit.js`文件，于是浏览器不需要用户处理自己又发送了一条`GET`的HTTP Request,并且执行返回的脚本，这个脚本的内容是监听html文件中提交按钮的“点击”事件，当按钮被点击时，执行某个函数。
+
+返回的html文件包括了提示框，要求用户输入姓名，手机，空闲时间等信息，在这些输入栏的最下面有一个提交按钮，当点击这个按钮时，脚本就会被激活，脚本执行的函数将读取用户从上面输入进来的内容，做一些简单的认证（比如说手机号的格式等），然后将这些信息组织成一个XML文件（当然,AJAX中的X就是XML咯，现在其实也可以用其他的方法序列化，比如JSON什么的），向服务器发送一个`POST`请求，地址是`http://example.org/api/submit/submit.php`,在请求体中包含刚才的XML文件。
+
+服务器在接收这个请求后，就会将，这个请求的上下文全部转交给`submit.php`这个脚本，脚本再做一些工作，录入数据库，如果一切都成功了，就向客户端发送回应成功，反之则回应失败的消息，回应的内容可以是一个纯文本，或者直接是状态码，比如，就返回一个JSON:
+
+```JSON
+
+{
+    "status":"success",
+    "submit":{
+        "name":"小明",
+        "freeday":"2023-11-25",
+        "phone":10000000000
+    },
+    "createdAt":"2023-10-25_9:23:22"
+}
+
+```
+
+在JavaScript脚本接收到回应后，根据返回的内容，操作html文件的内容，在提交按钮的下面一行插入一个文本块：
+
+```HTML
+
+<div id="json_responses">
+    <p id="json:status">提交成功！你提交了：</p>
+    <p id="json:submit.name">姓名：小明</p>
+    <p id="json:submit.freeday">空闲时间：2023-11-25</p>
+    <p id="json:submit.phone">手机号：10000000000</p>
+    <p id="json:createdAt">服务端提交创建时间：2023-10-25 9:23:22</p>
+</div>
+
+```
+
+或者其他的信息
+
+#### URI在现代的意义
+从刚才的这个例子中，我们可以看到网站的URI,其实慢慢的不止可以指代一个文件了，他更多的是指代一个资源，或者一个业务,向`submit.php`提交一个`POST`请求，难道是在远端创建一个`submit.php`程序？其实在这里更多是指将客户端的数据上传到这个`/api/submit/submit.php`的业务窗口,我们的后端开发，也是建立在这种对虚拟的路径的请求下的。例如我们设计一个报名系统，我们可以设计一个API接口叫做`POST http://api.yourwebsite.io/newVolunteer`,接受浏览器js的报名信息提交，在服务器，根本就没有`/newVolunteer`这个文件，连文件夹都不一定会有,全靠路由在工作（见下篇文章）
+
+### Web应用
+#### WebSocket
+HTTP的动态网站已经很好了，但是协议本身有一个缺点:一个HTTP连接分为请求和响应，只能由客户端发起请求，服务端返回响应，如果客户端没有先发一点什么给服务端的话，服务端是没办法先给客户端发信息的，这就给一些更加复杂的要求增添了障碍：比如通过浏览器和别人聊天，需要接受来自服务器发给你的其他人的聊天的信息；或者是在浏览器上玩游戏，需要和服务器交换数据。这可以通过轮询来解决，但是这样还是不方便。
+
+WebSocket是一个全新的协议，支持客户端和服务器的全双工通信，即客户端和服务器都可以主动地发消息，而且可以同时进行，而且是采用较小的数据帧格式，降低了网络开销，提高了数据传输速度。WebSocket在建立连接后保持长时间有效，不需要为每次消息发送重新建立连接，因此效率更高。
+
+为了兼容HTTP协议，WebSocket也是监听80和443端口(HTTPS),握手采用了HTTP协议，通过升级协议来建立连接，如果可以升级，服务器会返回101状态码，升级连接.
+
+:::info 信息
+
+对于WebSocket过于详细的介绍超出了本篇文章的内容，可以自行了解
+
+:::
+
+##### Server-Sent Events(SSE)
+WebSocket是一个全新的协议，兼容性可能不是那么好，如果要求比较低的话，可以看一看Server-Sent Events,这个协议基于HTTP,允许服务器主动给客户端发送信息，当然也请自行了解。
+
+#### 在Web上运行应用
+传统观念里，一个应用程序是在计算机上直接运行的，但是在介绍了上面的技术之后，我们可以想到，在Web上也是可以运行应用程序的，通过现代的高性能JavaScript运行时，可以提供类似于原生的运行速度，通过WebSocket,可以快速的更新内容，现在的HTML和CSS也足够强大，用户的机器性能也越来越强了，而且，开发Web应用可以直接使用成熟的Web技术栈，在浏览器中运行也更安全，以至于现在很多本地的应用也开始使用Web技术了(electron)。
+
+例如，我们所使用的腾讯文档，支持多人协作编辑，就使用了WebSocket技术来向你主动发送其他人对文档编辑的信息
+
+#### 单页应用(SPA)
+一个现代的网站，或者说一个提供服务的Web应用，流行单页应用架构，顾名思义，服务器只会在用户打开网页时加载一段html文件，后面的全部内容都是通过js动态更新的，js和服务器的后端接口交互主要是采用AJAX,对于某些复杂的需求，可能会需要使用前面的技术，WebSocket或者SSE
+
+`React.js`就是贯彻单页应用思想最彻底的前端框架,单页应用的坏处就是打破了为静态网页文件设计的“收藏”功能和前进后退，也不利于SEO和无障碍，因为用户在网站上只打开一个网页，网页的内容根据用户操作由浏览器脚本动态更新，而生成的html也大多没有做语义化优化，难以被理解和解析
+
+SPA的例子就是邮箱应用（比如Gmail）,通过浏览器访问你的邮箱，通过邮箱的主页面点某个邮件，你并没有进入一个新的页面，而是在原有的页面上，内容变成了邮件查看的界面，如果在主页面上点击发件的话，同样也没有一个发件页面，而是直接呈现发件的UI
+
+有时候，通过AJAX调用API的HTTP交互没办法满足一些需求，比如说服务器主动推送信息，或者流式传输（比如直播平台，游戏等），这个时候就需要使用前面提到的技术，前面的腾讯文档就是一个例子，还有就是网络聊天室（matrix之类），需要向浏览器主动推送信息，还有直播平台，需要将源源不断的多媒体数据传递到用户那里，还有网络游戏需要快速在浏览器和服务器之间交换游戏数据，但是一般这些应用的基础框架都是建立在传统AJAX上的，只是业务部分采用其他协议实现，这些现代的应用慢慢地将计算量转移到了前端，而后端只负责存储和提供，查询数据，甚至后端都不用负责产生html,只需要提供API,来为前端提供数据就行
+
+
+##### WebAssembly
+WebAssembly是最近新出现的技术，他允许开发者将C/C++ , Rust等原本的一些编译型语言编译成浏览器可以执行的字节码，使得在浏览器中也可以执行这些程序，目前也有一些使用WebAssembly的应用，可以去看看，最大的好处就是不会JavaScript也能开发前端，也可以复用以前的代码（当然，这个其实是前端的内容）
+
+## Web后端-是干什么的？
+前面用非常长的一段文字来介绍Web的发展历史，就是为了说明Web后端是干什么的，或者说，编写一个Web后端需要干什么？
+
+如果你想写一个静态网站，那么简单的http服务器就可以满足你，不需要你手动写什么代码；如果你想写一个基于AJAX的服务（比如我们网维现在的报修系统），那么你需要设计好API,和前端沟通好序列化相关事项，或者是返回JSON信息什么的让前端处理，还是返回html让浏览器渲染;如果你想写一个WebSocket的Web应用那就要难一些了，可能需要掌握一些并发编程的知识才可以写出一个可以使用的服务
+
+我们接下来的教程，将注重开发一个现代的AJAX后端服务，同时辅助提供一些静态文件托管的功能。
+
+
+### Web后端的组成
+一个Web后端主要由以下部分组成：
+- 路由(router)
+- 处理(handler)
+- 数据库/ORM
+- 鉴权
+- 模板(如果需要)
+
+详细的信息，请阅读下一篇文章：[Click Me](./基于HTTP的Web后端的组成)
+
+:::tip 提示
+
+读完这篇文章之后，你可以回顾文章里的内容，问一问自己：
+
+- Web经历了哪些发展阶段？
+- 前后端之间是如何使用HTTP协议交互的？
+- AJAX技术是什么？是如何支撑起现代的网页的？(单页应用)
+
+推荐在看下一篇文章之前看看下面的参考文章
+
+:::
+
+## 参考
+在读完这篇文章后，你可以去详细阅读这篇文档：https://developer.mozilla.org/zh-CN/docs/Learn/Server-side/First_steps/Introduction (**强烈推荐！**)
+
+这里是关于HTTP协议的详细介绍：https://developer.mozilla.org/zh-CN/docs/Web/HTTP

docs/devdocs/_legacy/09-培训/02-Web后端/02-基于HTTP的Web后端的组成.md

@@ -0,0 +1,156 @@
+# 基于HTTP的Web后端的组成
+一个基于HTTP的Web后端通常有以下部分组成:
+
+##### 路由系统(router)
+
+路由系统负责处理用户访问网页时的请求路径/方法，并转交给对应的处理者
+
+
+##### 处理者(handler)
+
+处理者负责处理用户的请求，读取用户在URI中的参数，和请求体中的内容（如果有）等，统称为上下文(Context),负责返回请求所对应的回应
+
+有的系统还会继续细分，将业务层和接口层分开(这种情况下通常接口层是和路由功能合并的)
+
+
+_最低要求是这个，另外，通常一个后端系统还需要连接一个数据库:_
+
+
+##### 数据库
+
+通常是兼容SQL协议的关系型数据库，负责存储后端所需要用到和产生的信息
+
+_其实很多后端系统无非就是对数据库的增删改查(所谓的CRUD),可以说这些系统就是数据库的一层方便wrapper_
+
+
+##### 鉴权系统
+
+通常，我们系统的内容不打算对互联网上的任何一个人开放，所以我们需要一些方法来验证访问者的身份
+
+
+
+##### 模板系统（optional）
+
+如果你打算通过后端渲染HTML返回到用户浏览器，那你需要一套模板来方便地将动态内容插入到模板里面返回给用户，如果是一个纯粹API的站点，还是想直接把工作甩给前端，你就可以不用配置模板
+
+
+此外，还有一些外围的工作：
+
+##### 反向代理
+
+通常我们的Web后端服务不是直接暴露对外访问的，而是经过一层代理的转发，这样更加的安全，配置也更加简单，服务只需要监听本地端口
+
+##### 配置系统
+
+你的系统需要读取配置，比如监听端口，数据库连接，还有其他服务的密钥等
+
+##### CI/CD
+
+自动化配置构建，部署，测试等工作，让你专注代码工作，而不用把心思过多地放在部署构建这些工作上面
+
+## 路由
+假设你的一个报名服务架设在`service.io`上：
+
+首先，用户访问这个网址时需要显示一段欢迎文字，然后将他们引导到报名的页面
+
+那么，你应该在用户访问`/`时返回一个html文件，里面含有导向`/volunteer.html`的超链接
+
+`/volunteer.html`里面的前端代码需要以AJAX的形式与后端API交互，比如：
+
+`service.io/api/register`接受POST请求，前端上传报名人的信息，后端录入数据库,并返回录入的信息，全部以JSON序列化
+
+`service.io/api/view`接受GET请求，让这个报名人查看自己的报名信息，返回JSON格式
+
+`service.io/api/cancel`接受POST请求，取消某个报名人的信息，成功则返回相应状态码
+
+`service.io/admin/viewAll`让管理员查看当前的所有报名，接受GET请求
+
+`service.io/admin/cancel`让管理员取消任意的报名,接受的POST
+
+在现代网站设计中，我们不是在根目录下面创建对应的文件（实际上，连根目录都不需要了），我们使用一些叫做“路由器(router)”的模块,当用户通过一定的方法请求一定的路径时，就把这些请求转交到相应的handler
+### URI参数
+参数在正常路径后面，以?开始，以&分割，以键值对的形式存在
+
+例如：`service.io/api/register?name=小明&phone=10000000000&freeday=2024-9-25`
+
+这样的参数可以被许多后端框架使用内置的解析器解析
+
+### 参数化路径
+这种路径通常是配合REST风格的接口来设计的，比如：
+
+`service.io/api/users/小明`
+
+类似于这样的路径，许多后端框架可以使用`service.io/api/users/:user`这样的形式来匹配，在转交给的handler中可以读取`:user`参数，从而返回参数所指定的资源
+### API设计
+API的设计包括了路径的设计和接口格式的设计，一般小项目可以相对地随便一点，但是大项目还是需要认真一点的
+#### 传统
+我们刚才所举的例子就是一个传统的API设计，一个路径就对应了一个业务点，一般只会使用`GET`和`POST`来对应获取和上传，前后端的交互一般在文档里自行约定，或者采用内置的表单(如果数据比较简单的话)
+#### REST
+REST的意思是“表现层状态转换”（英语：Representational State Transfer，缩写：REST），这种风格的要点是一个URI表示一个资源，而不是一个业务，同时充分地利用HTTP方法
+
+例如，我们在前面定义了`Register`,`View`和`Cancel`三个API,如果是要上传什么就用`POST`，获取`GET`,一个路径表示的是一个业务，而不是系统的某个资源，下面来看看REST怎么写：
+
+`POST service.io/api/users/小明` 用户小明提交一个报名，具体的报名信息在请求体里，这将在数据库里面创建一个小明的报名记录
+
+`GET service.io/api/users/小明` 用户小明查看自己的报名信息
+
+`DELETE service.io/api/users/小明` 取消小明的报名
+
+`PUT service.io/api/users/小明` 修改小明的报名信息，新信息放在请求体里面了
+
+可以发现，REST风格的API可以看作是对传统静态网页互联网的回归，这种风格直观简洁，兼容性更好，更加利于缓存等
+
+#### GraphQL
+GraphQL是一种用于API交互的查询语言，他意图解决接口格式定义和多次查询带来的复杂问题
+
+首先，后端需要支持GraphQL,然后，前端需要在API请求中注明自己想后端用什么格式呈现什么想要的信息，这样就不需要前端多次请求不同的业务了
+
+这对大型系统或许比较友好，但是如果只是一些小项目的话，这可能有些复杂，具体可以自己去了解
+## handler
+handler可以说是一个后端系统的核心了，因为他们是实际处理业务的地方
+### 面向对象与模型
+虽然可以使用其他的范式，但是最推荐的是依据OOP的原则，将需要处理的模型写成对象，将一系列操作写成对象的方法
+例如，报名系统本质上就是处理“报名人”这个对象的各种操作，我们可以定义：
+
+```Go
+
+type Volunteer struct{
+    config.DB
+    id      int
+    Name    string
+    Phone   int
+    FreeDay time.Time
+    Note    string
+}
+
+func (v *volunteer)Add()error{
+    if err:=db.addVolunteer(v.MainConnection) err!=nil{
+        return err
+    }
+    return nil
+}
+
+```
+要设计一个登记报名的handler,就只需要将前端发过来的信息反序列化到Volunteer对象里，然后调用Add方法即可，这种思路就叫做面向对象
+
+所设计的Volunteer和他的一系列方法就叫做“模型”
+
+## 数据库
+数据库为后端的业务数据提供了方便的存储和查询服务，这里指的是结构化数据，其他需求可以去看高级教程
+### SQLite
+这是个轻量级的数据库，一个数据库就是一个文件，通常用于业务量比较小的场景或者是本地开发的场景
+### PostgreSQL
+这个可以说是目前最厉害的开源数据库了，不仅提供了常规的结构化功能，而且对于一些简单的非结构化存储需求也可以胜任，但是本身的资源消耗是有点高的
+
+### 选择数据库的各种考量
+- 业务量：如果业务量比较小的话，就使用SQLite吧
+- 兼容性：如果现有的环境和业务依赖于某个数据库，那么就继续用吧
+### ORM
+ORM是对数据库的一层抽象，让你专注于业务逻辑的开发，而不用担心具体的数据库问题，如果对于性能或者其他的方面没有很大的需求的话，建议在你的项目里使用ORM
+## 鉴权
+### Session
+### JWT
+### OAuth2.0
+
+## 模板
+### Jinja2

docs/devdocs/_legacy/09-培训/02-Web后端/03-高级教程.md

@@ -0,0 +1,11 @@
+# 高级教程
+本篇是Web后端的进阶系列文章
+## 缓存
+### 为什么我们需要缓存？
+对于某些需要高频读写的数据，放在数据库中的速度会比较慢，所以我们需要一个缓存俩提供快速访问，这些缓存通常放在内存中，提供最快的访问速度
+### Redis 和 Memcached
+## 消息队列
+
+## 日志与监控
+
+## NoSQL与非结构化数据