callable = () -> {
+ log.info("controller-callable#async task started. Thread: " + Thread.currentThread().getName());
+ Thread.sleep(300);
+ log.info("controller-callable#async task finished");
+ return "async result";
+ };
+
+ log.info("controller#handler finished");
+ return callable;
+ }
+}
+```
## 4 流程
### 4.1 流程图
-
-
执行效果：
diff --git "a/docs/md/spring/03-SpringMVC\346\213\246\346\210\252\345\244\204\347\220\206\345\231\250.md" "b/docs/md/spring/03-SpringMVC\346\213\246\346\210\252\345\244\204\347\220\206\345\231\250.md"
deleted file mode 100644
index 5c75f2da8f..0000000000
--- "a/docs/md/spring/03-SpringMVC\346\213\246\346\210\252\345\244\204\347\220\206\345\231\250.md"
+++ /dev/null
@@ -1,133 +0,0 @@
-# 03-SpringMVC拦截处理器
-
-## 1 工作原理流程图
-
-
-
-
-
-## 2 Spring Web MVC 的处理器拦截器
-
-
-
-
-
-类似Servlet的过滤器Filter，用于对处理器进行预处理和后处理。HandlerInterceptor接口定义如下方法：
-
-### 2.1 preHandle
-
-
-
-
-
-最终会调用HandlerInterceptor的
-
-## 1 preHandle
-
-
-
-
-
-调用所有的HandlerInterceptor拦截器并调用其preHandle方法。
-
-执行controller处理逻辑前执行，返回值为boolean，返回值为true时接着执行postHandle和afterCompletion，若返回false则中断执行。
-
-
-
-拦截处理程序的执行。 HandlerMapping确定的适当处理器对象后调用，但在HandlerAdapter调用处理器之前。
-
-DispatcherServlet是在执行链中处理的handler，其中包括了任意数量的拦截器，处理器本身在链的末尾，即最后才处理 handler。 利用该方法，每个拦截器可以决定中止执行链，特别发送一个HTTP错误或写入客户端响应。
-
-
-
-异步请求处理参见AsyncHandlerInterceptor 。
-true如果执行链应与下一个拦截器或处理程序本身进行。 否则，DispatcherServlet认为，这种拦截器已经处理了响应本身。
-
-在**请求处理之前进行调用**，只有当该方法返回true，才会继续调用下个`Interceptor`的`preHandle()`，若已是最后一个`Interceptor`，就调用当前请求的`Controller`
-
-### 2.2 postHandle
-
-applyPostHandle，获取所有的拦截器并调用其postHandle方法：
-
-
-在执行controller的处理后，在ModelAndView处理前执行。
-
-拦截处理程序的执行。 调用后的HandlerAdapter实际上调用的处理，但DispatcherServlet的呈现视图之前。 可以公开额外的模型对象通过给定的ModelAndView中的视图。
-DispatcherServlet的在执行链流程处理程序，其中包括任何数量的拦截器的，与所述处理程序本身在末端。 利用这种方法，每个拦截器可以后处理的执行，在执行链的相反的顺序得到应用。
-注：特殊注意事项适用于异步请求处理。 欲了解更多详情，请参见AsyncHandlerInterceptor 。
-
-在请求处理后，`DispatcherServlet`进行视图返回**渲染之前进行调用**，可在这个方法中对`Controller`处理之后的`ModelAndView`对象进行操作(比如这里加入公用信息，以便页面显示)
-
-### 2.3 afterCompletion
-
-在DispatchServlet执行完ModelAndView之后执行。
-
-
-
-请求处理，即完成之后回调，呈现视图后。 将在处理程序执行的任何结果调用，从而允许适当的资源清理。
-注意：如果此拦截器的才会被调用preHandle方法已成功完成，返回true ！
-如同postHandle方法，该方法将在以相反的顺序链中的每个拦截器被调用，所以第一个拦截器将是最后被调用。
-注：特殊注意事项适用于异步请求处理。 欲了解更多详情，请参见AsyncHandlerInterceptor 。
-
-需当前对应的`Interceptor`的`preHandle`方法的返回值为`true`时才会执行。该方法将在整个请求结束之后，即DispatcherServlet` 渲染了对应的视图之后执行，**用于资源清理**
-
-## 3 拦截器配置
-
-### 3.1 针对某种mapping拦截器配置
-
-```xml
-
-
-
-
-
-
-
-
-```
-
-### 3.2 针对所有mapping配置全局拦截器
-
-```xml
-
-
-
-
-
-
-
-
-
-
-
-
-```
-
-## 4 实践
-
- 用户访问其他页面时,从Seesion中获取到用户，未登录则重定向到登录页面。
-
-```java
-Public class LoginInterceptor implements HandlerInterceptor{
- @Override
- Public boolean preHandle(HttpServletRequest request,
- HttpServletResponse response, Object handler) throws Exception {
-
- //如果是登录页面则放行
- if(request.getRequestURI().indexOf("login.action")>=0){
- return true;
- }
- HttpSession session = request.getSession();
- //如果用户已登录也放行
- if(session.getAttribute("user")!=null){
- return true;
- }
- //用户没有登录挑战到登录页面
- request.getRequestDispatcher("/WEB-INF/jsp/login.jsp").forward(request, response);
-
- return false;
- }
-```
\ No newline at end of file
diff --git "a/docs/md/spring/01-SpringMVC\347\232\204AsyncHandlerInterceptor\345\274\202\346\255\245\347\232\204\345\244\204\347\220\206\345\231\250\346\213\246\346\210\252\345\231\250.md" b/docs/md/spring/SpringMVC-AsyncHandlerInterceptor.md
similarity index 100%
rename from "docs/md/spring/01-SpringMVC\347\232\204AsyncHandlerInterceptor\345\274\202\346\255\245\347\232\204\345\244\204\347\220\206\345\231\250\346\213\246\346\210\252\345\231\250.md"
rename to docs/md/spring/SpringMVC-AsyncHandlerInterceptor.md
diff --git a/docs/md/spring/SpringMVC-HandlerInterceptor.md b/docs/md/spring/SpringMVC-HandlerInterceptor.md
new file mode 100644
index 0000000000..e68684698b
--- /dev/null
+++ b/docs/md/spring/SpringMVC-HandlerInterceptor.md
@@ -0,0 +1,167 @@
+# SpringMVC拦截处理器
+
+## 1 工作原理流程图
+
+
+
+## 2 Spring Web MVC 的处理器拦截器
+
+```java
+public interface HandlerInterceptor {
+
+ default boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler)
+ throws Exception {
+
+ return true;
+ }
+
+ default void postHandle(HttpServletRequest request, HttpServletResponse response, Object handler,
+ @Nullable ModelAndView modelAndView) throws Exception {
+ }
+
+ default void afterCompletion(HttpServletRequest request, HttpServletResponse response, Object handler,
+ @Nullable Exception ex) throws Exception {
+ }
+
+}
+```
+
+类似Servlet的过滤器Filter，对处理器进行预处理、后处理。HandlerInterceptor接口方法：
+
+### 2.1 preHandle
+
+```java
+@SuppressWarnings("serial")
+public class DispatcherServlet extends FrameworkServlet {
+
+ protected void doDispatch() {
+ ...
+ if (!mappedHandler.applyPreHandle(processedRequest, response)) {
+ return;
+ }
+ }
+}
+```
+
+最终会调用HandlerInterceptor#preHandle：
+
+```java
+public class HandlerExecutionChain {
+
+ boolean applyPreHandle(HttpServletRequest request, HttpServletResponse response) throws Exception {
+ HandlerInterceptor[] interceptors = getInterceptors();
+ if (!ObjectUtils.isEmpty(interceptors)) {
+ for (int i = 0; i < interceptors.length; i++) {
+ HandlerInterceptor interceptor = interceptors[i];
+ if (!interceptor.preHandle(request, response, this.handler)) {
+ ...
+}
+```
+
+调用所有的HandlerInterceptor拦截器并调用其preHandle方法。
+
+执行controller处理逻辑前执行，返回值为boolean，返回值为true时接着执行postHandle和afterCompletion，若返回false则中断执行。
+
+
+
+拦截处理程序的执行。 HandlerMapping确定的适当处理器对象后调用，但在HandlerAdapter调用处理器之前。
+
+DispatcherServlet是在执行链中处理的handler，其中包括了任意数量的拦截器，处理器本身在链的末尾，即最后才处理 handler。 利用该方法，每个拦截器可以决定中止执行链，特别发送一个HTTP错误或写入客户端响应。
+
+
+
+异步请求处理参见AsyncHandlerInterceptor 。
+true如果执行链应与下一个拦截器或处理程序本身进行。 否则，DispatcherServlet认为，这种拦截器已经处理了响应本身。
+
+在业务处理器处理请求前被调用，只有当该方法返回true，才会继续调用下个`Interceptor`的`preHandle()`，若已是最后一个`Interceptor`，就调用当前请求的`Controller`
+
+### 2.2 postHandle
+
+applyPostHandle，获取所有的拦截器并调用其postHandle方法：
+
+```java
+/**
+ * Apply postHandle methods of registered interceptors.
+ */
+void applyPostHandle(HttpServletRequest request, HttpServletResponse response, @Nullable ModelAndView mv)
+ throws Exception {
+
+ HandlerInterceptor[] interceptors = getInterceptors();
+ if (!ObjectUtils.isEmpty(interceptors)) {
+ for (int i = interceptors.length - 1; i >= 0; i--) {
+ HandlerInterceptor interceptor = interceptors[i];
+ interceptor.postHandle(request, response, this.handler, mv);
+ }
+ }
+}
+```
+
+执行controller的处理后，即业务处理器处理请求执行完成后，并在ModelAndView处理生成视图之前执行。
+
+请求处理后，`DispatcherServlet`进行视图返回**渲染之前进行调用**，可在该方法中对`Controller`处理之后的`ModelAndView`对象进行操作（如加入公用信息，以便页面显示）。
+
+### 2.3 afterCompletion
+
+DispatchServlet执行完ModelAndView后执行，即完成之后回调，呈现视图后。 将在处理程序执行的任何结果调用，从而允许适当的资源清理。
+
+需当前对应的`Interceptor`的`preHandle`方法的返回值为`true`时才会执行。该方法将在整个请求结束之后，即DispatcherServlet渲染了对应的视图之后执行，**用于资源清理**。
+
+## 3 拦截器配置
+
+### 3.1 针对某种mapping拦截器配置
+
+```xml
+
+
+
+
+
+
+
+
+```
+
+### 3.2 针对所有mapping配置全局拦截器
+
+```xml
+
+
+
+
+
+
+
+
+
+
+
+
+```
+
+## 4 实践
+
+ 用户访问其他页面时,从Seesion中获取到用户，未登录则重定向到登录页面。
+
+```java
+Public class LoginInterceptor implements HandlerInterceptor {
+ @Override
+ Public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception {
+
+ // 若是登录页面则放行
+ if(request.getRequestURI().indexOf("login.action")>=0){
+ return true;
+ }
+ HttpSession session = request.getSession();
+ //如果用户已登录也放行
+ if(session.getAttribute("user")!=null){
+ return true;
+ }
+ //用户没有登录挑战到登录页面
+ request.getRequestDispatcher("/WEB-INF/jsp/login.jsp").forward(request, response);
+
+ return false;
+ }
+```
\ No newline at end of file
diff --git a/docs/md/spring/farewell-bean-not-found-easily-solve-spring-boot-package-scanning-issues.md b/docs/md/spring/farewell-bean-not-found-easily-solve-spring-boot-package-scanning-issues.md
new file mode 100644
index 0000000000..fad5658992
--- /dev/null
+++ b/docs/md/spring/farewell-bean-not-found-easily-solve-spring-boot-package-scanning-issues.md
@@ -0,0 +1,146 @@
+# 01-告别 "Bean Not Found"！轻松搞定 Spring Boot 包扫描难题 ✅
+
+## 0 前言
+
+SpringBoot约定大于配置，但不熟悉所有约定，所以经常写bug！
+
+## 1 案例：扫描不到Bean定义
+
+Spring Boot服务包结构：
+
+
+
+BestPractiseApplication：
+
+```java
+package com.javaedge.spring.aop;
+
+/**
+ * @author JavaEdge
+ */
+@SpringBootApplication
+public class BestPractiseApplication {
+
+ public static void main(String[] args) {
+ SpringApplication.run(BestPractiseApplication.class, args);
+ }
+}
+```
+
+MyController：
+
+```java
+package com.javaedge.spring.app;
+
+/**
+ * @author JavaEdge
+ */
+@RestController
+public class MyController {
+
+ @GetMapping("hello")
+ public String hello() {
+ return "hello Java";
+ }
+}
+```
+
+访问`http://localhost:12345/hello`：
+
+
+
+紧急需求，需添加多个Controller，常规操作调整包结构：
+
+
+
+发现应用不识别MyController，找不到 MyController 这 Bean，why？
+
+
+
+## 2 解惑
+
+### 2.1 之前为啥生效？
+
+@SpringBootApplication继承了其它注解：
+
+```java
+@Target(ElementType.TYPE)
+@Retention(RetentionPolicy.RUNTIME)
+@Documented
+@Inherited
+@SpringBootConfiguration
+@EnableAutoConfiguration
+@ComponentScan(excludeFilters = { @Filter(type = FilterType.CUSTOM, classes = TypeExcludeFilter.class),
+ @Filter(type = FilterType.CUSTOM, classes = AutoConfigurationExcludeFilter.class) })
+public @interface SpringBootApplication {
+```
+
+SpringBootApplication默认开启ComponentScan。SpringBoot应用启动时，ComponentScan扫描所有定义的 Bean，扫描位置由 ComponentScan 的 basePackages 属性指定：
+
+```java
+package org.springframework.context.annotation;
+
+@Retention(RetentionPolicy.RUNTIME)
+@Target(ElementType.TYPE)
+@Documented
+@Repeatable(ComponentScans.class)
+public @interface ComponentScan {
+
+ @AliasFor("basePackages")
+ String[] value() default {};
+
+ @AliasFor("value")
+ String[] basePackages() default {};
+```
+
+但basePackages默认空，那它扫描的啥包？debug 到 ComponentScanAnnotationParser#parse：
+
+
+
+即declaringClass所在包，即`com.javaedge.app`。
+
+## 3 修正
+
+如下两种方案：
+
+### 3.1 放好位置
+
+
+
+
+
+### 3.2 显式配置
+
+#### @ComponentScan
+
+```java
+package com.javaedge.spring.app;
+
+@SpringBootApplication()
+@ComponentScan("com.javaedge.spring.controller")
+public class BestPractiseApplication {
+
+ public static void main(String[] args) {
+ SpringApplication.run(BestPractiseApplication.class, args);
+ }
+}
+```
+
+
+
+#### @ComponentScans
+
+```java
+package com.javaedge.spring.app;
+
+@SpringBootApplication()
+@ComponentScans(value = {@ComponentScan(value = "com.javaedge.spring.controller")})
+public class BestPractiseApplication {
+
+ public static void main(String[] args) {
+ SpringApplication.run(BestPractiseApplication.class, args);
+ }
+}
+```
+
+ComponentScans 相比 ComponentScan，可指定扫描多个包范围。
\ No newline at end of file
diff --git a/docs/md/spring/why-spring-bean-difficult-birth-overcome-constructor-injection-dependencies-and-ambiguity.md b/docs/md/spring/why-spring-bean-difficult-birth-overcome-constructor-injection-dependencies-and-ambiguity.md
new file mode 100644
index 0000000000..08581f79ab
--- /dev/null
+++ b/docs/md/spring/why-spring-bean-difficult-birth-overcome-constructor-injection-dependencies-and-ambiguity.md
@@ -0,0 +1,189 @@
+# Spring 原型 Bean 的“单例劫”：@Lookup 如何破局，确保每次获取新实例？
+
+## 1 案例：原型 Bean 被固定
+
+使用原型 Bean：
+
+```java
+package com.javaedge.spring.service;
+
+/**
+ * @author JavaEdge
+ */
+@Service
+@Scope(ConfigurableBeanFactory.SCOPE_PROTOTYPE)
+public class JavaService {
+}
+```
+
+这么用：
+
+```java
+package com.javaedge.spring.controller;
+
+@RestController
+public class MyController {
+
+ @Autowired
+ private JavaService javaService;
+
+ @GetMapping("hello")
+ public String hello() {
+ return "hello: " + javaService;
+ }
+```
+
+不管访问多少次[http://localhost:12345/hello](http://localhost:12345/hello)，返回值不变：
+
+
+
+不是定义成原型 Bean了，没生效？
+
+## 2 答疑
+
+当一个属性成员 javaService 声明为@Autowired，创建 MyController Bean 时，会先用构造器反射出实例，然后装配各标记@Autowired的属性成员。
+
+装配方法AbstractAutowireCapableBeanFactory#populateBean，会用很多BeanPostProcessor，其中AutowiredAnnotationBeanPostProcessor通过 DefaultListableBeanFactory#findAutowireCandidates 寻找到 JavaService 类型 Bean，再设置给对应属性（即 javaService成员）。
+
+### inject
+
+AutowiredAnnotationBeanPostProcessor.AutowiredFieldElement：
+
+```java
+protected void inject(Object bean, @Nullable String beanName, PropertyValues pvs) {
+ Field field = (Field) this.member;
+ Object value;
+ // 寻找bean
+ if (this.cached) {
+ value = resolvedCachedArgument(beanName, this.cachedFieldValue);
+ }
+ else {
+ // ...
+ value = beanFactory.resolveDependency(desc, beanName, autowiredBeanNames, typeConverter);
+ }
+ if (value != null) {
+ // 将bean设置给成员字段
+ ReflectionUtils.makeAccessible(field);
+ field.set(bean, value);
+ }
+}
+```
+
+找到要自动注入的 Bean 后，即反射设置给对应field。这个field的执行只发生一次，所以后续就固定，不会因ServiceImpl标记了 **SCOPE_PROTOTYPE** 而改变。
+
+所以，当一个单例Bean用@Autowired标记其属性时，该属性值会被固定！
+
+## 3 修正
+
+不能将 JavaService 的 Bean 固定到属性，而应每次用时都重新获取一次。修正方案：
+
+### 3.1 自动注入 Context
+
+即自动注入ApplicationContext，再定义 getJavaService 方法以获取一个新 JavaService 实例：
+
+```java
+@RestController
+public class MyController {
+
+ @Autowired
+ private ApplicationContext applicationContext;
+
+ @Autowired
+ private JavaService javaService;
+
+ @GetMapping("hello")
+ public String hello() {
+ return "hello: " + getJavaService();
+ }
+
+ public JavaService getJavaService() {
+ return applicationContext.getBean(JavaService.class);
+ }
+}
+```
+
+### 使用 Lookup 注解
+
+还是要添加一个 getServiceImpl 方法，不过这个方法是被 Lookup 标记的：
+
+```java
+@RestController
+public class MyController {
+
+ @Autowired
+ private JavaService javaService;
+
+ @GetMapping("hello")
+ public String hello() {
+ return "hello: " + getJavaService();
+ }
+
+ @Lookup
+ public JavaService getJavaService() {
+ return null;
+ }
+}
+```
+
+这样每次访问该接口，都会创建新的Bean。
+
+## 4 Lookup原理
+
+最终执行因@Lookup而走入CglibSubclassingInstantiationStrategy.LookupOverrideMethodInterceptor，其关键实现参考 LookupOverrideMethodInterceptor的
+
+### intercept
+
+```java
+private final BeanFactory owner;
+
+public Object intercept(Object obj, Method method, Object[] args, MethodProxy mp) throws Throwable {
+ LookupOverride lo = (LookupOverride) getBeanDefinition().getMethodOverrides().getOverride(method);
+ Assert.state(lo != null, "LookupOverride not found");
+ Object[] argsToUse = (args.length > 0 ? args : null); // if no-arg, don't insist on args at all
+ if (StringUtils.hasText(lo.getBeanName())) {
+ return (argsToUse != null ? this.owner.getBean(lo.getBeanName(), argsToUse) :
+ this.owner.getBean(lo.getBeanName()));
+ }
+ else {
+ return (argsToUse != null ? this.owner.getBean(method.getReturnType(), argsToUse) :
+ this.owner.getBean(method.getReturnType()));
+ }
+}
+```
+
+方法调用最终没有走入案例代码实现的return null语句，而是通过 BeanFactory 获取 Bean。从这点看出，在getServiceImpl方法实现中，随便咋写都行，不重要。
+
+如用下面实现来测试这结论：
+
+```java
+@Lookup
+public ServiceImpl getServiceImpl() {
+ // 日志会输出么？
+ log.info("executing this method");
+ return null;
+}
+```
+
+以上代码，添加了一行代码输出日志。测试后，发现没有日志输出。这也验证了，用@Lookup注解一个方法时，方法具体实现已不重要。
+
+Q：再回溯分析，为啥走入CGLIB搞出的类？
+
+A：因为我们有方法标记Lookup。可从下面这段验证，参考 SimpleInstantiationStrategy#instantiate：
+
+```java
+@Override
+public Object instantiate(RootBeanDefinition bd, String beanName, BeanFactory owner) {
+ // Don't override the class with CGLIB if no overrides.
+ if (!bd.hasMethodOverrides()) {
+ return BeanUtils.instantiateClass(constructorToUse);
+ }
+ else {
+ // Must generate CGLIB subclass.
+ return instantiateWithMethodInjection(bd, beanName, owner);
+ }
+}
+```
+
+当 hasMethodOverrides 为 true，则用 CGLIB。而本案例该条件成立在于解析HelloWorldController这Bean时，发现有方法被@Lookup，此时就会添加相应方法到属性methodOverrides 里面去（此过程由 AutowiredAnnotationBeanPostProcessor#determineCandidateConstructors 完成）。
+
+添加后效果图如下：
\ No newline at end of file
diff --git "a/docs/md/tomcat/Tomcat\350\277\233\347\250\213\345\215\240\347\224\250CPU\350\277\207\351\253\230\346\200\216\344\271\210\345\212\236\357\274\237.md" b/docs/md/tomcat/how-to-solve-high-cpu-usage-in-tomcat-process.md
similarity index 86%
rename from "docs/md/tomcat/Tomcat\350\277\233\347\250\213\345\215\240\347\224\250CPU\350\277\207\351\253\230\346\200\216\344\271\210\345\212\236\357\274\237.md"
rename to docs/md/tomcat/how-to-solve-high-cpu-usage-in-tomcat-process.md
index ab04d4d1ae..d4c6de7538 100644
--- "a/docs/md/tomcat/Tomcat\350\277\233\347\250\213\345\215\240\347\224\250CPU\350\277\207\351\253\230\346\200\216\344\271\210\345\212\236\357\274\237.md"
+++ b/docs/md/tomcat/how-to-solve-high-cpu-usage-in-tomcat-process.md
@@ -28,11 +28,15 @@ java -Xss256k -jar demo-0.0.1-SNAPSHOT.jar
线程栈大小指定256KB。对于测试程序，os默认值8192KB过大，因为需要创建4096个线程。
-top看到Java进程CPU使用率达961.6%，注意进程ID 55790：
+#### top
+
+见Java进程CPU使用率爆表：
-精细化top查看这Java进程中各线程使用CPU情况：
+#### top细查
+
+这进程的各线程使用CPU情况：
```java
$ top -H -p 55790
@@ -40,13 +44,17 @@ $ top -H -p 55790
-有个“scheduling-1”线程占用较多CPU。下一步就找出这个线程在做啥。jstack生成线程快照。jstack输出较大，一般将其写入文件：
+“scheduling-1”线程占较多CPU。找这线程在做啥。
+
+#### jstack生成线程快照
+
+jstack输出较大，一般将其写入文件：
```java
jstack 55790 > 55790.log
```
-打开55790.log，定位到第4步中找到的名为 **scheduling-1** 的线程，其线程栈：
+打开log并定位到第4步中找到的名为 **scheduling-1** 的线程，其线程栈：
@@ -89,5 +97,6 @@ grep -o 'pool-2-thread' 55790.log | wc -l
## 总结
-遇到CPU过高，首先定位哪个进程导致，之后可通过top -H -p pid命令定位到具体的线程。
-其次还要通jstack查看线程的状态，看看线程的个数或者线程的状态，如果线程数过多，可以怀疑是线程上下文切换的开销，我们可以通过vmstat和pidstat这两个工具进行确认。
\ No newline at end of file
+CPU过高，先定位啥进程导致，之后top -H -p pid定位具体线程。
+
+还要jstack查看线程状态，看线程个数或线程状态，若线程数过多，可怀疑是线程上下文切换开销，可通过vmstat和pidstat确认。
\ No newline at end of file
diff --git a/docs/md/vue/frontend-ci-cd-automation-deploy-and-instant-rollback-solution.md b/docs/md/vue/frontend-ci-cd-automation-deploy-and-instant-rollback-solution.md
new file mode 100644
index 0000000000..28277a4abc
--- /dev/null
+++ b/docs/md/vue/frontend-ci-cd-automation-deploy-and-instant-rollback-solution.md
@@ -0,0 +1,134 @@
+# 上线卡半夜、出 bug 只能硬扛？前端自动化部署 + 秒级回滚方案来了
+
+## 0 前言
+
+项目上线前最后一步，把开发好的代码部署到线上。
+
+“npm run build不就行”。这只是在本地把代码打包，想在线上也可访问这些代码，还需部署。所以在下面，如今的前端代码部署时的难点在哪呢？
+
+## 1 部署难点
+
+### jQuery时代之前
+
+前端项目中所有内容都是一些简单的静态资源。网站还没部署的概念，网站上线前，直接把开发完的项目打包发给运维，再由运维把代码直接上传到服务器的网站根目录下解压缩，完成项目部署。
+
+### jQuery时代
+
+项目的入口页面被后端管理，模板部署到后端，CSS、js和图片等静态资源依然是打包到后端之后，再解压处理。但现在，对前端的性能和稳定性的要求也越来越高，jQuery时代那种简单部署模式不足以应对性能优化、持续部署。
+
+### 当下主要面临的代码部署难点
+
+- 咋高效地利用项目中的文件缓存
+- 咋能让整个项目的上线部署过程自动化，尽可能避免人力的介入，提高上线稳定性
+- 项目上线之后，如果发现有重大Bug，要考虑咋尽快回滚代码
+
+当我们面对这些代码部署上的难点，特别是在团队协作的项目中遇到时，我们就可以考虑对项目进行自动化部署了，这样代码部署的速度和稳定性会给项目研发效率带来很好的提升。
+
+## 2 上线前的自动化部署
+
+如下是大部分团队部署项目时的逻辑：
+
+```mermaid
+flowchart LR
+ A[开发代码] -->|打包压缩| B[打包代码]
+ B -->|上传| C[服务器]
+
+ style A fill:#90EE90
+ style B fill:#90EE90
+ style C fill:#87CEEB
+
+```
+
+完成打包压缩，即开发完项目后，代码推送到GitHub，就算完成任务。但打包代码后，把代码上传服务器也是这步，对于前端开发者，很少能接触，但却很重要。
+
+咋把打包好的代码上传服务器，需好的解决方案。
+
+- 先需一台独立机器进行打包和构建，该机器需独立于所有开发环境，为保证打包环境稳定
+- 部署任务启动的时候，需拉取远程代码，并切换到需部署的分支，然后锁定Node版本进行依赖安装、单元测试、ESLint等代码检查工作
+- 最后，在这台机器，执行经过编译产出的打包后的代码，并打包上传代码到CDN和静态服务器
+- 完成这些操作后，还要能通过脚本自动通过内部沟通软件通知团队项目构建的结果
+
+项目部署过程可能遇到如下
+
+### 问题
+
+- 在什么os环境中执行项目的构建？
+- 由谁触发构建？
+- 咋管理前面所述的把代码上传CDN时，CDN账户的权限？
+- 咋自动化执行部署的全过程，若每次都由人工执行，就得消耗一个人力守着编译打包，且易引发问题，如测试的步骤遗漏或部署顺序出错。咋提升构建速率，是部署功能中需解决的重要问题。
+
+### 解决方案
+
+如采用能保证环境一致性的Docker；自动化构建触发可通过GitHub Actions；GitHub的actions功能相当于给我们提供了一个免费的服务器，可以很方便地监控代码的推送、安装依赖、代码编译自动上传到服务器。
+
+```mermaid
+flowchart LR
+ A[开发代码] -->|推送代码| B[Github]
+ B --> C[环境依赖 / 自动化测试 / 代码打包 / 通知]
+ C --> D[打包后代码]
+ D -->|html| E[服务器]
+ D -->|静态资源| F[CDN]
+
+ style A fill:#90EE90
+ style B fill:#90EE90
+ style C fill:#90EE90
+ style D fill:#90EE90
+ style E fill:#87CEEB
+ style F fill:#87CEEB
+```
+
+这是用GitHub Actions部署项目后的项目开发流程。现在静态资源管理已完成，也实现自动化部署。提交代码后，项目就可自动推送到服务器，网站第一次上线成功。
+
+## 3 上线后的自动化部署
+
+后续的持续上线咋办？直接发到生产环境，面临极大风险。但不直接发布到生产环境，我们就不能在本地和测试的前端环境去连接生产环境的数据库。
+
+需预发布的（Pre）环境，只能让测试和开发访问，除了访问地址的环节不同，其他所有环节都和生产环境一致，提供最真实的回归测试环境。
+
+又面临
+
+### 3.1 问题
+
+若确定下周一零点发布，就只能晚上12点准时守在电脑前等结果？若npm安装依赖失败或上线后发现重大Bug，就只能迎投诉？
+
+随node\_modules体积越来越大，构建时间越来越长。若每次构建都需30min甚至更长，即使Bug在项目刚上线时就发现，且秒级响应修复，但重新部署项目时，也要等服务器慢慢编译。时间就是金钱，若你在修复Bug和重新部署项目上耗时长，就导致项目故障时间过长。
+
+### 解决方案
+
+需一种机制，让我们发现问题后，尽快回滚版本，且在回滚过程，尽可能无需人力介入。所以，需静态资源的版本管理，即让每个历史版本的资源都保留，且有唯一版本号，如故障，能瞬间切换版本。这个过程由具体代码实现后，只需点击回滚的版本号，系统就自动恢复到上线前版本。
+
+该机制下，如业务流量特大，那直接全量上线的操作就会被禁止。为减少上线时，部署操作对用户的影响，需先选择一部分用户做灰度测试，即上线后的项目的访问权限，暂时只对这些用户开放。或做AB测试，如给北京的同学推送Vue课，给上海推荐React课等。我们要做的，是把不同版本代码分开打包，互不干涉。之后，再设计部署的机器和机房去适配不同用户。
+
+Gtihub中可用actions配置打包功能，下面的代码是actions的配置文件。Ubuntu作服务器的打包环境，拉取GitHub最新master代码，并把Node版本固定14.7.6，执行npm install后，再执行npm run build代码打包压缩。
+
+通过GitHub Actions自动化打包一份准备上线的代码：
+
+```yaml
+name: 打包应用的actions
+on:
+ push: # 监听代码时间
+ branches:
+ - master # master分支代码推送的时候激活当前action
+jobs:
+ build:
+ # runs-on 操作系统
+ runs-on: ubuntu-latest
+ steps:
+ - name: 迁出代码
+ uses: actions/checkout@master
+ # 安装Node
+ - name: 安装Node
+ uses: actions/setup-node@v1
+ with:
+ node-version: 14.7.6
+ # 安装依赖
+ - name: 安装依赖
+ run: npm install
+ # 打包
+ - name: 打包
+ run: npm run build
+```
+
+然后配置上线服务器和GitHub Actions服务器的信任关系，通过SSH密钥可实现免登录直接部署。直接把build后的代码打包压缩，通过SSH直接上传到服务器，并且要进行代码文件版本的管理，就完成代码部署。
+
+部署成功后的结果通知。钉钉、飞书都提供推送结果，可随时通过群机器人接口把消息推送到群内，把版本号、部署日期、发起人等信息推送到对应接口，就完成自动化部署。
\ No newline at end of file
diff --git a/docs/md/vue/goodbye-jquery-thinking-create-checklist-apps-with-vue-js-experience-the-charm-of-data-driven.md b/docs/md/vue/goodbye-jquery-thinking-create-checklist-apps-with-vue-js-experience-the-charm-of-data-driven.md
new file mode 100644
index 0000000000..dcd147a1dd
--- /dev/null
+++ b/docs/md/vue/goodbye-jquery-thinking-create-checklist-apps-with-vue-js-experience-the-charm-of-data-driven.md
@@ -0,0 +1,388 @@
+# 告别 jQuery 思维：用 Vue.js 轻松打造清单应用，体验数据驱动的魅力
+
+## 0 前言
+
+团队的项目是用Vue.js开发的，但并不熟悉Vue的具体技术细节，所以我决定带他先做一个清单应用，先在整体上熟悉这个框架。带你们做个清单应用，更多的是一种模拟的场景，并不需要对号入座到真实的工作场景下。
+
+## 1 任务分解
+
+有一个输入框，供我们输入数据；下方有一个列表，显示着所有我们要做的事情。
+
+在输入框输入内容后，敲下回车，下面就会新增一条数据。对于每个要做的事情，你还可以用复选框标记，标记后文字就会变灰，并带有一个删除的效果，表示这事已做完。
+
+
+
+清单应用麻雀虽小，五脏俱全。不管入门哪个框架，都可写一个清单体验。
+
+只有简单jQuery开发经验，先要思想转变。对比
+
+## 2 jQuery V.S Vue.js
+
+做一个输入框，里面输入的任何数据都会在页面上同步显示。
+
+### 2.1 jQuery开发思路
+
+1. 先找到输入框，给输入框绑定输入事件
+2. 输入的同时，我们获取输入的值
+3. 再找到对应的html标签，更新标签的内容
+
+代码：
+
+```html
+
+
+
+
+
+
+```
+
+jQuery开发逻辑就是先找到目标元素，再进行对应修改。
+
+而Vue.js不再思考页面的元素咋操作，而是思考数据咋变化。即只需操作数据，至于数据和页面的同步问题，Vue帮我们处理。Vue让前端能专注数据本身操作，而数据和页面的同步问题，由Vue负责。
+
+### 2.2 Vue开发思路
+
+我们需要一个数据，在输入框的代码和h2标签的代码内使用。只需操作数据，再交给Vue去管理数据和页面的同步。
+
+Vue下，想页面显示一个数据:
+
+- 先在代码的data里声明数据
+- 输入框代码里用v-model标记输入框和数据的同步
+- HTML模板里，两个花括号标记，来显示数据，如{{title}}∂
+
+#### 对应代码
+
+```vue
+
+
{{title}}
+
+
+
+
+
+```
+
+## 3 清单页面的渲染
+
+- 输入框输入数据
+- 输入框下方要有个列表，显示所有输入的值
+
+按Vue思考方式，需一个数组，再用v-for循环渲染。
+
+### 代码
+
+```vue
+
+
+
+
+```
+
+先放两个假数据，如在标签里直接写{{todos}}，就会看到显示的是数组，但不是想要的，我们需要显示一个列表。
+
+Vue中只要渲染列表，都用v-for：
+
+```xml
+{{todo}}
+```
+
+循环遍历todos这个数据， 每一条遍历的结果叫todo，再把这个数据渲染出来，页面就能显示一个列表：
+
+
+
+## 4 处理用户交互
+
+上步主要考虑：实现前端页面的一个输入框及能显示输入值的一个列表的功能。
+
+下一步，就是回车时，让列表新增一条。按Vue思维：
+
+- 监听用户的输入。在监听中，若判断到用户的输入是回车，就执行一个函数
+- 在执行的这个函数内部，把title追加到todos最后面位置，并清空title
+
+### 代码
+
+```vue
+
+
+
+
+```
+
+@标记用户的交互：
+
+- @click是点击
+- @keydown是键盘敲下
+
+监听回车键，那么我们就用@keydown.enter=“addTodo” 。
+
+监听到用户的输入后，对要执行的函数，新增一个methods配置。函数内部，this可直接读到data里数据，无需考虑咋找到标签。只需如下一行就能让列表自动新增一条， 这就是数据驱动页面。
+
+```js
+this.todos.push(this.title)
+```
+
+## 5 额外信息的显示
+
+实现标记清单中某项是否完成。
+
+目前代码设计，输入只能是字符串格式。而标记功能，却是把列表中的某项，用灰色的字体背景和中划线来标记，以此表示这一条内容是已完成内容。
+
+想实现，需改造数据结构，把内容的数据类型，从简单的字符串类型改为对象。
+
+### 代码
+
+```vue
+
+
+
+
+
+```
+
+### 改造思路
+
+对todos数组，除了title，还要加个done字段，标记列表中的某项内容是否完成，并且渲染时用todo.title。
+
+前面对列表中每项用无序列表示。但若想在列表中实现对某些选项的同时多选，得用复选框。对每条信息，都要加个复选框，所以用v-model绑定这done字段，实现数据里能记录用户操作的状态。
+
+还需根据done字段显示某行样式。Vue的冒号":" 开头的属性是用来传递数据，这里的写法就是根据todo.done决定是否有done这个class。最后，当加上".done"的样式后，左图就是效果，右图是涉及到".done"的相关代码：
+
+
+
+## 6 进一步优化
+
+还想增加两个功能：
+
+- 在前端页面显示的列表的最下面，显示一下列表项目中没完成的项目的比例
+- 新增一个清理的按钮，用来删掉已经标记为完成的列表中的一条或多条数据
+
+### 第一个功能的代码（模版里写js）
+
+```html
+
+ {{todos.filter(v=>!v.done).length}}
+ /
+ {{todos.length}}
+
+```
+
+这段代码增加到上步最后的完整代码中，运行代码，从下图所示的前端页面运行时状态中，可见其中显示的未完成比例的数据也没问题。
+
+
+
+代码看起来丑且性能差，且需要二次计算的数据。模板里写JS，看着代码也乱。Vue对此设计了
+
+### 计算属性
+
+用计算属性实现二次计算需求：
+
+```vue
+
+ {{active}} / {{all}}
+
+
+
+```
+
+新增属性computed，其配置active、all都是函数。俩函数返回的计算后的值，在模板里可直接当做数据来用，这样把js的计算逻辑依然放在js，避免臃肿模板。
+
+computed计算属性还内置缓存功能，如果依赖数据没变化，多次使用计算属性会直接返回缓存结果，相比直接写在模板，性能也提升。
+
+计算属性不仅可以用来返回数据，有些时候我们也需要修改计算属性，如新增一个全选的复选框：
+
+- 全选框在勾选与取消勾选两个状态之间的切换，会把所有清单内的数据都同步勾选
+- 清单内的项目如果全部选中或者取消，也会修改全选框的状态
+
+所以全选框这计算属性，就有了修改的需求。此时computed的配置就不能是函数，要变成一个对象，分别实现：
+
+- get函数，之前的返回值
+- set，修改计算属性要执行的函数
+
+### computed修改后的代码
+
+```vue
+
+ 全选
+ {{active}} / {{all}}
+
+
+
+```
+
+ 实现新增一个全选的复选框后的效果：
+
+
+
+## 7 条件渲染
+
+新增一个“清理”的按钮，点击之后把已完成的数据删除，功能需求很简单，但是有一个额外的要求，就是列表中没有标记为完成的某一项列表数据时，这个按钮是不显示的。
+
+这种在特定条件下才显示，或者隐藏的需求也很常见，我们称之为条件渲染。在Vue中，我们使用v-if 来实现条件渲染。
+
+### 代码
+
+```vue
+
+
+```
+
+active＜all时，显示清理按钮，即v-if后面值true时，显示清理按钮，false时不显示。
+
+@click的作用是绑定点击事件。
+
+还可用v-else配合v-if，当todos是空的时候，显示一条“暂无数据”的信息：
+
+```xml
+
+
+ 暂无数据
+
+
+```
+
+当我们实现了清理按钮的功能，并且也实现了列表为空时，能够显示“暂无数据”的信息后，我们看下清单应用的最终效果。
+
+ 
+
+## 8 总结
+
+先扭转之前jQuery开发思路，弄明白jQuery和Vue开发思路区别。从寻找DOM到数据驱动，前端开发的一次巨大变革。
+
+Vue的入门做清单应用：先要有输入框能输入文本，并且在输入框下方循环显示清单，我们用到了v-model，v-for这些功能。这些v-开头的属性都是Vue自带写法，我们通过{{}}包裹的形式显示数据。
+
+用户输入完成后回车新增一条数据，就用到@开头的几个属性，@keyup和@click都是绑定对应的交互事件。
+
+最后，通过computed，我们能对页面数据的显示进行优化。我们所需要关心的，就是数据的变化。
+
+## FAQ
+
+现在所有的操作状态一刷新就都没了，咋解决？
\ No newline at end of file
diff --git a/docs/md/vue/vue-js-vs-axios-practical-guide-from-ajax-requests-to-api-proxy-configuration.md b/docs/md/vue/vue-js-vs-axios-practical-guide-from-ajax-requests-to-api-proxy-configuration.md
new file mode 100644
index 0000000000..dc7a835e45
--- /dev/null
+++ b/docs/md/vue/vue-js-vs-axios-practical-guide-from-ajax-requests-to-api-proxy-configuration.md
@@ -0,0 +1,145 @@
+# Vue.js 与 Axios 实战：从发送 AJAX 请求到 API 代理配置全攻略
+
+## 0 前言
+
+Axios，流行的 js 库，用于发送 AJAX 请求。本文介绍Vue中咋用 Axios 发 AJAX 请求。
+
+## 1 安装
+
+先在项目中安装 Axios。进入项目目录运行：
+
+```bash
+cnpm install axios@0.17.1 --save
+```
+
+## 2 发送 AJAX 请求
+
+在 Vue 组件中用它发 AJAX 请求。
+
+### 示例
+
+```vue
+
+
+
+
+
+```
+
+在 `getData` 方法中，用 `axios.get` 方法发送 GET 请求。该方法接受一个 URL 参数，用于指定要请求的服务器端点。本例用 `/api/data` 作为 URL。
+
+再用 Promise 的 `then` 方法处理响应，如果：
+
+- 请求成功，`then` 将接收一个响应对象，并将响应数据存储到组件的 `data` 属性中
+- 请求失败，则用 Promise 的 `catch` 方法处理错误
+
+最后，在组件模板中，用一个按钮触发 `getData` 方法，并根据是否有数据来显示数据。
+
+## 3 项目实战
+
+组件很多，若每个组件都发 HTTP 请求，性能太差。咋优化？希望整个首页只发送一个 ajax 请求。显然，在 Home.vue 里发送最好不过。
+
+组件有个生命周期函数 mounted：
+
+```js
+methods: {
+ getHomeInfo () {
+ // 本地 mock 数据
+ // axios.get('/api/index.json?city=' + this.city)
+ axios.get('/static/mock/index.json')
+ .then(this.getHomeInfoSuccess)
+ },
+ getHomeInfoSuccess (res) {
+ }
+},
+mounted () {
+ this.getHomeInfo()
+}
+```
+
+有人觉得，本地mock 执行
+
+```js
+axios.get('/static/mock/index.json')
+ .then(this.getHomeInfoSuccess)
+```
+
+上线前，再改成
+
+```js
+axios.get('/api/index.json?city=' + this.city)
+```
+
+真麻烦，万一忘了，很烦。还好 Vue 帮解决这问题。修改脚手架文件：index.js
+
+
+
+```js
+'use strict'
+// Template version: 1.3.1
+// see http://vuejs-templates.github.io/webpack for documentation.
+
+const path = require('path')
+
+module.exports = {
+ dev: {
+
+ // Paths
+ assetsSubDirectory: 'static',
+ assetsPublicPath: '/',
+ /**
+ * webpack-dev-server 提供的功能
+ *
+ * /api开头的请求代理到http://localhost:8080/static/mock
+ * proxyTable是一个对象，用于配置代理规则
+ * '/api'是代理规则的路径，表示所有以/api开头的请求都会被代理
+ * target是代理的目标地址，即将请求转发到的地址
+ * pathRewrite是路径重写规则，用于将请求路径中的'/api'替换成'/static/mock'
+ */
+ proxyTable: {
+ '/api': {
+ target: 'http://localhost:8080',
+ pathRewrite: {
+ '^/api': '/static/mock'
+ }
+ }
+ },
+```
+
+改变了配置项，所以需要重启服务：
+
+可见，请求成功，拿到数据了：
+
+
+
+## 4 总结
+
+功能强大的 js 库，可发送 AJAX 请求。在 Vue 中使用 Axios 可轻松与服务器进行通信，并从服务器获取数据。
\ No newline at end of file
diff --git a/package-lock.png b/package-lock.png
deleted file mode 100644
index 3db68806c1..0000000000
Binary files a/package-lock.png and /dev/null differ