目前技术圈的发展速度可谓是有目共睹，尤其是前端，每隔一段时间就出新的技术，可以说让很多初学者非常畏惧，没有一个明确的方向不知道从何学起。

同时也有很多人，只局限于使用手头已掌握的技术，而不愿去尝试新技术。举个例子，如今 vue3 都已经正式发布，但仍还有停留在 vue2 不愿尝试 vue3 的开发者。而 java 都发布 18 版本了，可还有很多人都还使用着 java8，这种现象可以说是非常常见了。

这里说说我个人编码经验与看法，**仅作为个人观点，没别的意思**。



熟悉我的人应该都知道，我对很多新鲜的技术有一种难以用言语表达的情感，又哭又笑。属于是那种看到感兴趣的就会开始尝试，在之前也许更强烈。

驱使我去接触的原因无非就以下几点：

- 开发体验、性能提升
- 对已有技术的厌倦感和对新鲜事物的好奇心
- 更多机会与方向
- 对未来技术趋势有更好的了解

## 写不完的代码

首先要知道一点，在任何的软件开发迭代中都没有最终形态的代码。说白话就是代码都是不断更新的，永远写不出最好的代码。

你能看到如今很多开源项目或者商业项目都在不断新增代码或者功能，除非作者不维护了，不然这份代码可以说写到世界末日。

究其原因还是因为社会不断在发展，硬件升级，性能提升，不断的业务需求。毕竟人都在进步，社会难道还不能进步。所以必然会有新的技术出现，只是出现的时间快慢，与技术难点突破。

## 开发体验、性能提升

毋庸置疑，在购买方面，肯定是买新不买旧，同样的在技术（软件更新）方面也是则从用新不用旧。驱使软件和框架更新的原因也就是新增了某些功能（特性），对用户（开发者）的体验有所提升。一般而言比较少的会存在反向更新的操作，这里除了某些国产软件~~（如某信，某 Q 等等）~~

就我对此的看法也是如此，假设一个开发工具启动花费了 5s 钟启动，而在它的最新版只需要 1s 钟就能够启动，你会选择更新尝试吗？。再比如一个框架原先的代码需要 10 行代码才能实现的功能，由于新版本提供一个语言级别的语法糖，使该功能只需一行。

并且我对开发体验非常在意，尤其是不好用，或者不好配置的东西，我基本秉持能不用就不用的原则，像 vue2 与 webpack 就是这样，我跟愿意使用 vue3 或 vite。诸如此类的替换有非常多，便不一一列举。

要我肯定毫不犹豫的更新去使用，但有些人可能对此提升不是很在意，又或者是升级的成本相对较高，也可能是因为这个开发工具（框架）他用的比较少，更新的意义自然就不大。

## 对代码厌倦和对新事物的好奇心

我写代码时常处于三分钟热度的状态，有些东西可能也就一开始的时候感觉比较新奇，然后就不了了之了。我对此的看法主要还是容易对代码产生厌倦感，不想写代码，不愿意学习。当厌倦感产生了，自然而然就放弃编写，也就是三分钟热度的状态。不过也能侧重体验一点，那就是肯定我对此不是那么感兴趣，既然不是那么感兴趣的东西，又何必在写下去呢？

接着过段时间又遇到了一个新的技术，冲击了我的好奇心，开始尝试。 如此重复，就会发现啥都学了一点，但实际是啥都没学到。但至少，让我肯去学习，而不是在原地踏步。而从心底里就想接触的新鲜事物，每次接触到就能满足自己内心的好奇心，就这一点我便知足了。

### 重构的艺术

如果回头看看自己 1，2 年前写的代码，会发现原来自己也曾写过丑陋不堪的代码，也成为过自己所讨厌的样子。如果这份代码我将来还会用到，那么我就尝试去重构，也许在当时还不支持某种特性，代码就无法简化。基于现有的水平，便会发现很多代码都有可改善的地方，可以化繁为简。代码重构属于将杂乱摆放的东西，收拾的整整齐齐的样子。重构是在提升观赏度和舒适度的同时，还减少 bug 的诱发概率。

> 在编程语言级别水平上，也就是我为什么会想去使用最新的版本（ES2022，TypeScript 4.9），即便是兼容性的问题，我也会去使用，就是因为能够满足我对代码的舒适度，这便足以。

### 生态与解决问题方面

我是很感谢新技术的出现，他实实在在的解决了一些我已有的痛点，提升了我的开发体验。当然它也让我踩了无数的坑，也折磨过我。但不可否认的是，我的自我解决问题的能力也在不断提升，如果我学的是一门比较流行的技术，那么我所遇到的问题，很有可能别人也遇到过，并将他的解决方案分享出来。而我就很容易根据报错描述找他的解决方案来解决我的问题。但在新技术下，用的人自然而然就少了，所分享的问题解决方案也就少了，所以在这种环境下，我就需要自行翻看源码，查阅文档，提出 issues 才能够解决问题。自然而然解决问题的能力也就有所提升。

像流行框架能有这么有问题解决方案，就是因为强大的生态，同时这也是生态好处之一。

> 因此也有很多人顾忌使用新技术，就是因为遇到问题不知如何解决。包括我也是，但通常我会观察一段时间，等成熟了我才去尝试，而不是直接上手，避免踩一些不必要且耗时的坑。

### 总是活在舒适圈

在圈内有着熟悉的环境，与认识的人相处，做自己会做的事，所以会感到很轻松、很自在。但是当踏出这个圈子的界限的时候，就马上会面对不熟悉的变化与挑战，因而感到不舒适，很自然的想要退回到舒适圈内。

我在阅读英文博客的时候，我也时常感到不舒适，阅读不下去。我也很想回到舒适圈，使用翻译软件来翻译但是这样就会导致我非常依赖翻译软件，就间接失去了一次英文环境与英语能力的提升。

长时间待在舒适圈，会让自己过得很舒服，但是却很难提升自己。不过想想也是，**提升的过程不就是苦尽甘来**。

以目前来看有一种这样的学习趋势，别人学什么，当下什么技术火，就去学什么。我其实特别反感这种现象，也不推崇这种学习理念。我会做出我的解释：

首先，什么技术会火就学什么，这固然没什么问题，如果一门技术没有热度，没有生态，那么学了的意义不大，一是难有长久稳定的技术发展，二是不能将技术变现。而绝大多数人之所以选择火的技术，有很大一点是因为有前人给他铺了很多“路”，如学习指南，思维导图，视频教程仿佛跟着学就能成为编程大牛似的。可一旦没有这些，就不知道该如何下手。始终都是跟着别人步伐学习，思维很难扩散出去。

并且这种现象必然会导致内卷，首先看看国内的技术，Vue 和 Spring boot 的可以说 10 个 web 开发程序员中有 8 个技术栈是这套，比麻花还是卷了，可薪资呢？

这里我并不想贴相关的薪资图片，你完全可以自行去了解，但是我可以肯定且直接告诉你，React 的薪资普遍会比 Vue 高上一截，而 Java 后端开发，如果技术只停留在 CRUD 的层面，工资普遍也高不了多少。

**如果你不去拓展自身的技术栈，不多去了解一些未来的可能会火的技术，还停留在当下，活在舒适圈。那么薪资大概率不变，并且自身会有很大被劝退的概率。**

与时俱进，这是我认为不断学习新技术，提升自身技术栈，非常重要的一点。**过得舒服，反而过得难受**

## 更多的机会与方向

技术更新迭代越来，也带来越多的机会，这对于接触前端的我感到尤为明显。假设当下又出了某某技术，那么必然会引起软件开发者的关注，于此同时就带来了维护者，贡献者，甚至是一些金主投资商。像 [Tailwind CSS](https://tailwindcss.com) 与 [Vercel](https://vercel.com/) 就是一个很好的例子，两个前端明星项目，有兴趣可以了解它们的故事。

**不过这种机会在国内不太多见，反而在国外特别普遍。**

但必须要承认的一个事实，如今技术发展过于迅猛，加上目前就业行情不容乐观，当别人了解过的东西，你却不了解，那么别人所能遇到的机会自然就比你多。说的难听点也就是没有对技术提升的想法，今后项目迭代的过程中使用到一些前沿技术就难以胜任。

### 没有目标的学习，等同于乱学

**没有一个明确的目标，学任何（新）技术都是乱学，充其量也就只比不学好一点。**

这在我初学阶段尤为明显，我一开始也不清楚我以后会从事什么行业，可以说是什么都乱学一顿。在我的一篇年终总结 [2019.7-2020.7 编程年记](/blog/2020-year-end-summary) 中可以说是尤为明显，尤其是在 [定一下明年的目标](/blog/2020-year-end-summary#定一下明年的目标) 的段落中，最后我真正深入学习的也就是只有 Web 开发。

我相信很多初学者也会遇到类似的问题，不知道学什么，想学好找工作的但是薪资不高，想学感兴趣的但又不知如何下手。说实话，要我回到当初，我也难以抉择。也有可能处于摆烂状态或是乱学一同，到头来啥都会一点点，但是又好像啥也不会的样子。

这里我是奉劝先定一个短期的目标，为了这个目标我要去学习哪些技术知识。这里就说我未来一年的目标为例：我未来一年想写开源项目，为开源社区做一份微薄贡献，乃至从事开源行业。那么我就需要了解写开源我需要那些预备知识，例如 Github 的使用，项目规范，英文交流等对应开源项目的技能知识，这才是我所该学的，并且能够实实在在用到的，且对我未来有用的。

## 对未来技术趋势有更好的了解

**当你了解的技术越多，你就越能知道自己适合哪些技术。**并且当你去尝试过后，更能加深你对某个技术的信仰。

在未来技术只会越来越多，因为当下要解决太多问题，有太多的业务需求开发。只要不断有需求，就不断会有技术更新。但技术更新必然是朝着好的方向去发展，即技术趋势方向。而了解的越多，能看到技术趋势也就更远，方向就更难偏移。

像我目前就比较看好未来 js/ts 的发展，这也是使我从逆向和爬虫转到 Web 开发行业上，并且将会长期发展下去。

但很多程序员就缺乏这种对**技术的认可**，甚至眼光比较浅薄，认为自己当下所学的就足以，可没却从未到真正的”外面”去看过。

当有了对未来技术趋势的了解，自身就有相对明确的目标学习，而不是漫无目的学习，跟风学习。

## 我是如何了解到这些技术的？

也许有些人并不在意新技术是否学习，而是好奇我是如何知道这些技术的。这个问题非常好，我自己简单总结通过那些途径来获取到这些相关技术的新闻。

主要有以下几种来源：

- 多加技术群，不定时看群聊
- **多刷技术大佬文章（推特），或者是技术公众号和掘金（最多的也是最有效的）**
- 订阅一些技术周刊，或订阅某个项目

没啥技巧，就靠刷技术文章，自然而然的了解也就越来越多了。

尤其是第二点，也是我了解这些新技术的最直接途径。与其自己去主动了解新的技术，将刷抖音的时间改成刷技术文章，了解新技术就是分分钟的事情。可以说我写博客是因为这个契机，记录自己用到的技术的开发过程，并分享个人的开发体验，让更多人了解到这些新技术。

## 面对新技术该怎么学？

其实更多时候是比较在意如何去学一门新技术，而不是找一门新技术，当阅历多了，技术自然就了解的多。这里我分享下我对于新技术是如何起步与学习的。

首先我会列举出我近期感兴趣的技术，这一步很关键，我当然不可能每个技术都去尝试一遍，时间精力根本不够。通常在我了解到这个技术的时候，比如文章与视频中，都会介绍到这个的优点与用法，这就足以了。

但想要进一步的学习，还是得依靠实战项目（至少我都是通过实战项目来学习的），这时候我会看看手头的项目，看看有没有能够基于上面所列举出的新技术升级的想法，如果有的话，那正好就当重构与新技术的学习，这是最好的，也是相对比较节省时间的。

但如果没有的话，我通常是会考虑另写一个项目，而这个项目可能是某个灵感的实现，也可能是久违想写的项目，或者是复刻某个感兴趣的站点，总之从上面所列举出来的技术中去选择一个来进行实践。在项目实践中去尝试使用这些新技术，哪怕只是实现一个简单的 demo，也总比单纯的刷文档，看代码来的有效。

**在项目实践中学习，永远是最直接也是最有效的**。回想你编写课设或者工作的项目，是不是在项目开发中进步的最快？如果这时候还有点时间紧迫感，进步反而会更快。（当然焦虑和压力也会随之提升）

## 最后感悟

关于本文，必然有引来一些不同看法与见解，每个人都有对不同事物的理解，我只是将我对新技术的看法，以文章的方式输出出来。本文并未带有任何的技术的偏见，我对任何技术都保持一视同仁，并且愿意去尝试学习。

不必抱怨新技术发展的过快，自己来不及学，学不完。或者担心自己学的东西在未来将会淘汰，等同于白学。学习过程就是一个非常好的经验总结，当你回顾整个学习过程，其实都没有白学。反而多一次的学习过程，在未来学习新的东西时，学习的成效也会显著提升。保持不断学习，就永远来的及学习。

更多时候，不应该只学如何使用，而是该想想这东西是在什么样的契机下如何被创造出来的，解决了什么问题。而这个问题在未来有没有什么更好的解决方案可替代，如果有更好的解决方案，那么必将又将发展出新的技术来更好的解决这个问题。这在我曾经的学习中，我是从未考虑到的，只专注于学习，而没去了解为什么。

我是希望越来越多的新技术出现，无论它是为了解决什么，必然能解决某些人的一些需求，那么它的出现就很有意义。至于未来该技术和相关生态发展如何，不得而知。也没人敢笃定未来这个技术必定会火，就去学这门技术。绝大大多情况下都是比较看好这门技术，认为未来可期，同时又感兴趣，就开始学习并使用。

深谈个人对新技术的看法

如果你的项目要长期使用并维护的话，那么代码自动测试就非常有必要使用。因为没人能保证在修改代码后，不会引发其他额外 bug（功能失效，渲染失败），而在修改完代码后，跑一遍测试就能很大程度让开发者发现自己所修改的代码是否存在问题，是否会导致原有功能失效。

尤其是在其他人接手这个项目时，诱发 bug 的概率自然也就更高（因为他有很大的可能不知道这部分代码的上下文的功能用途），所以这也就是为什么很多开源项目与大型企业的公司都会使用自动化测试，以及要求一定的代码覆盖率。

当然如果项目不是长期维护的，那么完全没必要编写测试代码，这么做无疑是在浪费开发者的时间。



## 适合引入自动化测试的场景

提前简单总结下**适合引入自动化测试的场景（优点）**：

- 中长期项目迭代/重构（需要频繁的修改代码）

- 准确定位代码问题，提高代码质量

- 引用了不可控的第三方依赖，极易发生 bug（例：beta 版相关的包）

测试的目的在于，**及时发现错误，提高代码质量和开发效率，避免存在 BUG 的代码发布上线造成损失**。

自动化测试要注意的点

- 并不是所有项目都适合引入自动化测试，反而会增加一定代码成本

- 如果项目开发阶段还不稳定，那么手动测试效率会比自动化测试更好

- 有些代码可能这辈子都不会在碰第二次，就没有编写自动化测试的意义

**在代码编写阶段，建议只对重点功能进行测试，没必要一定追求过高的测试覆盖率**。注意，是编写阶段

## 测试思想

### TDD：Test-Driven Development（测试驱动开发）

- TDD：Test-Driven Development（测试驱动开发）：TDD 则要求在编写某个功能的代码之前先编写测试代码，然后只编写使测试通过的功能代码，通过测试来推动整个开发的进行

### BDD：Behavior-Driven Development（行为驱动开发）

- BDD：Behavior-Driven Development（行为驱动开发）：BDD 可以让项目成员（甚至是不懂编程的）使用自然语言来描述系统功能和业务逻辑，从而根据这些描述步骤进行系统自动化的测试

## 自动化测试类型

测试类型有以下几种：

- **单元测试（Unit Testing）**

  代码中多个组件共用的工具类库、多个组件共用的子组件等。通常情况下，在公共函数/组件中一定要有单元测试来保证代码能够正常工作。单元测试也应该是项目中数量最多、覆盖率最高的。

- **集成测试（Integration Testing）**

  测试经过单元测试后的各个模块组合在一起是否能正常工作。会对组合之后的代码整体暴露在外接口进行测试，查看组合后的代码工作是否符合预期。集成测试是安全感较高的测试，能很大程度提升开发者的信心，集成测试用例设计合理且测试都通过能够很大程度保证产品符合预期。

- **UI 测试 （UI Testing）**

  对于前端的测试，是脱离真实后端环境的，仅仅只是将前端放在真实环境中运行，而后端和数据都应该使用 Mock 的。

- **端对端测试（End-to-End Testing）**

  将整个应用放到真实的环境中运行，包括数据在内也是需要使用真实的。

关于测试框架，我主要使用 [Vitest](https://vitest.dev/) 与 [Cypress](https://cypress.io/)。这两个作为测试框架都相对比较新，并且性能与开发上会比 [Jest](https://jestjs.io/)，[Puppeteer](https://pptr.dev/) 来的好。本文的一些测试示例也是基于这两类框架之上。

:::note 其实还有个接口测试，不过这就不是前端要关心的内容了，所以就没列举在这上面。

:::

## 自动化测试的误区

自动化测试和普通说的测试是有些不大一样的，有很多测试，其实都不能归类为前端自动化测试。这里我会举个例子来说明一下。

在自动化测试来说有个要求：**自动化测试要的不是某次测试执行的是否通过，而是每次执行都必须通过。**

怎么理解这句话呢：比方说我要测试获取博客列表的函数，假设实际的接口失效了，那么就会导致结果与预期不一致，就会导致代码测试不通过。既然不通过，那我就要去查看为什么不通过。当我点击这个单元测试的时，发现原来是后端接口失效了。可万一哪天这个接口突然好了，又或者发现刚刚原来没插网线导致的请求失败导致测试不通过。像这些 **不稳定因素** 在前端自动化测试中就会使用 mock 的方式，强制返回一定格式的数据给测试框架。到这里你可能会好奇，为什么要这么做？

想想看，如果因为接口失效导致测试失败，是因为测试代码的问题吗？那跟测试代码有毛关系，明显是后端或者服务器的问题。我们要测试的是**获取博客列表的函数，而不是在测试接口（接口自动化测试）**。测试接口不应该是前端要做的事情。确保后端返回正确的响应结果，前端能够对这些数据进行处理渲染，这才是我们要做的。

**每次测试都存在不可控的因素，就会导致每次测试结果都有可能不同，这就违背测试的意义了。** 所以这也就是为什么要数据 mock 的原因了。

**给测试输入的值，在经过测试后，要保证输出的值与我们预期想要结果的值相同。**

## 自动化测试到底在测试什么？

其实目前前端有个尴尬的点，目前绝大部分实际业务项目里，前端的单元测试都没啥鸟用，UI 自动测试又太难搞。

这就导致很多开发者不清楚到底要测试什么，导致对测试特别不重视，包括我一开始也是如此。看到很多文章都是在演示测试 1+1 =2，介绍测试框架，很少从实际项目中出发进行测试。不过原因无非就是实际项目写的少，就别说测试代码了。再不然就是写过的代码都不怎么维护（重构，阅读），自然的就不会去写测试了。

不过确实没什么好举例的，因为太多东西可以写成单元测试了，比方说`formatTime.test.ts`, `param2Obj.test.ts`,`validate.test.ts`，从文件名就知道在测试什么了，就看开发者想不想写的问题了。

可以到 [vitest-dev/vitest](https://github.com/vitest-dev/vitest 'vitest-dev/vitest') / [facebook/jest](https://github.com/facebook/jest) 等测试框架中的 example 中查看测试案例。

关于 UI 测试和 e2e 测试，我非常推荐看看 cypress 的[Todo 示例](https://example.cypress.io/todo 'Todo示例')，测试的特别清楚，这里放张官方测试结果供参考。

![](https://img.kuizuo.cn/image_a_B5FPFfJI.png)

这里补充一句，vitest 是能做 UI 测试的，可以通过 [vuejs/test-utils](https://github.com/vuejs/test-utils 'vuejs/test-utils') 库来实现，但是 vitest 的运行环境是 nodejs，通过 jsdom 等库来模拟浏览器环境，而 cypress 是实实在在的运行在浏览器上，而且有可视化页面操作。这两者的区别也就是运行时环境的区别，有些实际场景对真实环境是有需求的，所以针对 UI 测试更多会选择像 cypress 这种直接运行在浏览器的测试框架。

## 为何我开始重视起测试?

在之前我根本不会在意测试，就连已有的测试代码我都不会尝试运行。就在前段时间我正重构我的一个项目时，但当我写了一大部分的代码后，我尝试运行发现有些功能失效了。于是我进一步的排查，终于找到我修改代码并还原成我原来的代码。

假设一开始有份完整的测试代码，当我修改一部分代码后，跑一遍测试查看测试情况。发现没问题后，再开始下一步的代码工作，反复测试，直到最终重构完毕。**与其浪费代码的时间，不如将这些时间去用来完善测试代码**。不仅自己后续使用需要，到时候项目交付给别人的时，别人也不至于修改你的代码时兢兢业业。

**究其原因是为了保证代码质量**。

当然，虽说重视，但我也不会立马为已有的项目增加测试.耗时且费力不讨好。更多时候只会在准备重构的项目，或者是新项目上去增加测试代码。

编写这篇文章主要解惑我自己对往常对测试的看法，也借此机会养成 TDD 模式的开发的习惯。

## 参考文章

[试试前端自动化测试！（基础篇） - 掘金 (juejin.cn)](https://juejin.cn/post/6844904194600599560)

前端测试

之前搭建过 Gitlab，但是就只是搭建而已，并未实际使用，因为我大部分的代码还是存放在 [Github](https://github.com/kuizuo?tab=repositories) 上。

并且大部分项目都是在 [Vercel](https://vercel.com) 上运行的（Vercel 是真好用），但是最近国内访问 vercel 情况不容乐观，貌似被墙了呜呜。然后 Gitlab 的资源占用非常严重，几乎占用了一半的服务器性能，可 [点我](https://kuizuo.cn/gitlab-code-management-environment#运行状态) 查看运行状态。与此同时，随着很多私有项目越来越多，使用 git 私有仓库以及 Vercel 部署，肯定不如自建私有 git 服务和自有服务器部署使用体验来好。

于是就想搭建一个轻量级仓库，同时支持 CI/CD。经过一番的调研，决定使用 Gitea 和 Drone 作为解决方案。



## Gitea

[Gitea](https://gitea.io/zh-cn/ 'Gitea') 是一个开源社区驱动的轻量级代码托管解决方案，后端采用 [Go](https://golang.org/ 'Go') 编写，采用 [MIT](https://github.com/go-gitea/gitea/blob/master/LICENSE 'MIT') 许可证.

你可以在 [横向对比 Gitea 与其它 Git 托管工具](https://docs.gitea.io/zh-cn/comparison/#横向对比-gitea-与其它-git-托管工具 '横向对比 Gitea 与其它 Git 托管工具') 查看 gitea 与其他 git 工具的优势与缺陷。

### 安装

这里我选用 Docker 进行安装，安装文档可在[官方文档](https://docs.gitea.io/zh-cn/ '官方文档')中查看其他安装方式

```yaml title='docker-compose.yml' icon='logos:docker-icon'
version: '3'

networks:
  gitea:
    external: false

volumes:
  gitea:
    driver: local

services:
  server:
    image: gitea/gitea:1.17.1
    container_name: gitea
    environment:
      - USER_UID=1000
      - USER_GID=1000
    restart: always
    networks:
      - gitea
    volumes:
      - gitea:/data
      - /etc/timezone:/etc/timezone:ro
      - /etc/localtime:/etc/localtime:ro
    ports:
      - '10800:3000'
      - '2221:22'
```

根据自身需求配置 docker-compose.yml 内容。运行 `docker-compose up` 等待部署

服务器防火墙与云服务安全组都需要开放端口才可访问，`服务器ip:10800`，将会出现如下界面

![](https://img.kuizuo.cn/image_8ix-AMvt3t.png)

**因为修改配置相对比较麻烦，所以在首次安装的时候，请根据实际需求进行配置安装。**

### 修改配置

假设要修改其中的配置的话，gitea 的后台管理面板是无法直接修改的。需要到 `/data/gitea/conf/app.ini` 中修改，具体修改的配置 参阅 [自定义 Gitea 配置 - Docs](https://docs.gitea.io/zh-cn/customizing-gitea/ '自定义 Gitea 配置 - Docs')

:::warning 必须完全重启 Gitea 以使配置生效。

:::

### 迁移仓库

从其他第三方 git 仓库迁移到 gitea，可以访问[https://git.kuizuo.cn/repo/migrate](https://git.kuizuo.cn/repo/migrate 'https://git.kuizuo.cn/repo/migrate') 来迁移仓库

![](https://img.kuizuo.cn/image_sRQV5hAKUh.png)

稍等片刻，取决于访问 github 仓库的速度。有可能还会迁移失败，就像下面这样。

![](https://img.kuizuo.cn/image_X9IpG2q36n.png)

所以可以申请访问令牌（Access Token），在 [New Personal Access Token](https://github.com/settings/tokens/new 'New Personal Access Token') 处创建。迁移成功后，如下图所示

![](https://img.kuizuo.cn/image_Rug0AmD8GE.png)

### 镜像仓库

很大部分时间，gitea 只能作为我的副仓库，或者说 github 的镜像仓库。

gitea 也提供镜像仓库的方案，官方文档[Repository Mirror](https://docs.gitea.io/en-us/repo-mirror/ 'Repository Mirror')

![](https://img.kuizuo.cn/image_Q5IaHnKCYJ.png)

## Drone

由于 Gitea 并没有内置 CI/CD（持续集成/持续部署） 的解决方案，所以需要配置第三方的，这里推荐使用 Drone CI。

Drone 是面向繁忙开发团队的自助服务持续集成平台。相对于常见的 Jenkins，选中 Drone 的原因在于它非常简洁，不像 Jenkins 那样复杂，同时它拥有可以满足基本需求的能力，并且提供了许多实用的[插件](https://plugins.drone.io/)，如 GitHub，Email，微信，钉钉等

### 安装

由于我们使用了 gitea，所以 drone 中选择 gitea 来安装，这是官方文档 [Gitea | Drone](https://docs.drone.io/server/provider/gitea/ 'Gitea | Drone')，照着操作即可。

需要安装 Server 和 Runner，一个是 Drone 的服务，另一个用于检测 Git 记录，以重新构建项目。

这里贴下 drone 的 docker 配置（根据文档和自己部署的 git 服务配置来替换）。

```yaml title='server'
docker run \ --volume=/var/lib/drone:/data \ --env=DRONE_GITEA_SERVER=https://try.gitea.io \ --env=DRONE_GITEA_CLIENT_ID=05136e57d80189bef462 \ --env=DRONE_GITEA_CLIENT_SECRET=7c229228a77d2cbddaa61ddc78d45e \ --env=DRONE_RPC_SECRET=super-duper-secret \ --env=DRONE_SERVER_HOST=drone.company.com \ --env=DRONE_SERVER_PROTO=https \ --publish=80:80 \ --publish=443:443 \ --restart=always \ --detach=true \ --name=drone \ drone/drone:2
```

```yaml title='runner'
docker run --detach \ --volume=/var/run/docker.sock:/var/run/docker.sock \ --env=DRONE_RPC_PROTO=https \ --env=DRONE_RPC_HOST=drone.company.com \ --env=DRONE_RPC_SECRET=super-duper-secret \ --env=DRONE_RUNNER_CAPACITY=2 \ --env=DRONE_RUNNER_NAME=my-first-runner \ --publish=3000:3000 \ --restart=always \ --name=runner \ drone/drone-runner-docker:1
```

查看连接情况

```bash
docker logs runner
```

执行完毕后，然后访问线上的 drone 服务，点击 CONTINUE 将会跳转到你的 Git 授权页面

![](https://img.kuizuo.cn/image_rUdNHPlB73.png)

点击应用授权，再次回到 drone，此时页面 Dashboard 列出了 gitea 的所有仓库（如果没有的话，可以点击右上角的 SYNC 来同步）。

![](https://img.kuizuo.cn/image_TXWZgDOhrQ.png)

## 实战

上述只是安装了，我们还需要编写 `.drone.yml` 配置文件来告诉 drone 我们要做什么，编写过程与 Github Action 类似。相关文档: [Pipeline | Drone](https://docs.drone.io/pipeline/overview/ 'Overview | Drone')

### 部署前端项目

这里就选用 [antfu/vitesse](https://github.com/antfu/vitesse 'antfu/vitesse') 作为演示。这里省略 clone 仓库的步骤。进入到自己的 gitea 仓库，然后添加 `.drone.yml` 文件，内容如下：

```yaml title='.drone.yml' icon='logos:drone-icon'
kind: pipeline
type: docker
name: ci

steps:
  - name: install & build
    image: node
    commands:
      - npm config set registry http://mirrors.cloud.tencent.com/npm/
      - npm i -g pnpm
      - pnpm i
      - pnpm run build

  - name: upload
    image: appleboy/drone-scp
    settings:
      host:
        from_secret: host
      username:
        from_secret: username
      password:
        from_secret: password
      port: 22
      command_timeout: 2m
      target: /www/wwwroot/${DRONE_REPO_OWNER}/${DRONE_REPO_NAME}
      source:
        - ./dist
```

这里对 `.drone.yml` 配置进行详解：

其中 build 这个不用多说，与 node 构建相关的，不过多介绍。

upload 则使用[appleboy/drone-scp](https://plugins.drone.io/plugins/scp 'appleboy/drone-scp')插件，可以将构建出来的文件通过发送到服务器指定位置。在这里 source 对应就是构建的文件，target 则是要移动的位置，这里的 `/www/wwwroot/${DRONE_REPO_OWNER}/${DRONE_REPO_NAME}` 对应本项目为 `/www/wwwroot/kuizuo/vitesse`。此外 ssh 的 host，username，password 或 key，都作为环境变量（私有变量的方式传递，这在 drone 的控制台中可以设置）。

由于每次构建可能需要删除原有的已部署的资源文件，那么可以使用 [appleboy/drone-ssh](https://plugins.drone.io/plugins/ssh) 插件来执行终端命令来删除，例如

```yaml title='.drone.yml' icon='logos:drone-icon'
kind: pipeline
name: default

steps:
  - name: deploy
    image: appleboy/drone-ssh
    environment:
      DEPLOY_PATH:
        from_secret: /www/wwwroot/${DRONE_REPO_OWNER}/${DRONE_REPO_NAME}
    settings:
      host:
        from_secret: host
      username:
        from_secret: username
      password:
        from_secret: password
      port: 22
      command_timeout: 2m
      envs: [DEPLOY_PATH]
      script:
        - rm -rf $${DEPLOY_PATH}
```

具体就因人而异了，这里我仅作为演示。

大致介绍完毕（其实已经介绍差不多了），有关更多插件可以参阅 [drone 插件](https://plugins.drone.io 'drone 插件')。这里开始演示，进入 drone 页面，找到仓库，默认情况下，所有仓库都处于未激活状态。

![](https://img.kuizuo.cn/image_6XBrsAY8VE.png)

点击 `ACTIVATE REPOSITORY` 根据选项选择，点击右上角的`NEW BUILD`选择分支，添加 drone 环境变量（私有变量），即上面的 from_secret 后面的内容（host，username，password），即可开始运行。

![](https://img.kuizuo.cn/image_PAM6QQS1V_.png)

静等 PIPELINE 执行完毕，结果如下

![image-20220928152635955](https://img.kuizuo.cn/image-20220928152635955.png)

此时打开宝塔，跳转到指定目录下，就可以看到构建的内容都已经放到指定位置了

![image-20220928152725853](https://img.kuizuo.cn/image-20220928152725853.png)

这时候只需要配置下 nginx，就能将页面展示到公网上，这里就不在这里赘述。当完成上述配置完毕后，每次只需要 pull request，drone 就会自动拉取 gitea 的代码，并开始执行`.drone.yml`中的任务。

## 参考文章

[【CI/CD】搭建 drone 服务，构建前端 cicd 工作流，实现博客的自动化打包并部署 - 掘金 (juejin.cn)](https://juejin.cn/post/7073380337766072350 '【CI/CD】搭建drone服务，构建前端cicd工作流，实现博客的自动化打包并部署 - 掘金 (juejin.cn)')

[单机部署 CI/CD 进阶版：宝塔+gitea+drone | Laravel China 社区 (learnku.com)](https://learnku.com/articles/71333)

Gitea 与 Drone 实践

前段时间看了别人的一个写了羊了个羊刷次数网页版，但是 js 代码做了混淆，然后我的那个解混淆的工具还没适配上，短时间内还原不了。但由于是网页版，所以抓包数据还是能看到的，于是就准备复刻了一个。

可在此体验：[7y8y.vercel.app](https://7y8y.vercel.app) （当然由于官方改动，现在功能已经失效了，但看看页面到不成问题，可能需要科学上网）

原本我是不考虑写的，但是这背后所涉及到的技术以及技术框架我是特别想聊聊，加之以后我也有很大的可能会再写一个类似的刷 xx 的网页版，所以就考虑写一个类似的模板以便后续应用需求。

与此同时，我也快有半年的时间没碰 **协议复现**（网络通信协议重新实现，后文都简称协议复现）。我更喜欢说这个词，也有的人会说**模拟请求**，对应的关键词可能有 post 请求，抓包，发包，爬虫等等，但大致的意思是**抓取请求数据包，然后脱离宿主机（浏览器，手机），将抓取的数据包重新发送一遍**。

你也可以理解成爬虫，但和爬虫相比，要做的不只是爬取数据，而是要基于某些请求包（或者说调用他人不提供的 api 接口，即爬取），来实现一定的功能。比如登录协议，签到协议，抢购协议，游戏封包等等，然后不依靠宿主机（即不用登录浏览器或者应用设备）就能实现诸如登录，签到等功能（在后台记录是有的）。因为这些都是基于网络通信协议的，只要抓包（抓取数据包），然后使用编程提供的网络请求模块来模拟请求，达到重新发包，重新请求的目的。在网页中有 http 协议，websocket 协议，而游戏中有相应的与游戏服务器对应的协议，邮件短信文件又是不同的协议（这里的协议都叫网络通信协议），所以我个人更倾向于称之为协议复现。

所以要做协议复现，那基本上有一定的逆向功底和爬虫能力，还有网络通信协议相关的知识了。此次的开发也算是回顾下这些相关技术了。



## 小区开门应用

在这里容我多废话几句，讲一个我之前的一次开发经历，可以说这次的开发经历算是这篇文章的由来。

### 应用需求

在之前住的一个小区，有个门禁系统，需要安装一个开门的 app（后文都称开门 app），然后注册一个账号到物业那边登记为户主或家庭成员。

每次开门的时候，都需要打开这个开门 app，然后点击你要打开的门，接着门就打开了。或者叫保安开个门，总之就是特别麻烦，还不提供创建应用快捷方式。

于是我想的是将接口数据“偷”了过来，将大门列表展示在前端上，然后点击对应的大门，然后将大门 id 转发给原 app 的服务器，就实现了开门的效果，也就是这个小区开门的网页版的核心逻辑。

当时设计的界面大致如下，展示小区的大门，点击即可远程开门。

![](https://img.kuizuo.cn/image_Zv0hXU8h1j.png)

因为是网页版的，所以只需要在浏览器打开对应的网址，点击对应的大门按钮即可。而开发的初衷是这个 app 不提供桌面快捷方式，点击这个 app 还需要观看首屏广告，此外他人也不用到物业登记，就能开门，对于一些朋友或者住户来说，省去了物业登记的繁琐。

不过这个软件还是有挺多要注意的点：首先就是鉴权了，由于我当时主要目的是为了我自己和身边朋友，网站也没有特意发布到互联网上，所以就没做鉴权相关的，不然正常情况下是一定要做鉴权和调用记录的，以及 ip 白名单的。否则搞不好登录原 app 的账号直接因为调用过于频繁直接给禁用了；最主要的安全问题，这里的安全可不只是网站的安全，而是现实的安全。想想如果有一个可以随意进出小区大门的程序，那么任何人都可以进入这个小区，小区的公共设施，业主生活质量安全等等谁来保障？而且最主要所绑定的账号还是我的，万一小区真出了事，那么我的责任将会非常大。

综合考量，这个应用是绝对不可能大肆发布到网上的。个人自用问题还是不大，因为这种调用量对服务器几乎没有什么压力。

在当时我甚至想基于手机的 GPS 定位，来实现靠近小区自动开门。真羡慕当时我的一堆想法，但也遗憾当时没有去尝试实现这一个想法。

### 开发

这个应用的起源就说到这了，接下来我要说说其开发形态了，这也就是本文说要的重点内容了。下面是我当时的项目结构：

![](https://img.kuizuo.cn/image_7J7PhsdaQy.png)

不难看出，这是一个前后端分离的项目，其中前端使用 uniapp 来开发一套代码多端运行，并且使用的是 Hbuilder 编辑器来开发。而后端就是常规的 Node 后端服务，使用的是 Express 框架。

技术栈就介绍完毕，这里我要介绍整个开门实现流程。

就说说获取大门列表和开门的两个接口请求：

#### 获取大门列表

后端接口：`http://localhost:3000/api/list`

这个接口主要的作用就是获取原开门 app 的大门列表，这里简单介绍下代码

```javascript
router.get('/list', async (req, res, next) => {
  // 模拟请求获取所有大门数据
  let url = `https://xxx.com/api/getDoorList`
  let data = {
    xxx: {},
  }

  let json = await (await axios.post(url, data)).data

  return json // [{...},{...},{...}]
})
```

然后前端请求后，将列表数据渲染到页面上。

#### 开门请求

后端接口：`http://localhost:3000/api/open`

```javascript
router.get('/open', async (req, res, next) => {
  let { id } = req.query

  // 模拟请求开门
  let url = `https://xxx.com/api/openDoorControl`
  let data = {
    id: id,
  }

  let json = await (await axios.post(url, data)).data

  return json // { "code": 0 ,"msg": "success" }
})
```

这里的代码也仅仅只是作为演示，实际代码可不止这么简单，因为还需要涉及到登录，加密等等环节。

我的前端页面访问地址是 [http://localhost:5000](http://localhost:5000)，我需要访问后端接口 [http://localhost:3000/api/list](http://localhost:3000/api/list) 和 [http://localhost:3000/api/openDoor](http://localhost:3000/api/openDoor)。

对于不了解 web 开发的人员可能会问为啥要后端服务，不直接在前端向开门 app 的服务器发送请求，然后将响应直接渲染到前端上。比如直接在前端代码中写 openopenDoor 函数

```javascript
async function openDoor(id) {

  // 模拟请求开门
  let url = `https://xxx.com/api/openDoorControl`
  let data = {
    id: id
  }

  let json = await (await axios.post(url, data)).data

  return json // { "code": 0 ,"msg": "success" }
})
```

这个疑惑在我初次想使用 web 端来实现协议复现的时候也考虑过，但浏览器为了安全考虑而不支持。这也是我下面所要说的

### 同源策略 跨域

一般用户的浏览器是有非常强的页面安全策略的，这里要说的就是同源策略，更细分点就是跨域。比如说 kuizuo.cn 这个站点，想要向 baidu.com 发送请求，请求是能够正常发送过去的，但是 kuizuo.cn 这个站点是接收不到任何数据。因为 kuizuo.cn 和 baidu.com 根本不是同一个网址，专业点说就是不同源，这种不同源的请求在浏览器，称为跨域请求。

![](https://img.kuizuo.cn/image_QLEJFPTkb6.png)

跨域请求如果请求的服务端不允许跨域，即响应协议头没有如下内容

```text
access-control-allow-credentials: true
access-control-allow-headers: Content-Type, Authorization, X-Requested-With
access-control-allow-methods: GET, POST, PUT, DELETE, OPTIONS
access-control-allow-origin: *
```

浏览器会直接拒绝接收响应，但**浏览器确实将请求发送给了服务端**，并且你打开控制台中的网络是看不到该请求的响应结果的。

跨域限制只存在于浏览器端，在其他环境下是不存在，请求都是能够发送出去，并且是可以接收到的。所以说为什么不在前端直接向原应用程序的服务器发送请求，罪魁祸首也就是**同源策略**。

### 不支持修改协议头

像 origin，reference，user-agents 等协议头在浏览器是无法修改的

```text
origin: https://xxx.com
referer: https://xxx.com/api/test
user-agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/105.0.0.0 Safari/537.36 Edg/105.0.1343.42
```

而有些请求是会效验你的设备信息，来源地址，这些内容在浏览器中都写在协议头中，且浏览器不支持修改。使用浏览器来发送数据，无疑就是告诉服务器我是浏览器发送的。服务器判断来源不是自家的域名，那就直接拒绝响应，像防盗链就是检测 referer 。

## 方案

### 桌面端应用开发

正是因为同源策略的限制，导致做协议复现时往往都会选择在本地中直接运行，比如使用易语言，python 等语言，将应用打包成 exe，然后跑在 window 系统上。

![](https://img.kuizuo.cn/image_hyjd395YGI.png)

这样的应用会有以下几点缺陷：

- **易破解**：由于你的大部分核心逻辑最终都会进行编译打包成 exe，如果会些破解技术，恰好你不做任何防护手段，要破解你的程序非常容易。所以也就为什么很多 exe 程序（尤其是易语言）会带有 `.vmp.exe` 后缀也就是 vmp 加壳，让程序很难被分析与破解。并且我就可以开启系统抓包，就可以看到应用程序模拟发送的请求数据包是什么。

- **不易跨平台**：大多数的协议复现都是 exe 桌面应用程序，虽然也有安卓，但一般比较少。对于非 windows 用户或者说手头不方便用电脑的用户就很难体验到，并且还要特意安装一个应用，应用程序更新也需要重新安装。

其实我说的这些，也算是绝大部分都是桌面应用程序的一个“通病”，但也不是没有优点，这在后面介绍后端应用开发的会做一个比较。

### 后端应用开发

另一种方式就是我自行搭建一个后端服务，然后将我要模拟的请求封装成一个接口供外部调用。只要我的这个后端服务允许跨域请求，那么我在浏览器或者在桌面端应用都能调用该接口。这样做调用者根本不可能知到你这个接口返回的数据的核心代码（除非他能渗透你的服务器）。

![](https://img.kuizuo.cn/image_pVEHwQk1AJ.png)

别人像要复现一个相同的协议请求的话，就必须自行抓包分析原站点的数据。而原站点可能做了一定的防护手段，例如验证码 浏览器指纹等风控手段。对于一般人而言，非常难破解。但是假设你能复现该请求的话，又非常不想让别人复现，那么自行搭建一个后端服务封装是最好的手段。而在此基础上，你可以做一些限制，比如接口封装，调用收费等等。

这里我就不细说太多了，但也不是说没有缺点，甚至可以说这个缺点不比桌面端应用好到哪里：

- **部署后端服务**：由于搭建了一个后端服务，那么就需要将后端服务部署到服务器上，部署后端服务是小事（但其实也很麻烦，有些写协议复现也不一定会后端开发），但是需要考虑用户的访问量，可能并发量大，那么请求就可能会阻塞导致响应速度变慢。

- **请求限制**：从上流程图也不难看出，由于后端应用是部署在自己的服务器上，同时需要承载多个接口请求，然后模拟的请求都是由**自己后端应用服务器发送**的，这和桌面端应用不同。桌面端模拟的请求发送是用户自己的电脑，即用户自己电脑的 ip 地址，而后端应用服务器是服务器的 ip。一旦发送的请求多了，必然是会限制请求的，说白了就是将 ip 黑了，无法访问。要解决的最有效的办法就是换 ip，使用一些 ip 代理服务商，在请求 xx 服务器的时候使用动态 ip 来请求，检测被黑 ip 之后就换另一个 ip 来请求，但是这样就需要额外支付一些 ip 的费用。

如果你需要**跨平台**（web 端，桌面端，手机端）并且想要**保护好你的模拟请求的代码**，那么就要考虑选择后端应用开发方案。

像我一开始所介绍的小区开门网页版就是属于这一范围，这里就不再赘述其实现过程了。

### 前端应用开发/反向代理（可行）

假设你手头已经有了某个网站的大部分协议复现的代码接口，但是**不想搭建一个后端应用，却想要在前端中使用**。有没有解决方案，这也是有的。

一种就是通过浏览器插件来允许任何请求跨域，或者本地开启 http 响应替换，将允许跨域的协议头加到响应中。但这些手段都需要使用者有一定的开发能力，对于普通用户而言就无能为力。

目前绝大多数的网站应该都属于前后端分离的形式，后端只提供服务与接口的，提供的接口一般都带有 `/api/` 或 `/v1/` 等请求前缀。那么就可以将前端的请求，通过反向代理，转发到原应用服务器。

反向代理其实也需要服务器，但是和后端应用相比，只需要配置一个 nginx，例如

```text
location /api/ {
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_pass http://要转发的服务器域名/api/;
    index index.html index.htm index.jsp;
}
```

举个例子，原后端应用通过 `http://target.com/api/user/me` 来获取目标服务器用户信息，如果我的前端应用 `http://example.com` 想要请求该接口必然会有跨域限制。但是通过反向代理，我的前端应用可以请求 `http://example.com/api/user/methods`，nginx 会判断 `url` 是否为 `/api/` 前缀，将请求转发给 `http://target.com/API`。说白了请求 `http://example.com/api/user/me` 就是在请求 `http://target.com/api`，同时还不会触发跨域，反向代理也是解决跨域的常用方法之一。

![](https://img.kuizuo.cn/image_PO82fF6A5E.png)

由于请求还是通过服务器发送的，所以后端应用开发有的限制，在反向代理也同样是有的。还有就是对于限制设备请求的服务器，使用这种方案就不行。。。

同时这种开发方案对于多域名的应用来说可能就不是那么友好，因为就需要配置比较多的反向代理，同时只是将接口转发，接口的定制化就不是那么好。**只不过你可以原封不动的将原有的请求迁移到前端**，假设有了某个网站的大部分协议复现的代码接口，那么这样迁移将会特别方便。

:::info 提一嘴，如果使用跨平台开发的，如使用前端技术栈去编写桌面端应用（electron），编写安卓，小程序（uniapp，taro）的话，**除了小程序外，其他都没有跨域限制的**（具体还要看相应跨平台技术的限制）。

:::

### 方案选择

最终选择那种开发方式还是取决对应的应用场景，没有绝对的方案，具体考虑哪种方案是需要考虑用户，代码安全，请求量，是否维护来考量了。

写到这，可能对大多数人而言还是不懂，也很正常，因为这些内容都不算属于传统开发的范畴，甚至可以说是做 <font color="gray">hui</font> 产的利器。

## 全栈框架

我非常希望使用到浏览器的跨平台性，即多端运行，用户的设备只需要有一个浏览器能打开网页就能体验到。（这其实也算是我为什么学 web 开发的初衷了）

但是在一开始所介绍的小区开门应用中，这样的开发体验其实并不友好。因为我既要编写前端应用还要编写后端服务，相当于两个项目。同时部署应用和传统部署没有特别大的区别，都需要一台服务器，很多时候都是浪费在部署上。

而全栈框架可以算是后端应用开发和前端应用开发结合。能很好的解决上述存在的问题，并且也易于部署，下面我会细细道来。

这里我选用的 [Nuxt](https://nuxt.com) 框架，这是一个基于 Vue 前端框架实现的服务端渲染框架，羊了个羊刷次数网页版就是基于 Nuxt3 框架来开发的，并且使用 vercel 来进行部署。我手头还写过一个项目 [api-service](https://github.com/kuizuo/api-service)。

首先在全栈框架，是有对应的后端服务引擎。像 Nuxt 使用的是 [Nitro](https://nitro.unjs.io/)，而 Next.js 使用的是 koa。都提供了后端服务 API 的解决方案，同时这些都是服务都算是 `serverless function`（无服务函数），所以在编写与调用非常方便。

此外基于 [Netlify](https://www.netlify.com/) 和 [Vercel](https://vercel.com) 这些 `serverless development` 平台，可以非常方便的部署全栈框架。同时内置 CI/CD，只需要提交 git commit 就能实现自动构建自动部署。

最主要是的我恰好使用 Node.js 来做爬虫与 api 接口，因此后端复现接口也使用 js 来实现。

为此我特意编写了一个 [Protocol 协议复现模板](/blog/protocol-template) ，这里我就不在过多介绍该模板。

## 总结

协议复现能写非常多的程序，因为协议复现的大多数案例都是基于已有的应用服务上去实现的，而很多人的日常生活都使用这些已有的服务上。有些已有的服务可能对于一些人而言，体验不好，或者是有其他限制。因此就有人对这些已有的服务来进行“扩展”，来实现自己所定制化的需求。

模拟请求|协议复现方案

我个人是非常讨厌这些认证提交手续的，例如疫情健康报告，请假申请表等等，当然也包括这次 Github 学生认证。

这也就是我为什么迟迟不认证 Github 学生的原因，其实说白了就是没必要。但就在前段时间 [github copilot](https://github.com/features/copilot/ 'github copilot') 不是内测结束了，然后要开始收费了，收费标准 一个月 $10 / 一年 $100。这费用对于我本不富裕的生活雪上加霜。而 coplot 对教育认证有免费资格使用，于是乎就有了此次较为艰辛的 github 学生认证。



## 开始认证

介绍完故事背景后，就要开始认证了。

能看到这篇的估计也是想要学生认证的，这里就将我的认证过程总结出来。

### 1、不要科学上网

如果开启科学上网的话，提交时 github 会根据 ip 来判断所提交的学校位置和 ip 地址是否相近，如果差的很远的话是直接认证失败，并提示

> You appear not to be near any campus location for the school you have selected. If you are a distance learner then your school-provided academic affiliation documentation must state so.

大致意思：您没有出现在您所选择的学校的任何校园附近。如果你是远程学习者，那么你的学校提供的学术联系文件必须说明这一点。

也就是这一点，让我放弃我在老家认证学生认证的想法，而到开学才重新认证

但如果不开启科学上网就有可能获取不了 Google 地图与最终提交，我的做法是修改 host，然后需要 Google 地图的时候开启科学上网，然后获取定位信息后再关闭，最后提交的时候没开启科学上网。

### 2、学生认证资料

#### 教育邮箱

有的大学是没有教育邮箱的，就比如我的大学。但不用教育邮箱也是能认证成功的。（当然有的话反而更好通过）

#### 学生证

学生证学生卡这些都可以作为学生 ID 来认证的，不过在拍学生证之前一定要保证照片清晰，看情况决定时间水印，因为有可能会提示如下信息

> Your document does not appear to include a date demonstrating current academic affiliation. For countries utilizing non-standard calendars, you may need to capture the original document beside one with a converted date. You may include multiple documents in your image, so long as they are legible.

大致意思就是提交的资料没有当前时间认证，所以加个时间水印主要是为了这个。

但不过我有个同学是新号，5 月 github 注册的时候提示要他学生认证，然后他就随手拍了一下学生证的照片提交上去就认证通过了。据他回忆当时认证的信息填的很随意，然后第一次就通过了。而反倒是我提交了好多次学生证都失败了，怎么说呢，可能看账号吧。

#### 学信网在线验证报告

假设你拍照提交学生证一直失败（我就是这样），那么还可以通过 [学信网](https://account.chsi.com.cn/passport/login '学信网') 的学信档案 [申请教育部学籍在线验证报告](https://my.chsi.com.cn/archive/bab/xj/show.action '申请教育部学籍在线验证报告')

这个报告默认是中文的，但是 github 不一定认中文的，所以会拒绝。这时候就需要翻译成英文，但是在学信网申请英文在线报告需要额外 30 元，有效期 1 年。当然如果不想花这些钱，就想着是学生认证白嫖的话，也可以使用网页在线翻译，将内容翻译成英文，就得到了一份英文版的在线验证报告。而这个份报告是能通过的，我就是这样操作的。

每次提交的文件都要求不同，因为 github 后台会对文件做认证，所以就需要多拍照，多截图，做到图片相似，但不相同。

### 3、修改 github 个人信息

如果你按照上面的操作提交了，但还是不通过，并且只有下面一条提示信息的话

> You are significantly more likely to be verified if you have completed your [GitHub user profile](https://docs.github.com/en/account-and-profile/setting-up-and-managing-your-github-profile/customizing-your-profile/personalizing-your-profile 'GitHub user profile') with your full name and a short bio.

大致意思是，完善你的 github 个人账号信息（头像，昵称，简介），像我做的就是把昵称改成了我的真实姓名，简介就写我来自什么学校，热爱开源。就差最后大招把头像改成我的自拍照，背景是学校门口。当然 github 还算仁慈，最终还是没让我放出“大招”。

然后我修改了个人信息，并又提交了几次后，就终于成功了！

所以只出现了上面的一条提示，那么说明已经快要成功了，只不过 github 还要考核你的坚持程度，看你会不会放弃（我猜的）

## 我的认证过程

按照以上的步骤，我将演示一遍我的认证过程。

1、登录 [github education](https://education.github.com/benefits) ，选择学生那个按钮。

![image-20221010134753749](https://img.kuizuo.cn/image-20221010134753749.png)

2、首次表单填写邮箱，学校，以及使用 Github 的目的。**表单所提交内容全都要使用英文**

![image-20221010134942952](https://img.kuizuo.cn/image-20221010134942952.png)

3、再次填写一个表单，首先是照片证明，也就是学生认证资料。这里是使用的是**学信网的在线证明英文翻译**，Proof Type 选择 Other (Example: Screenshot of school portal)，备注内容填写证明来源，例如：**这份证明来自中国高等教育学生信息网（学信网），以下是在线证明地址。。。**

![image-20221010135500357](https://img.kuizuo.cn/image-20221010135500357.png)

其次第二个表单，根据你的学校信息填写即可。**切记到这一步的时候请不要使用科学上课，最好使用学校的网络来提交。**

![image-20221010135949606](https://img.kuizuo.cn/image-20221010135949606.png)

4、点击 Process my application 提交，等待结果即可。

最终 Github 在今早发送邮箱告知我认证成功了！

![](https://img.kuizuo.cn/github_eduction_success.jpg)

只要你提供的学生信息真实有效，不断提交最终肯定是会成功的。在这认证期间我一共提交了 11 次请求。

![](https://img.kuizuo.cn/image_n3x8Cm8kMv.png)

期间收到的 Gtihub Education 邮箱信息如下：

![](https://img.kuizuo.cn/github_eduction_eamil.jpg)

最终也不负众望，在收到 github 通知的时候的，我就立马编写了这篇文章，记录了自己 github 学生认证的过程。

如果你有幸看到这篇文章，并想要认证 github 学生资格，希望这篇文章有帮到你。

## 认证到期

![](https://img.kuizuo.cn/202307210745506.png)

时隔一年，我的 github 学生认证到期了，然而就当我准备按照上述方式续期的时候。发现我的学校认证方式变得严格了起来，

![](https://img.kuizuo.cn/202307210748905.png)

由于我之前的信息(学信网在线认证)已经使用过了，告知我换个文件，我猜测是因为 审核流程 检测到页面相似度过高，就 Reject 了。还有一点在这次提交的时候，明确告诉需要我校的教育邮箱来进行认证，然而我并未申请，并且申请也不是那么容易，所以便暂时放弃。

不过目前来看，我使用最多的还是 github copilot，但学生认证过期后并不影响使用，所以我就不急着续期了。但 Jetbrains 的产品估计是跑不了的。

## 感谢

最终也是要感谢 Github 为广大开发者提供平台，让一群志同道合的人在上面分享并创造想法，同时也感谢这些默默为开源做出贡献的前人，不断为这个世界增添一丝色彩。