实现即时通讯主要有四种方式，它们分别是短轮询、长轮询、长连接、WebSocket

1. 短轮询

1.1 说明

传统的web通信模式。后台处理数据，需要一定时间，前端想要知道后端的处理结果，就要不定时的向后端发出请求以获得最新情况，得到想要的结果，或者超出规定的最长时间就终止再发请求。

1.2 优点：

前后端程序编写比较容易

1.3 缺点：

• 效率低：轮询的请求间隔时间一般是固定的，无论服务器是否有新的数据，都需要等待一段固定的时间。当数据更新的频率较低时，大部分请求都是无效的；


• 实时性差：如果数据在两次请求间发生了更新，那么用户只能在下一次轮询时才能得到最新数据；


• 浪费资源：高频率的操作功能，或者页面访问，导致的大量用户使用轮询时，会占用大量的网络资源，降低整体网络速度

1.4 基础实现：

每隔一段时间发送一个请求即可，得到想要的结果，或者超出规定的最长时间就终止再发请求。

let count = 0;

const timer = null;

// 超时时间

const MAX_TIME = 10 * 1000;

// 心跳间隙

const HEARTBEAT_INTERVAL = 1000; 



/**

 * @description: 模拟请求后端数据 （第6次时返回true）

 */

const fetchData = () => {

  return new Promise((resolve, reject) => {

    setTimeout(() => {

      console.log('fetch data...', count)

      count += 1 

      if(count === 5) {

        resolve(true);

      }else {

        resolve(false);

      }

    }, 1000)

  });

};



/**

 * @description: 异步轮询，当超时时或者接口返回true时，中断轮询

 */

const doSomething = async () => {

  try {

    let startTime = 0;

    const timer = setInterval(async ()=>{

      const res = await fetchData();

      startTime += HEARTBEAT_INTERVAL;

      if(res || startTime > MAX_TIME) {

        clearInterval(timer)

      }

    }, HEARTBEAT_INTERVAL)



  } catch (err) {

    console.log(err);

  }

};



doSomething();

2. 长轮询

2.1 说明

客户端向服务器发送Ajax请求，服务器接到请求后hold住连接，直到有新消息才返回响应信息并关闭连接，客户端处理完响应信息后再向服务器发送新的请求

长轮询的实现原理与轮询类似，只是客户端的请求会保持打开状态，直到服务器返回响应或超时。在服务器端，可以使用阻塞方式处理长轮询请求，即服务器线程会一直等待直到有新的数据或事件，然后返回响应给客户端。客户端收到响应后，可以处理数据或事件，并随后发送下一个长轮询请求。

2.2 优点

长轮询相较于轮询技术来说，减少了不必要的网络流量和请求次数，降低了服务器和客户端的资源消耗

2.3 缺点

但是相对于传统的轮询技术，长轮询的实现更加复杂，并且需要服务器支持长时间保持连接的能力。

2.4 基础实现

超时和未得到想要的结果都需要重新执行原方法（递归实现）

async function subscribe() {

  let response = await fetch("/subscribe");



  if (response.status == 502) {

    // 状态 502 是连接超时错误，

    // 连接挂起时间过长时可能会发生，

    // 远程服务器或代理会关闭它

    // 让我们重新连接

    await subscribe();

  } else if (response.status != 200) {

    // 一个 error —— 让我们显示它

    showMessage(response.statusText);

    // 一秒后重新连接

    await new Promise(resolve => setTimeout(resolve, 1000));

    await subscribe();

  } else {

    // 获取并显示消息

    let message = await response.text();

    showMessage(message);

    // 再次调用 subscribe() 以获取下一条消息

    await subscribe();

  }

}



subscribe();

3. 长链接

3.1 说明

HTTP keep-alive 也称为 HTTP 长连接。它通过重用一个 TCP 连接来发送/接收多个 HTTP请求，来减少创建/关闭多个 TCP 连接的开销

3.1.1 为什么HTTP是短连接？

HTTP是短连接，客户端向服务器发送一个请求，得到响应后，连接就关闭。

例如，用户通过浏览器访问一个web站点上的某个网页，当网页内容加载完毕之后（已得到响应），用户可能需要花费几分钟甚至更多的时间来浏览网页内容，此时完全没有必要继续维持底层连。当用户需要访问其他网页时，再创建新的连接即可。

因此，HTTP连接的寿命通常都很短。这样做的好处是，可以极大的减轻服务端的压力。一般而言，一个站点能支撑的最大并发连接数也是有限的，

面对这么多客户端浏览器，不可能长期维持所有连接。每个客户端取得自己所需的内容后，即关闭连接，更加合理。

3.1.2 为什么要引入keep-alive（也称HTTP长连接）

通常一个网页可能会有很多组成部分，除了文本内容，还会有诸如：js、css、图片等静态资源，有时还会异步发起AJAX请求。

只有所有的资源都加载完毕后，我们看到网页完整的内容。然而，一个网页中，可能引入了几十个js、css文件，上百张图片，

如果每请求一个资源，就创建一个连接，然后关闭，代价实在太大了。

基于此背景，我们希望连接能够在短时间内得到复用，在加载同一个网页中的内容时，尽量的复用连接，这就是HTTP协议中keep-alive属性的作用。

• HTTP 1.0 中默认是关闭的，需要在http头加入"Connection: Keep-Alive"，才能启用Keep-Alive；


• HTTP 1.1 中默认启用Keep-Alive，如果加入"Connection: close "，才关闭

注意：这里复用的是 TCP连接，并不是复用request

HTTP 的 Keep-Alive 也叫 HTTP 长连接，该功能是由「应用程序」实现的，可以使得用同一个 TCP 连接来发送和接收多个 HTTP 请求/应答，减少了 HTTP 短连接带来的多次 TCP 连接建立和释放的开销。

TCP 的 Keepalive 也叫 TCP 保活机制，该功能是由「内核」实现的，当客户端和服务端长达一定时间没有进行数据交互时，内核为了确保该连接是否还有效，就会发送探测报文，来检测对方是否还在线，然后来决定是否要关闭该连接

4. WebSocket

4.1 说明

Websocket是基于HTTP协议的，在和服务端建立了链接后，服务端有数据有了变化后会主动推送给前端；

一般可以用于 股票交易行情分析、聊天室、在线游戏，替代轮询和长轮询。

4.2 优点

请求响应快，不浪费资源。（传统的http请求，其并发能力都是依赖同时发起多个TCP连接访问服务器实现的(因此并发数受限于浏览器允许的并发连接数)，而websocket则允许我们在一条ws连接上同时并发多个请求，即在A请求发出后A响应还未到达，就可以继续发出B请求。由于TCP的慢启动特性（新连接速度上来是需要时间的），以及连接本身的握手损耗，都使得websocket协议的这一特性有很大的效率提升；http协议的头部太大，且每个请求携带的几百上千字节的头部大部分是重复的，websocket则因为复用长连接而没有这一问题。）

4.3 缺点

• 主流浏览器支持的Web Socket版本不一致；


• 服务端没有标准的API。

4.4 基础实现

这里使用了一个 网页和打印app的通信举例（部分敏感代码已省略）

const printConnect = () => {

    try {

      const host = 'ws://localhost:13888'

      cloundPrintInfo.webSocket = new WebSocket(host)



      // 通信

      cloundPrintInfo.webSocket.onopen = () => {

        // 获取打印机列表

        cloundPrintInfo.webSocket.send(

        JSON.stringify({

          cmd: 'getPrinters',

          version: '1.0',

        })

      )

      }



      // 通信返回

      cloundPrintInfo.webSocket.onmessage = (msg: any) => {

        

        const { data: returnData } = msg

     

        // code  1000: 全部成功  1001: 部分失败  1002: 全部失败

        const { cmd } = JSON.parse(`${returnData}`)

       

        // 获取打印机数据

        if (cmd === 'GETPRINTERS') {

          printerInfoSet(returnData)

        }



        // 处理发送打印请求结果

        if (cmd === 'PRINT') {

          handlePrintResult(returnData)

        }



        // 批量推送打印结果

        if (cmd === 'NOTIFYPRINTRESULT') {

          cloudPrintTip(returnData)

        }

      }



      // 通信失败

      cloundPrintInfo.webSocket.onerror = () => {

        printClose()

      }



      // 关闭通信

      cloundPrintInfo.webSocket.onclose = () => {

        printClose()

      }

    } catch (exception) {

      console.log('建立连接失败', exception)

      printClose()

    }

  }

在实际应用中，你可能需要处理更复杂的情况，比如重连逻辑、心跳机制来保持连接活跃、以及安全性问题等

重连逻辑：当WebSocket连接由于网络问题或其他原因断开时，客户端可能需要自动尝试重新连接

var socket;

var reconnectInterval = 5000; // 重连间隔时间，例如5秒



function connect() {

  socket = new WebSocket('ws://localhost:3000');



  socket.onopen = function(event) {

    console.log('Connected to the WebSocket server');

  };



  socket.onclose = function(event) {

    console.log('WebSocket connection closed. Reconnecting...');

    setTimeout(connect, reconnectInterval); // 在指定时间后尝试重连

  };



  socket.onerror = function(error) {

    console.error('WebSocket error:', error);

    socket.close(); // 确保在错误后关闭连接，触发重连

  };

}



connect(); // 初始连接

心跳机制：指定期发送消息以保持连接活跃的过程。这可以防止代理服务器或负载均衡器因为长时间的不活动而关闭连接

function heartbeat() {

  if (socket.readyState === WebSocket.OPEN) {

    socket.send('ping'); // 发送心跳消息，内容可以是'ping'

  }

}



// 每30秒发送一次心跳

var heartbeatInterval = setInterval(heartbeat, 30000);



// 清除心跳定时器，通常在连接关闭时调用

function clearHeartbeat() {

  clearInterval(heartbeatInterval);

}



socket.onclose = function(event) {

  clearHeartbeat();

};

4种对比

从兼容性角度考虑，短轮询>长轮询>长连接SSE>WebSocket；

从性能方面考虑，WebSocket>长连接SSE>长轮询>短轮询。

参考文章：

• Http——Keep-Alive机制

1. 背景

今天刷到一篇文章，标题是反射为什么慢，一下子懵逼了，确实没想过这个问题；盲猜了一下是由于反射实际上是做了一个代理的动作，导致执行的效率是小于直接实体类去调用方法的。

2. 文章给出的解释

文章中给出的理由是因为以下4点：

3. 结合实际理解

3.1 第一点分析

首先我们需要知道，java中的反射是一种机制，它可以在代码运行过程中，获取类的内部信息（变量、构造方法、成员方法）；操作对象的属性、方法。
然后关于反射的原理，首先我们需要知道一个java项目在启动之后，会将class文件加载到堆中，生成一个class对象，这个class对象中有一个类的所有信息，通过这个class对象获取类相关信息的操作我们称为反射。

其次是JIT优化技术，首先我们需要知道在java虚拟机中有两个角色，解释器和编译器；这两者各有优劣，首先是解释器可以在项目启动的时候直接直接发挥作用，省去编译的时候，立即执行，但是在执行效率上有所欠缺；在项目启动之后，随着时间推移，编译器逐渐将机器码编译成本地代码执行，减少解释器的中间损耗，增加了执行效率。

我们可以知道JIT优化通常依赖于在编译时能够知道的静态信息，而反射的动态性可能会破坏这些假设，使得JIT编译器难以进行有效的优化。

3.2 第二点

关于第二点，我们直接写一段反射调用对象方法的demo：

@Test

public void methodTest() {

    Class clazz = MyClass.class;



    try {

        //获取指定方法

        //这个注释的会报错 java.lang.NoSuchMethodException

        //Method back = clazz.getMethod("back");

        Method back = clazz.getMethod("back", String.class);

        Method say = clazz.getDeclaredMethod("say", String.class);

        //私有方法需要设置

        say.setAccessible(true);

        MyClass myClass = new MyClass("abc", 99);

        //反射调用方法

        System.out.println(back.invoke(myClass, "back"));



        say.invoke(myClass, "hello world");

    } catch (Exception e) {

        e.printStackTrace();

    }

}

在上面这段代码中，我们调用了一个invoke 方法，并且传了class对象和参数，进入到invoke方法中，我们可以看到invoke方法的入参都是Object类型的，args更是一个Object 数组，这就第二点，关于反射调用过程中的拆装箱。

@CallerSensitive

public Object invoke(Object obj, Object... args)

    throws IllegalAccessException, IllegalArgumentException,

        InvocationTargetException

{

    if (!override) {

        if (!Reflection.quickCheckMemberAccess(clazz, modifiers)) {

            Class<?> caller = Reflection.getCallerClass();

            checkAccess(caller, clazz, obj, modifiers);

        }

    }

    MethodAccessor ma = methodAccessor;             // read volatile

    if (ma == null) {

        ma = acquireMethodAccessor();

    }

    return ma.invoke(obj, args);

}

3.3 第三点

关于调用方法需要遍历这点，还是上面那个demo，我们在获取Method 对象的时候是通过调用getMethod、getDeclaredMethod方法，点击进入这个方法的源码，我们可以看到如下代码：

private static Method searchMethods(Method[] methods,

                                    String name,

                                    Class<?>[] parameterTypes)

{

    Method res = null;

    String internedName = name.intern();

    for (int i = 0; i < methods.length; i++) {

        Method m = methods[i];

        if (m.getName() == internedName

            && arrayContentsEq(parameterTypes, m.getParameterTypes())

            && (res == null

                || res.getReturnType().isAssignableFrom(m.getReturnType())))

            res = m;

    }



    return (res == null ? res : getReflectionFactory().copyMethod(res));

}

我们可以看到，底层实际上也是将class对象的所有method遍历了一遍，最终才拿到我们需要的方法的，这也就是第二点，执行具体方法的时候需要遍历class对象的方法。

3.4 第四点

第4点说需要对方法和参数进行检查，也就是我们在执行具体的某一个方法的时候，我们实际上是需要校验这个方法是否可见的，如果不可见，我们还需要将这个方法设置为可见，否则如果我们直接调用这个方法的话，会报错。

同时还有一个点，在我们调用invoke方法的时候，反射类会对方法和参数进行一个校验，让我们来看一下源码：

@CallerSensitive

public Object invoke(Object obj, Object... args)

    throws IllegalAccessException, IllegalArgumentException,

        InvocationTargetException

{

    if (!override) {

        if (!Reflection.quickCheckMemberAccess(clazz, modifiers)) {

            Class<?> caller = Reflection.getCallerClass();

            checkAccess(caller, clazz, obj, modifiers);

        }

    }

    MethodAccessor ma = methodAccessor;             // read volatile

    if (ma == null) {

        ma = acquireMethodAccessor();

    }

    return ma.invoke(obj, args);

}

我们可以看到还有quickCheckMemberAccess、checkAccess 等逻辑

4. 总结

平时在反射这块用的比较少，也没针对性的去学习一下。在工作之余，还是得保持一个学习的习惯，这样子才不会出现今天这种被一个问题难倒的情况，而且才能产出更多、更优秀的方案。

掘金2024年度人气创作者打榜中，快来帮我打榜吧～ activity.juejin.cn/rank/2024/w…

大家好，我是每天分享AI应用的萤火君！

最近OpenAI一连搞了十几天的新品直播，虽然热度不是特别高，但是也确实爆出了一些比较有意思的东西，比如GPT o3，据说编程能力已经超过 99.9%的程序员（某程序员竞赛的前200名:codeforces.com/ratings），我等码农是不是要哭晕在厕所了？

程序员的出路在哪里？

AI编程革命

谈到这一轮的AI革命，很多人会类比工业革命。在工业革命初期，随着机器的普及应用，很多手工业者丢了生计，但也有一批手动业者主动进化，学会了机器的操作方法，在新的时代里依然抢手。

所以最新的说法是：AI不会革所有人的命，AI革的是不会使用AI的人的命。

这种说法是站的住脚的。

就我个人而言，写代码已经离不开AI了，遇到不会写的代码就问AI已经是家常便饭，甚至有了什么思路之后，直接就让AI先写一个实现，感觉不好的话，再让AI重写，一般都能得出满意的结果。这比自己苦思冥想、到处去查资料要快上不少，甚至结果也往往更好。当然这里边还有一些前提条件，比如你要把自己的想法清晰的表达出来。

就像人们对商品的需求是广泛且持续存在的，软件的需求也是广泛且持续存在的。使用AI可以提升软件程序的生产效率，如果你花1天时间可以写出100分的程序，那么使用AI，很可能只需要几分钟的时间就能写出至少80分的程序，这里边的生产力差距是很明显的，所以AI对于编程而言，自然也是一场革命。

历史证明，不想被淘汰，只能积极的拥抱新的生产工具。学会使用AI编程，自然也成了程序员在AI时代的必备能力。

AI编程的要点

就像大家都写程序，有的人写的好，有的人写不出来。使用AI编程也是，有的人效率大幅提升，有的人生成的代码没法用，还耽误时间。

为什么会这样？

我个人的观点是：不得要领。

编写代码的要领是：掌握各种编程规则，并在各种解决方案中做好权衡。很多同学以代码能跑起来为最终目标，不管性能，也不考虑维护、扩展，这样很难写出优秀的程序，自然也成不了高手。

AI编程的要领是什么呢？

讲清楚

我们还是在编程，所以编程的要领还是要掌握，但是又增加了AI的方式，就需要结合AI的特性。

这里边最主要的问题就是讲不清楚，程序员们往往知道怎么去实现，但是很难给别人讲明白。而使用生成式AI，一个很重要的工作是编写提示词，也就是把你想要的东西通过文字清晰明白的表达出来。

举个简单的例子，你想要让AI设计一个商城的数据库，如果你只是简单的告诉它：帮我设计一个商城的数据库。

它很大概率上是很难生成直接可用的代码的，因为它不知道你要使用什么数据库，也不知道你的商品和订单是怎么管理的，更不清楚你的订单量是什么样的规模，这些都会影响数据库的设计。AI大概率会给你了一个路边摊的方案，然后被你鄙视一番。

要想让AI输出高质量的内容，我们必须把问题的上下文讲清楚，以AI能够理解的方式告诉它。在数据库的例子中，可能包括：你的商城都有哪些功能，商品品类如何组织，商品有哪些属性，每天的订单量如何，订单的流转过程如何，等等。

有时候对于一个复杂的系统，一轮对话是不够的，可能需要多轮对话，比如先讲一下你的商城功能有哪些、业务规模如何，然后让AI给你一些数据库的选型建议；然后再基于你选择的数据库，通过各个部分的描述，让AI给出具体领域的设计。

好模型

工欲善其事，必先利其器。

AI模型的性能也很重要，这里说的模型性能是AI模型生成结果的质量问题。

了解过大语言模型的同学应该都听说过OpenAI，作为大语言模型的领导者，它的ChatGPT是顶好的，对于同样的问题，ChatGPT往往能理解的更为准确，也能给出质量更高的答案。对于编程来说，就是它输出的代码能正常跑起来，而很多模型给出的答案经常跑不起来，各种报错。

根据我的测试体验，目前 GPT 4o 和 Claude 3.5 Sonnet 在编程方面的能力比较领先，国产的 通义灵码 也不错，但是有时给出的方案还是差强人意，有点路边摊的感觉，输出过多不太重要的东西，沟通效率上差一些，应该还是基础模型的能力不够强。

当下，从效率方面看，使用更好的模型确实可以节约一些时间。

程序员的未来

所有的工作都是基于需求产生的，程序员也不例外。

计算机出现以后，人们需要使用计算机来完成大量繁复的计算任务，随着计算能力的增强和计算范围的拓展，人们又需要使用计算机来运行各种各样的软件程序。但是人和机器打交道特别困难，最开始使用0和1的机器码，这不是一般人能玩的溜的，后来虽然又搞出了各种各样的先进技术和编程语言，但是计算任务的复杂度也进一步提升，对专业人士的需求不减反增，程序员就是这类专业人士。

现在大语言模型来了，AI编程革命愈演愈烈，程序员何去何从？

绝对数量的减少

我们还是从需求出发。

首先假设计算任务的需求并没有明显减少，也没有明显增多，也就是程序的需求没有减少；但是使用AI之后编写程序的效率会提升，也就是说个体生产力会提升；在总体需求不变的情况下，个体生产力的提升就会减少对个体数量的需求。在这个假设中，一些程序员不得不出局。

那么这个假设是否成立呢？

当前国内有一个现象很突出，很多厂子经历了一轮又一轮的裁员，很多同学离职后有很长时间的空窗期，整个社会对程序员的需求明显在减少。但是AI的发展必然又带来新的工作机会，比如提示工程师、模型训练工程师、AI应用开发工程师，如果我们把这些新的岗位也划到程序员的行列，但是它们足以抵消社会对传统程序员的需求减少吗？

我想不能够，因为使用AI的效率更高，则需要人贡献的力量就会更少。也许AI会创造更多的其它工种，但是对以编程为生的程序员的需求一定是减少的。

需求和技术的平衡

随着AI模型能力的持续增强，手写代码的机会越来越少，但是AI的能力长时间内始终有所欠缺，比如：理解用户的需求，在各种技术方案中做出权衡等，而且AI的伦理问题一时半会也很难解决，程序出了问题还要有人来背锅。

所以程序员的大部分工作将是：

理解用户需求，然后让AI实现用户的需求，并对生成的结果进行调整和把关。

理解用户需求：注意这里说的是理解用户需求，而不是理解产品经理给出的产品设计。当下，程序员编写程序本来也是需要理解产品设计的，但是好的程序只是理解了产品经理的输出还是不够的，产品经理的主要问题是缺乏技术的敏感度，这需要程序员来补齐，并在产品中有所体现。而且如果程序员写代码的时间少了，那老板自然不会让你闲着，直接对接用户可能是一个方向。

让AI实现用户的需求：这里关注的是程序员的语言表达能力，你得能把问题说清楚，知道如何与AI进行交互，让AI更好的完成编码工作。这是一项需要重点打造的能力。

对生成的结果进行调整和把关： AI对整体的把握能力仍然十分有限，虽然很多模型都号称支持多少K的上下文，但是真正用于实际的时候还是会丢三拉四，不够可靠。人要来把关的话，对技术的理解仍然十分钟重要，因为人要做决策，什么能做，什么不能做，什么情况适合采用什么样的方案，都要考虑清楚。

现在也有一些公司在做AI程序员，让一帮AI来扮演各种角色，来实现一个软件程序的开发。似乎程序员马上就要失业了，但是对于一个有着几年开发经验的同学来说，应该能够理解：一个包含各种复杂逻辑的业务系统，AI还是很难搞清楚的，短期内也很难代替人来做决策。

总结

AI的引入显著提高了编程效率，使得高质量代码的生成速度大大加快。面对未来，尽管传统编程岗位的需求可能减少，但新的职业机会也在不断涌现，程序员同学们要积极适应变化，充分利用AI的优势，掌握清晰表达需求的能力，了解如何有效沟通以获得最佳的AI输出，同时还要持续提升自身技术素养，以便更好地理解用户需求、指导AI工作及审核最终结果。

hi, 大家好, 我是徐小夕. 

5年前就开始着手设计和研发可视化大屏编辑器, 当时低代码在国内还没有现在那么火, 有人欢喜有人哀, 那个时候我就比较坚定的认为无码化搭建未来一定是个趋势, 能极大的帮助企业提高研发效率和降低研发成本, 所以 all in 做了2年, 上线了一个相对闭环的MVP可视化大屏搭建平台——V6.Dooring.

通过在技术社区不断的分享可视化搭建的技术实践和设计思路, 也参与了很多线上线下的技术分享, 慢慢市场终于“热了”起来.(机缘巧合)

从V6.Dooring的技术架构的设计, 到团队组建, 再到帮助企业做解决方案, 当时几乎所有的周末都花在这上面了, 想想收获还是挺大的, 接触到了形形色色的企业需求, 也不断完整着可视化大屏编辑器的功能, 最后推出了一个还算通用的解决方案:

当然上面介绍的还都不是这篇文章的重点.

重点是, 时隔4年, 我们打算把通用的可视化大屏解决方案, 开源! 

一方面是供大家学习参考, 更好的解决企业自身的业务需求, 另一方面可以提供一个技术交流的平台, 大家可以对可视化搭建领域的技术实践, 提出自己的想法和观点, 共同打造智能化, 体验更好的搭建产品.

先上github地址: github.com/MrXujiang/v…

V6.Dooring开源大屏编辑器演示

其实最近几年我在掘金专栏分享了很多零代码和可视化搭建的技术实现和产品设计:

可视化低代码技术精粹

 这里为了让大家更近一步了解V6-Dooring可视化大屏编辑器, 我还是会从技术设计到产品解决方案设计的角度, 和大家详细分享一下, 让大家在学习我们可视化大屏开源方案的过程中, 对可视化搭建技术产品, 有更深入的理解.

如果大家觉得有帮助, 不要忘记点赞 + 收藏哦, 后面我会持续分享最干的互联网干货.

你将收获

• 可视化大屏产品设计思路


• 主流可视化图表库技术选型


• 大屏编辑器设计思路


• 大屏可视化编辑器Schema设计


• 用户数据自治探索

方案实现

1.可视化大屏产品设计思路

目前很多企业或多或少的面临“信息孤岛”问题，各个系统平台之间的数据无法实现互通共享，难以实现一体化的数据分析和实时呈现。

相比于传统手工定制的图表与数据仪表盘，可视化大屏制作平台的出现，可以打破抵消的定制开发, 数据分散的问题，通过数据采集、清洗、分析到直观实时的数据可视化展现，能够多方位、多角度、全景展现各项指标，实时监控，动态一目了然。

针对以上需求, 我们设计了一套可视化大屏解决方案, 具体包含如下几点:

上图是笔者4个月前设计的基本草图, 后期会持续更新. 通过以上的设计分解, 我们基本可以搭建一个可自己定制的数据大屏.

2.主流可视化图表库技术选型

目前我调研的已知主流可视化库有:

• echart 一个基于 JavaScript 的老牌开源可视化图表库


• D3.js 一个数据驱动的可视化库, 可以不需要其他任何框架独立运行在现代浏览器中，它结合强大的可视化组件来驱动 DOM 操作


• antv 包含一套完整的可视化组件体系


• Chart.js 基于 HTML5 的 简单易用的 JavaScript 图表库


• metrics-graphics 建立在D3之上的可视化库, 针对可视化和布置时间序列数据进行了优化


• C3.js 通过包装构造整个图表所需的代码，使生成基于D3的图表变得容易

我们使用以上任何一个库都可以实现我们的可视化大屏搭建的需求, 各位可以根据喜好来选择.

3.大屏编辑器设计思路

在上面的分析中我们知道一个大屏编辑器需要有个编辑器核心, 主要包含以下部分:

• 组件库


• 拖拽(自由拖拽, 参考线, 自动提示)


• 画布渲染器


• 属性编辑器

如下图所示:

组件库我们可以用任何组件封装方式(react/vue等), 这里沿用H5-Dooring的可视化组件设计方式, 对组件模型进行优化和设计.

类似的代码如下:

import { Chart } from '@antv/f2';

import React, { memo, useEffect, useRef } from 'react';



import styles from './index.less';

import { IChartConfig } from './schema';



const XChart = (props:IChartConfig) => {

  const { data, color, size, paddingTop, title } = props;

  const chartRef = useRef(null);

  useEffect(() => {

      const chart = new Chart({

        el: chartRef.current || undefined,

        pixelRatio: window.devicePixelRatio, // 指定分辨率

      });



      // step 2: 处理数据

      const dataX = data.map(item => ({ ...item, value: Number(item.value) }));



      // Step 2: 载入数据源

      chart.source(dataX);



      // Step 3：创建图形语法，绘制柱状图，由 genre 和 sold 两个属性决定图形位置，genre 映射至 x 轴，sold 映射至 y 轴

      chart

        .interval()

        .position('name*value')

        .color('name');



      // Step 4: 渲染图表

      chart.render();

  }, [data]);

  return (

    <div className={styles.chartWrap}>

      <div className={styles.chartTitle} style={{ color, fontSize: size, paddingTop }}>

        {title}

      </div>

      <canvas ref={chartRef}></canvas>

    </div>

  );

};



export default memo(XChart);

以上只是一个简单的例子, 更具业务需求的复杂度我们往往会做更多的控制, 比如动画(animation), 事件(event), 数据获取(data inject)等.

当然实际应用中大屏展现的内容和形式远比这复杂， 我们从上图可以提炼出大屏页面的2个直观特征:

• 可视化组件集


• 空间坐标关系

因为我们可视化大屏载体是页面， 是html， 所以还有另外一个特征: 事件/交互。综上我们总结出了可视化大屏的必备要素:

我们只要充分的理解了可视化大屏的组成和特征， 我们才能更好的设计可视化大屏搭建引擎， 基于以上分析， 我设计了一张基础引擎的架构图:

接下来我就带大家一起来拆解并实现上面的搭建引擎。

大屏搭建引擎核心功能实现

俗话说: “好的拆解是成功的一半”， 任何一个复杂任务或者系统， 我们只要能将其拆解成很多细小的子模块， 就能很好的解决并实现它. (学习也是一样)

接下来我们就逐一解决上述基础引擎的几个核心子模块:

• 拖拽器实现


• 物料中心设计


• 动态渲染器实现


• 配置面板设计


• 控制中心概述


• 功能辅助设计

1.拖拽器实现

拖拽器是可视化搭建引擎的核心模块， 也是用来解决上述提到的大屏页面特征中的“空间坐标关系”这一问题。我们先来看一下实现效果:

组件拖拽可以采用市面已有的 Dragable 等插件, 也可以采用 H5-Dooring 的智能网格拖拽. 这里笔者选择自由拖拽来实现. 已有的有:

• rc-drag


• sortablejs


• react-dnd


• react-dragable


• vue-dragable

等等. 具体拖拽呈现流程如下:

具体拖拽流程就是:

组件的schema参考H5-Dooring DSL设计.

2.物料中心设计

物料中心主要为大屏页面提供 “原材料”。为了设计健壮且通用的物料， 我们需要设计一套标准组件结构和属性协议。并且为了方便物料管理和查询， 我们还需要对物料进行分类， 我的分类如下:

• 可视化组件 (柱状图， 饼图， 条形图， 地图可视化等)


• 修饰型组件 (图片， 轮播图， 修饰素材等)


• 文字类组件 (文本， 文本跑马灯， 文字看板)

具体的物料库演示如下:

这里我拿一个可视化组件的实现来举例说明:

import React， { memo， useEffect } from 'react'

import { Chart } from '@antv/g2'



import { colors } from '@/components/BasicShop/common'



import { ChartConfigType } from './schema'



interface ChartComponentProps extends ChartConfigType {

  id: string

}



const ChartComponent: React.FC<ChartComponentProps> = ({

  id, data, width, height,

  toggle, legendPosition, legendLayout, legendShape,

  labelColor, axisColor, multiColor, tipEvent, titleEvent,

  dataType, apiAddress, apiMethod, apiData, refreshTime,

}) => {

  useEffect(() => {

    let timer:any = null;

    const chart = new Chart({

      container: `chart-${id}`,

      autoFit: true,

      width,

      height

    })



    // 数据过滤， 接入

    const dataX = data.map(item => ({ ...item, value: Number(item.value) }))

    chart.data(dataX)

    

    // 图表属性组装

    chart.legend(

      toggle

        ? {

          position: legendPosition,

          layout: legendLayout,

          marker: {

            symbol: legendShape

          },

        }

        : false,

    )



    chart.tooltip({

      showTitle: false,

      showMarkers: false,

    })



    // 其他图表信息源配置， 方法雷同， 此处省略

    // ...



    chart.render()



  }, [])



  return <div id={`chart-${id}`} />

}



export default memo(ChartComponent)

以上就是我们的基础物料的实现模式， 可视化组件采用了g2， 当然大家也可以使用熟悉的echart， D3.js等. 不同物料既有通用的 props ， 也有专有的 props， 取决于我们如何定义物料的Schema。

在设计 Schema 前我们需要明确组件的属性划分， 为了满足组件配置的灵活性和通用性， 我做了如下划分:

• 外观属性 (组件宽高， 颜色， 标签， 展现模式等)


• 数据配置 (静态数据， 动态数据)


• 事件/交互 (如单击， 跳转等)

有了以上划分， 我们就可以轻松设计想要的通用Schema了。我们先来看看实现后的配置面板:

这些属性项都是基于我们定义的schema配置项， 通过 解析引擎 动态渲染出来的， 有关 解析引擎 和配置面板， 我会在下面的章节和大家介绍。我们先看看组件的 schema 结构:

const Chart: ChartSchema = {

  editAttrs: [

    {

      key: 'layerName',

      type: 'Text',

      cate: 'base'，

    },

    {

      key: 'y',

      type: 'Number',

      cate: 'base',

    },

    ...DataConfig, // 数据配置项

    ...eventConfig, // 事件配置项

    

  ]，

  config: {

    width: 200,

    height: 200,

    zIndex: 1,

    layerName: '柱状图',

    labelColor: 'rgba(188，200，212，1)',

    // ... 其他配置初始值

    multiColor: ['rgba(91, 143, 249, 1)', 'rgba(91, 143, 249, 1)', 'rgba(91, 143, 249，,1)', 'rgba(91, 143, 249, 1)'],

    data: [

      {

        name: 'A',

        value: 25,

      }，

      {

        name: 'B',

        value: 66,

      }

    ],

  },

}

其中 editAttrs 表示可编辑的属性列表， config 为属性的初始值， 当然大家也可以根据自己的喜好， 设计类似的通用schema。

我们通过以上设计的标准组件和标准schema， 就可以批量且高效的生产各种物料， 还可以轻松集成任何第三方可视化组件库。

3.动态渲染器实现

我们都知道， 一个页面中元素很多时会影响页面整体的加载速度， 因为浏览器渲染页面需要消耗CPU / GPU。对于可视化页面来说， 每一个可视化组件都需要渲染大量的信息元， 这无疑会对页面性能造成不小的影响， 所以我们需要设计一种机制， 让组件异步加载到画布上， 而不是一次性加载几十个几百个组件(这样的话页面会有大量的白屏时间， 用户体验极度下降)。

动态加载器就是提供了这样一种机制， 保证组件的加载都是异步的， 一方面可以减少页面体积， 另一方面用户可以更早的看到页面元素。目前我们熟的动态加载机制也有很多， Vue 和 React 生态都提供了开箱即用的解决方案(虽然我们可以用 webpack 自行设计这样的动态模型， 此处为了提高行文效率， 我们直接基于现成方案封装)。我们先看一下动态渲染组件的过程:

上面的演示可以细微的看出从左侧组件菜单拖动某个组件图标到画布上后， 真正的组件才开始加载渲染。

这里我们以 umi3.0 提供的 dynamic 函数来最小化实现一个动态渲染器. 如果不熟悉 umi 生态的朋友， 也不用着急， 看完我的实现过程和原理之后， 就可以利用任何熟悉的动态加载机制实现它了。实现如下:

import React, { useMemo, memo, FC } from 'react'

import { dynamic } from 'umi'



import LoadingComponent from '@/components/LoadingComponent'





const DynamicFunc = (cpName: string, category: string) => {

  return dynamic({

    async loader() {

      //  动态加载组件

      const { default: Graph } = await import(`@/components/materies/${cpName}`)



      return (props: DynamicType) => {

        const { config， id } = props

        return <Graph {...config} id={id} />

      }

    },

    loading: () => <LoadingComponent />

  })

}



const DynamicRenderEngine: FC<DynamicType> = memo((props) => {

  const { 

  type, 

  config, 

  // 其他配置... 

  } = props

  const Dynamic = useMemo(() => {

    return DynamicFunc(config)

  }, [config])



  return <Dynamic {...props} />

})



export default DynamicRenderEngine

是不是很简单? 当然我们也可以根据自身业务需要， 设计更复杂强大的动态渲染器。

4.配置面板设计

实现配置面板的前提是对组件 Schema 结构有一个系统的设计， 在介绍组件库实现中我们介绍了通用组件 schema 的一个设计案例， 我们基于这样的案例结构， 来实现 动态配置面板。

由上图可以知道， 动态配置面板的一个核心要素就是 表单渲染器。表单渲染器的目的就是基于属性配置列表 attrs 来动态渲染出对应的表单项。我之前写了一篇文章详细的介绍了表单设计器的技术实现的文章， 大家感兴趣也可以参考一下: Dooring可视化之从零实现动态表单设计器。

我这里来简单实现一个基础的表单渲染器模型:

const FormEditor = (props: FormEditorProps) => {

  const { attrs, defaultValue, onSave } = props;



  const onFinish = (values: Store) => {

    // 保存配置项数据

    onSave && onSave(values);

  };

  

  const handlechange = (value) => {

    // 更新逻辑

  }



  const [form] = Form.useForm();



  return (

    <Form

      form={form}

      {...formItemLayout}

      onFinish={onFinish}

      initialValues={defaultValue}

      onValuesChange={handlechange}

    >

      {

        attrs.map((item, i) => {

        return (

          <React.Fragment key={i}>

            {item.type === 'Number' && (

              <Form.Item label={item.name} name={item.key}>

                <InputNumber />

              </Form.Item>

            )}

            {item.type === 'Text' && (

              <Form.Item label={item.name} name={item.key}>

                <Input placeholder={item.placeholder} />

              </Form.Item>

            )}

            {item.type === 'TextArea' && (

              <Form.Item label={item.name} name={item.key}>

                <TextArea rows={4} />

              </Form.Item>

            )}

            // 其他配置类型

          </React.Fragment>

        );

      })}

    </Form>

  );

};

如果大家想看更完整的配置面板实现， 可以参考开源项目 H5-Dooring | H5可视化编辑器

我们可以看看最终的配置面板实现效果:

5.控制中心概述 & 功能辅助设计

控制中心的实现主要是业务层的， 没有涉及太多复杂的技术， 所以这里我简单介绍一下。因为可视化大屏页面展示的信息有些可能是私密数据， 只希望一部分人看到， 所以我们需要对页面的访问进行控制。其次由于企业内部业务战略需求， 可能会对页面进行各种验证， 状态校验， 数据更新频率等， 所以我们需要设计一套控制中心来管理。最基本的就是访问控制， 如下:

功能辅助设计 主要是一些用户操作上的优化， 比如快捷键， 画布缩放， 大屏快捷导航， 撤销重做等操作， 这块可以根据具体的产品需求来完善。大家后期设计搭建产品时也可以参考实现。

可视化大屏数据自治探索

目前我们实现的搭建平台可以静态的设计数据源, 也可以注入第三方接口, 如下:

我们可以调用内部接口来实时获取数据, 这块在可视化监控平台用的场景比较多, 方式如下:

参数(params)编辑区可以自定义接口参数. 代码编辑器笔者这里推荐两款, 大家可以选用:

• react-monaco-editor


• react-codemirror2

使用以上之一可以实现mini版vscode, 大家也可以尝试一下.

辅助功能

可视化大屏一键截图 一键截图功能还是沿用H5-Dooring 的快捷截图方案, 主要用于对大屏的分享, 海报制作等需求, 我们可以使用以下任何一个组件实现:

• dom-to-image


• html2canvas

撤销重做撤销重做功能我们可以使用已有的库比如react-undo, 也可以自己实现, 实现原理:有点链表的意思, 我们将每一个状态存储到数组中, 通过指针来实现撤销重做的功能, 如果要想更健壮一点, 我们可以设计一套“状态淘汰机制”, 设置可保留的最大状态数, 之前的自动淘汰(删除, 更高大上一点的叫出栈). 这样可以避免复杂操作中的大量状态存储, 节约浏览器内存.

标尺参考线 标尺和参考线这里我们自己实现, 通过动态dom渲染来实现参考线在缩放后的动态收缩, 实现方案核心如下:

arr.forEach(el => {

  let dom = [...Array.from(el.querySelectorAll('.calibrationNumber'))][0] as HTMLElement;

  if (dom) {

    dom.style.transform = `translate3d(-4px, -8px, 0px) scale(${(multiple + 0.1).toFixed(

      1,

    )})`;

  }

});

详细源码可参考: H5-Dooring | 参考线设计源码

如果大家有好的建议也欢迎随时交流反馈, 开源不易, 别忘了star哦~

github地址: github.com/MrXujiang/v…

今年大部分时间都是在编码上和写文章上，但是也不知道自己都学到了啥，那就写篇文章来盘点一下目前的技术栈吧，也作为下一年的参考目标，方便知道每一年都学了些啥。

我的技术栈

首先我先来对整体的技术做一个简单的介绍吧，然后后面再对当前的一些技术进行细分吧。

React、Typescript、React Native、mysql、prisma、NestJs、Redis、前端工程化。

React

React 这个框架我花的时间应该是比较多的了，在校期间已经读了一遍源码了，对这些原理已经基本了解了。在随着技术的继续深入，今年毕业后又重新开始阅读了一遍源码，对之前的认知有了更深一步的了解。

也写了比较多跟 React 相关的文章，包括设计模式，原理，配套生态的使用等等都有一些涉及。

在状态管理方面，redux，zustand 我都用过，尤其在 Zustand 的使用上，我特别喜欢 Zustand，它使得我能够快速实现全局状态管理，同时避免了传统 Redux 中繁琐的样板代码，且性能更优。也对 Zustand 有比较深入的了解，也对其源码有过研究。

NextJs

Next.js 是一个基于 React 的现代 Web 开发框架，它为开发者提供了一系列强大的功能和工具，旨在优化应用的性能、提高开发效率，并简化部署流程。Next.js 支持多种渲染模式，包括服务器端渲染（SSR）、静态生成（SSG）和增量静态生成（ISR），使得开发者可以根据不同的需求选择合适的渲染方式，从而在提升页面加载速度的同时优化 SEO。

在路由管理方面，Next.js 采用了基于文件系统的路由机制，这意味着开发者只需通过创建文件和文件夹来自动生成页面路由，无需手动配置。这种约定优于配置的方式让路由管理变得直观且高效。此外，Next.js 提供了动态路由支持，使得开发者可以轻松实现复杂的 URL 结构和参数化路径。

Next.js 还内置了 API 路由，允许开发者在同一个项目中编写后端 API，而无需独立配置服务器。通过这种方式，前后端开发可以在同一个代码库中协作，大大简化了全栈开发流程。同时，Next.js 对 TypeScript 提供了原生支持，帮助开发者提高代码的可维护性和可靠性。

Typescript

今年所有的项目都是在用 ts 写了，真的要频繁修改的项目就知道用 ts 好处了，有时候用 js 写的函数修改了都不知道怎么回事，而用了 ts 之后，哪里引用到的都报红了，修改真的非常方便。

今年花了一点时间深入学习了一下 Ts 类型，对一些高级类型以及其实现原理也基本知道了，明年还是多花点时间在类型体操上，除了算法之外，感觉类型体操也可以算得上是前端程序员的内功心法了。

React Native

不得不说，React Native 不愧是接活神器啊，刚学完之后就来了个安卓和 ios 的私活，虽然没有谈成。

React Native 和 Expo 是构建跨平台移动应用的两大热门工具，它们都基于 React，但在功能、开发体验和配置方式上存在一些差异。React Native 是一个开放源代码的框架，允许开发者使用 JavaScript 和 React 来构建 iOS 和 Android 原生应用。Expo 则是一个构建在 React Native 之上的开发平台，它提供了一套工具和服务，旨在简化 React Native 开发过程。

React Native 的核心优势在于其高效的跨平台开发能力。通过使用 React 语法和组件，开发者能够一次编写应用的 UI 和逻辑，然后部署到 iOS 和 Android 平台。React Native 提供了对原生模块的访问，使开发者能够使用原生 API 来扩展应用的功能，确保性能和用户体验能够接近原生应用。

Expo 在此基础上进一步简化了开发流程。作为一个开发工具，Expo 提供了许多内置的 API 和组件，使得开发者无需在项目中进行繁琐的原生模块配置，就能够快速实现设备的硬件访问功能（如摄像头、位置、推送通知等）。Expo 还内置了一个开发客户端，使得开发者可以实时预览应用，无需每次都进行完整的构建和部署。

另外，Expo 提供了一个完全托管的构建服务，开发者只需将应用推送到 Expo 服务器，Expo 就会自动处理 iOS 和 Android 应用的构建和发布。这大大简化了应用的构建和发布流程，尤其适合不想处理复杂原生配置的开发者。

然而，React Native 和 Expo 也有各自的局限性。React Native 提供更大的灵活性和自由度，开发者可以更自由地集成原生代码或使用第三方原生库，但这也意味着需要更多的配置和维护。Expo 则封装了很多功能，简化了开发，但在需要使用某些特定原生功能时，开发者可能需要“弹出”Expo 的托管环境，进行额外的原生开发。

样式方案的话我使用的是 twrnc，大部分组件都是手撸，因为有 cursor 和 chatgpt 的加持，开发效果还是杠杠的。

rn 原理也争取明年能多花点时间去研究研究，不然对着盲盒开发还是不好玩。

Nestjs

NestJs 的话没啥好说的，之前也都写过很多篇文章了，感兴趣的可以直接观看：

• 面试官：为什么选择学习 Nestjs，而不是 Express？🧐🧐🧐


• NestJS 的生命周期钩子以及它们在不同阶段的都适合做什么？

对 Nodejs 的底层也有了比较深的理解了：

• 探究 CPU 密集型与 IO 密集型任务：提升对 Node.js 中 libuv 库的理解

Prisma & mysql

Prisma 是一个现代化的 ORM（对象关系映射）工具，旨在简化数据库操作并提高开发效率。它支持 MySQL 等关系型数据库，并为 Node.js 提供了类型安全的数据库客户端。在 NestJS 中使用 Prisma，可以让开发者轻松定义数据库模型，并通过自动生成的 Prisma Client 执行类型安全的查询操作。与 MySQL 配合时，Prisma 提供了一种简单、直观的方式来操作数据库，而无需手动编写复杂的 SQL 查询。

Prisma 的核心优势在于其强大的类型安全功能，所有的数据库操作都能通过 Prisma Client 提供的自动生成的类型来进行，这大大减少了代码中的错误，提升了开发的效率。它还包含数据库迁移工具 Prisma Migrate，能够帮助开发者方便地管理数据库结构的变化。此外，Prisma Client 的查询 API 具有很好的性能，能够高效地执行复杂的数据库查询，支持包括关系查询、聚合查询等高级功能。

与传统的 ORM 相比，Prisma 使得数据库交互更加简洁且高效，减少了配置和手动操作的复杂性，特别适合在 NestJS 项目中使用，能够与 NestJS 提供的依赖注入和模块化架构很好地结合，提升整体开发体验。

Redis

Redis 和 mysql 都仅仅是会用的阶段，目前都是直接在 NestJs 项目中使用，都是已经封装好了的，直接传参调用就好了：

import { Injectable, Inject, OnModuleDestroy, Logger } from "@nestjs/common";

import Redis, { ClientContext, Result } from "ioredis";



import { ObjectType } from "../types";



import { isObject } from "@/utils";



@Injectable()

export class RedisService implements OnModuleDestroy {

  private readonly logger = new Logger(RedisService.name);



  constructor(@Inject("REDIS_CLIENT") private readonly redisClient: Redis) {}



  onModuleDestroy(): void {

    this.redisClient.disconnect();

  }



  /**

   * @Description: 设置值到redis中

   * @param {string} key

   * @param {any} value

   * @return {*}

   */

  public async set(

    key: string,

    value: unknown,

    second?: number

  ): Promise<Result<"OK", ClientContext> | null> {

    try {

      const formattedValue = isObject(value)

        ? JSON.stringify(value)

        : String(value);



      if (!second) {

        return await this.redisClient.set(key, formattedValue);

      } else {

        return await this.redisClient.set(key, formattedValue, "EX", second);

      }

    } catch (error) {

      this.logger.error(`Error setting key ${key} in Redis`, error);



      return null;

    }

  }



  /**

   * @Description: 获取redis缓存中的值

   * @param key {String}

   */

  public async get(key: string): Promise<string | null> {

    try {

      const data = await this.redisClient.get(key);



      return data ? data : null;

    } catch (error) {

      this.logger.error(`Error getting key ${key} from Redis`, error);



      return null;

    }

  }



  /**

   * @Description: 设置自动 +1

   * @param {string} key

   * @return {*}

   */

  public async incr(

    key: string

  ): Promise<Result<number, ClientContext> | null> {

    try {

      return await this.redisClient.incr(key);

    } catch (error) {

      this.logger.error(`Error incrementing key ${key} in Redis`, error);



      return null;

    }

  }



  /**

   * @Description: 删除redis缓存数据

   * @param {string} key

   * @return {*}

   */

  public async del(key: string): Promise<Result<number, ClientContext> | null> {

    try {

      return await this.redisClient.del(key);

    } catch (error) {

      this.logger.error(`Error deleting key ${key} from Redis`, error);



      return null;

    }

  }



  /**

   * @Description: 设置hash结构

   * @param {string} key

   * @param {ObjectType} field

   * @return {*}

   */

  public async hset(

    key: string,

    field: ObjectType

  ): Promise<Result<number, ClientContext> | null> {

    try {

      return await this.redisClient.hset(key, field);

    } catch (error) {

      this.logger.error(`Error setting hash for key ${key} in Redis`, error);



      return null;

    }

  }



  /**

   * @Description: 获取单个hash值

   * @param {string} key

   * @param {string} field

   * @return {*}

   */

  public async hget(key: string, field: string): Promise<string | null> {

    try {

      return await this.redisClient.hget(key, field);

    } catch (error) {

      this.logger.error(

        `Error getting hash field ${field} from key ${key} in Redis`,

        error

      );



      return null;

    }

  }



  /**

   * @Description: 获取所有hash值

   * @param {string} key

   * @return {*}

   */

  public async hgetall(key: string): Promise<Record<string, string> | null> {

    try {

      return await this.redisClient.hgetall(key);

    } catch (error) {

      this.logger.error(

        `Error getting all hash fields from key ${key} in Redis`,

        error

      );



      return null;

    }

  }



  /**

   * @Description: 清空redis缓存

   * @return {*}

   */

  public async flushall(): Promise<Result<"OK", ClientContext> | null> {

    try {

      return await this.redisClient.flushall();

    } catch (error) {

      this.logger.error("Error flushing all Redis data", error);



      return null;

    }

  }



  /**

   * @Description: 保存离线通知

   * @param {string} userId

   * @param {any} notification

   */

  public async saveOfflineNotification(

    userId: string,

    notification: any

  ): Promise<void> {

    try {

      await this.redisClient.lpush(

        `offline_notifications:${userId}`,

        JSON.stringify(notification)

      );

    } catch (error) {

      this.logger.error(

        `Error saving offline notification for user ${userId}`,

        error

      );

    }

  }



  /**

   * @Description: 获取离线通知

   * @param {string} userId

   * @return {*}

   */

  public async getOfflineNotifications(userId: string): Promise<any[]> {

    try {

      const notifications = await this.redisClient.lrange(

        `offline_notifications:${userId}`,

        0,

        -1

      );

      await this.redisClient.del(`offline_notifications:${userId}`);



      return notifications.map((notification) => JSON.parse(notification));

    } catch (error) {

      this.logger.error(

        `Error getting offline notifications for user ${userId}`,

        error

      );



      return [];

    }

  }



  /**

   * 获取指定 key 的剩余生存时间

   * @param key Redis key

   * @returns 剩余生存时间（秒）

   */

  public async getTTL(key: string): Promise<number> {

    return await this.redisClient.ttl(key);

  }

}

前端工程化

前端工程化这块花了很多信息在 eslint、prettier、husky、commitlint、github action 上，现在很多项目都是直接复制之前写好的过来就直接用。

后续应该是投入更多的时间在性能优化、埋点、自动化部署上了，如果有机会的也去研究一下 k8s 了。

全栈性价比最高的一套技术

最近刷到一个帖子，讲到了

我目前也算是一个小全栈了吧，我也来分享一下我的技术吧：

剩下的描述也是和他下面那句话一样了（毕业后对技术态度的转变就是什么能让我投入最小，让我最快赚到钱的就是好技术）

总结

学无止境，任重道远。

最后再来提一下这两个开源项目，它们都是我们目前正在维护的开源项目：

• 在线代码协同编辑器


• 前端脚手架 create-neat

如果你想参与进来开发或者想进群学习，可以添加我微信 yunmz777，后面还会有很多需求，等这个项目完成之后还会有很多新的并且很有趣的开源项目等着你。

前言

2024/12/27更新：实体证书也出来啦，如下：

2024/12/20更新：电子证书出来啦，如下：

算上这次，我其实已经参加了三次考试，先贴上这三次的成绩，相信大家也能感受到我的心情：

虽然这次总算通过了考试，但看到综合知识的成绩还是心有余悸，由于前两次考试的打击（都是差一门案例没有通过，上半年只差了两分)，这次考试前只写了两套半的综合知识真题和在考前一天准备了大半天（背论文模板和知识点集锦的 pdf)，而综合知识也是自己信心最足的一门，结果这次压线通过，所以还是建议大家只要报名了考试，还是要认真准备，至少把往年综合知识的真题刷一刷，避免最后发现只有综合知识未通过而追悔莫及。

我也在Github上分享了几个我备考用到的文档资料，大家自行取用。

PS：这次考试通过还要感谢我女友的祝福，我们在今年5.23相识（上半年考试前两天，然后考试也是差两分），再加上这次的压线通过，感受到了冥冥之中自有天意(❁´◡`❁)。

考试注意点

从去年下半年开始，软考统一由笔试改为机考，虽然不用再担心写字速度太慢或者不美观导致论文扣分，但要注意的是键盘只能使用考场提供的，因此很多人可能不太习惯。就我这几次的考试经验来说，两个小时写论文还是比较紧凑的，剩余时间都不超过10分钟，还要用这点时间去通读检查一遍论文有没有什么错别字，因此在考前准备一个论文模板还是十分必要的，这样就可以在写模板内容的同时去构思正文，对于时间充分的小伙伴来说，也可以计时去练习写几篇论文。另外需要注意从2024年开始，系统架构师改为一年两考（不通过也可以趁热打铁立刻准备下一次的考试了），上午考综合知识和案例(总共四小时，分别两小时，综合知识写完可提前半小时交卷去写案例)，下午考论文（两个小时），考试时间安排如下：

备考经历

第一次（2 ~ 3个月）：看完某赛视频全集（无大数据相关）+ 某赛知识点集锦 + 写完历年综合知识真题 + 案例论文对着答案看一遍（写了几道质量属性和数据库相关的案例题）+ 准备并背诵一个论文模板。

第二次（0.5 ~ 1个月）：这次将上次的看视频改为了看教材（把考试重点的几个章节内容都混了个眼熟），然后其他准备都差不多，只是准备时间有相应减少。

第三次（1 ~ 2天）：两套半综合知识真题 + 大致浏览一遍知识点集锦 + 背诵论文模板。

备考主要有以下注意点：

备考方式

综合知识

就我的经验来讲，我觉得综合知识是最可控的部分，只需将视频课 + 重要知识点集锦 + 历年综合知识真题过一遍，综合知识是完全不需要担心的。还有就是遇到考纲之外的真题，比如今年有一道题是：一项外观设计专利里面相似设计最多有几个，像这种基本无再考可能的题，只需要看到答案后混个眼熟就可以。除此之外还有一部分反复考的知识点：构件、4 + 1视图、ABSD、DSSA、架构评估（质量属性）、系统架构风格、项目时间和成本计算以及软件测试，这些内容需要格外留意，有时间的话，可以把教材上相关知识的内容过一遍。除此之外，一定要记得考试时相信自己的第一感觉，不确定的题目不要修改答案。

案例分析

案例分析的题型变化比较大，更考验平时的技术积累，不过第一道必选题近几年都是和质量属性相关（除了23年下半年是大数据），然后就是 Redis 的考频也比较高，近三次考试有两次涉及（以往也有涉及），在24年上半年甚至精确到了命令的考察。此外，近几次案例也都考到了关于技术架构图的填空题，所以建议练习一下往年的相关题型，再到 ProcessOn 之类的平台找几个技术架构图看看。

案例考察的范围比较广，因此建议在高频考点上多加复习和准备。然后遇到不熟悉的知识点也不要慌，更不要空着不写，可以分点试着写一些或者硬凑一些相关的内容，能得一分是一分。如果时间充足，还是建议把往年的案例真题按照时间由近到远认真看一看，即使是一些视频中说的考试概率很低的知识点（Hibernate和设计模式）在前两次的考试和论文中也都有涉及，尤其是项目和技术经验不是那么丰富的小伙伴（比如我自己）需要注意这点。

论文

虽然看到很多小伙伴都说论文难写还会卡分，但因为我三次考试也都只有案例未过，论文虽然分数不高，但也都过了合格线，这里也分享一下我的写作经验。

我觉得写论文只需要记住真实项目 + 技术点讨论 + 论点点题并结合项目分析 + 项目中遇到的问题点这几点即可，即使内容有点流水账也无伤大雅，最重要的是写的让项目看起来真实，是自己做的，除了摘要和开头结尾可以找模板进行参考，正文部分还是需要自己结合论点去写，不能全是理论而没有一点技术点（使用到的各种工具和服务也都可以说，例如代码评审使用和项目管理相关的）的讨论。就以我这次的论文结构为例，首先是摘要部分（250字以内）：

​ 2022年12月，我所在公司承接了某区xxx的开发项目。我在该项目中担任系统架构设计师的职务，负责需求分析和系统的架构设计等工作。该项目主要提供xxx、xxx和xxx功能。本文将结合作者的实践，以xxx项目为例，论述xxx在系统开发中的具体应用。在xxx模块使用了xxx，解决了xxx问题。在xxx模块使用了xxx，解决了xxx问题。在xxx模块使用了xxx，解决了xxx问题。实践证明，采用xxx，提升了软件的开发效率和质量。整个项目历时一年多，于今年6月正式上线运行，整个系统运行稳定，达到了预期的目标的要求。

然后是开头和结尾（800字左右）：

​ ......。（项目背景，150字左右）

​ 正是在这一背景下，2022年12月，我们公司承接了xxx项目，在本项目中，我担任系统架构师的职务，负责需求分析和系统的架构设计等工作。经过对项目的调研和对用户需求的分析，我们确认了系统应当具有以下功能：xxx，xxx，xxx。基于以上的需求，我们采用xxx解决了xxx问题。（300字左右，这部分介绍功能的部分可以和摘要内容有重合）

​ 经过团队的共同努力，本项目按时交付，于今年6月顺利交付并上线，到目前运行稳定，不管是xxx使用xxx，还是xxx使用xxx都反馈良好。但在实施的过程中也遇到了一些问题，xxx。而如何让xxx更xxx是一项长期的工作，还有很多问题需要在实践中不断探索，在理论中深入研究并加以解决。只有这样，xxx才能不断地优化和发展，xxx。（350字左右）

最后是正文，由于我写的是软件维护（具体包含完善性维护、预防性维护、改正性维护、适应性维护），所以我首先用200 ~ 300字描述了这四种维护的具体含义（可以用自己的语言去描述，不需要和书上完全一致）。然后针对每种维护，再分四段用250 ~ 300字去结合项目和技术点具体去讨论我在每种维护中所做的工作。

当然上面只是我的一些论文写作经验，至少最近三次都是按照这个模板和套路去写，也都通过了。不过大家还是要结合自己的项目去做一些修改，建议多找几个论文综合一下，然后结合自己的语言去写一个属于自己的模板( •̀ ω •́ )✧。

感想

经过这三次的备考和考试经历，我觉得除了一些实力外，运气也占了一部分。就像这次的案例考了我熟悉的也简单的质量属性和 Cache Aside 缓存策略，前两次都有涉及到大数据这个我不熟悉的相关知识，也是我挂在案例的原因之一，所以大家如果考试遇到不熟悉的题或者分数还差一点，不妨再试一两次，相信自己可以的(●'◡'●)。如果大家有什么问题，也可以留言交流讨论。

在涉及到支付的业务时，通常需要实现一个功能:如果用户在生成订单的一定时间内未完成支付，系统将自动取消订单。本文将基于Spring Boot框架实现订单30分钟内未支付自动取消的几种方案，并提供实例代码。

方案一：定时任务

利用@Scheduled注解，我们可以轻松实现定时任务，周期性扫描订单记录，检查未支付的订单，如果有满足三十分钟则进行关闭。

@Component

public class OrderSchedule {

    @Autowired

    private OrderService orderService;



    @Scheduled(cron = "0 0/1 * * * ?")

    public void cancelUnpaidOrders() {

        LocalDateTime now = LocalDateTime.now();

        List<Integer> idList = new ArrayList<Integer>();

        List<OrderEntity> orderList = orderService.getOrderList();

        orderList.forEach(order -> {

            if (order.getWhenCreated().plusMinutes(30).isBefore(now)) {

                idList.add(order.getId());

          }

        });

        orderService.cancelOrderList(idList);

        }

}

方案二：延迟队列

使用消息队列的延迟队列，当订单生成时将订单ID推送到延迟队列，设置30分钟后过期，过期后消费该消息，判断订单状态，如果未支付则取消订单。

@Service

public class OrderService {



    @Autowired

    private RabbitTemplate rabbitTemplate;



    public void createOrder(Order order) {

        // 保存数据库

        saveOrder(order);



        // 将订单ID推送至延迟队列

        rabbitTemplate.convertAndSend("orderDelayExchange", "orderDelayKey", order.getId(), message -> {

            message.getMessageProperties().setDelay(30 * 60 * 1000); // 设置延迟时间

            return message;

        });

    }

}



@Component

public class OrderDelayConsumer {



    @Autowired

    private OrderService orderService;



    @RabbitHandler

    @RabbitListener(queues = "orderDelayQueue")

    public void cancelOrder(String orderId) {

        // 取消订单

        orderService.cancelOrder(orderId);

    }

}

方案三：redis过期事件

使用redis的key过期事件，当订单创建时在Redis中存储一个key，设置30分钟过期，key过期时通过redis的过期事件通知功能触发订单取消。

@Service

public class OrderService {



    @Autowired

    private StringRedisTemplate redisTemplate;



    public void createOrder(Order order) {

        // 保存订单至数据库

        saveOrder(order);



        // 在redis中存储一个key，设置30分钟过期

        redisTemplate.opsForValue().set("order:" + order.getId(), order.getId(), 30, TimeUnit.MINUTES);

    }



    // 当key过期时，redis会自动调用该方法（需要配置redis的过期事件通知）

    public void onOrderKeyExpired(String orderId) {

        cancelOrder(orderId);

    }

}

注：redis的key过期通知是一种典型的发布-订阅模式。在redis中，我们可以订阅到某些特定的事件。key过期事件就是其中之一。但想要使用这个功能，需要redis服务器开启相关配置。具体如何配置会在后期的文章里分享给大家。

最后总结：

三种方案都可以实现订单在30分钟内未支付则自动取消的需求。根据实际业务需求、系统负载和其他因素，可以选择最适合自己系统的实现方案。每种方案都有其优缺点，需要根据具体情况权衡。

你好呀，我是歪歪。

踩坑了啊，最近踩了一个 lombok 的坑，有点意思，给你分享一波。

我之前写过一个公共的服务接口，这个接口已经有好几个系统对接并稳定运行了很长一段时间了，长到这个接口都已经交接给别的同事一年多了。

因为是基础服务嘛，相对稳定，所以交出去之后他也一直没有动过这部分代码。

但是有一天有新服务要对接这个接口，同事反馈说遇到一个诡异的问题，这个新服务调用的时候，接口里面报了一个空指针异常。

根据日志来看，那一行代码大概是这样的：

//为了脱敏我用field1、2、3来代替了

if(reqDto.getField1() 

    && reqDto.getField2()!=null

    && reqDto.getField3()!=null){

        //满足条件则执行对应业务逻辑

    }

reqDto 是接口入参对象，有好多字段。具体到 field1、2、3 大概是这样的：

@Data

@Builder

@NoArgsConstructor

@AllArgsConstructor

public class ReqDto { 

    private Boolean field1 = true;

    private String field2;

    private String field3;

}

所以看到这一行抛出了空指针异常，我直接就给出了一个结论：首先排除 field1 为 null，因为有默认值。那只可能 reqDto 传进来的就是 null，导致在 get 字段的时候出现了空指针异常。

但是很不幸，这个结论一秒就被推翻了。

因为 reqDto 是请求入参，在方法入口处选了几个关键字段进行打印。

如果 reqDto 是 null 的话，那么日志打印的时候就会先抛出空指针异常了。

然后我又开始怀疑是部署的代码版本和我们看的版本不一致，可能并不是这一行报错。

和测试同学确认之后，也排除了这个方向。

盯着报错的那一行代码又看了几秒，排除所有不可能之后，我又下了一个结论：调用的时候，传递进来的 field1 主动设值为了 null。

也就是说调用方有这样的代码：

ReqDto reqDto = new ReqDto();

reqDto.setField1(null);

我知道，这样的代码看起来很傻，但是确实只剩下这一种可能了。

于是我去看了调用方构建参数的写法，准备吐槽一波为什么要写设置为 null 这样的坑爹代码。

然而，当时我就被打脸了，调用方的代码是这样的：

ReqDto reqDto = ReqDto.builder()

        .field2("why")

        .field3("max")

        .build();

用的是 builder 模式构建的对象，并不是直接 new 出来的对象。

我一眼看着这个代码也没有发现毛病，虽然没有对 Boolean 类型的 field1 进行设值，但是我有默认值啊。

问调用方为什么不设值，对方的回答也是一句话：我看你有默认值，我本来也是想传 true，但是一看你的默认值就是 true，所以就没有给值了。

对啊，这逻辑无懈可击啊，难道......

是 builder 在里面搞事情了？

于是我里面写了一个代码进行了验证：

好你个浓眉大眼的 @Builder，果然是你在搞事情。

问题现象基本上就算是定位到了，用 @Builder 注解的时候，丢失默认值了。

所以拿着 “@Builder 默认值” 这样的关键词一搜：

立马就能找到这样的一个注解：@Builder.Default

对应到我的案例应该是这样的：

@Data

@Builder

@NoArgsConstructor

@AllArgsConstructor

public class ReqDto { 

    @Builder.Default

    private Boolean field1 = true;

    private String field2;

    private String field3;

}

这样，再次运行 Demo 就会发现有默认值了：

同时我们从两个写法生成的 class 文件中也可以看出一些端倪。

没有@Builder.Default 注解的时候，class 文件中 ReqDtoBuilder 类中关于 field1 字段是这样的：

但是有 @Builder.Default 注解的时候，是这样的：

明显是不同的处理方式。

反正，网上一搜索，加上 @Builder.Default 注解，问题就算是解决了。

但是紧接着我想到了另外一个问题：为什么？

为什么我明明给了默认值，@Builder 不使用，非得给再显示的标记一下呢？

于是我带着这个问题在网上冲了一大圈，不说没有找到权威的回答了，甚至没有找到来自“民间”的回答。

所以我也只能个人猜测一下，我觉得可能是 Lombok 觉得这样的赋默认值的写法是 Java 语言的规范：

private Boolean field1 = true;

规范我 Lombok 肯定遵守，但是我怎么知道你这个字段有没有默认值呢？

我肯定是有手段去检查的，但是我必须要每个字段都盲目的去瞅一眼，这个方案对我不友好啊。

这样，我给使用者定一个规范：你给我打个标，主动告诉我那些字段是有默认值的。对于打了标的字段，我才去解析对应的默认值，否则我就不管了。

如果你直接 new 对象，那是 Java 的规范，我管不了。

但是如果你使用 Builder 模式，你就得遵守我的规范。不然出了问题也别赖我，谁叫你不准守我的规范。

打个标，就是 @Builder.Default。

必须要强调的是，这个观点是歪师傅纯粹的个人想法，不保真。如果你有其他的看法也可以提出来一起交流，学习一波。

吃个瓜

虽然我没有找到关于 @Builder.Default 注解存在的意义的官方说明，但是我在 github 上找到了这个一个链接：

github.com/projectlomb…

里面的讨论的问题和我们这个注解有点关系，而且我认为这是一个非常明确的 bug，但是官方却当做 feature 给处理了。

简单的一起吃个瓜。

2017 年 3 月 29 日的时候，一个老哥抛出了一个问题。

首先我们看一下提出问题的老哥给的代码：

就上面这个代码，如果我们这样去创建对象：

MyClass myClass = new MyClass();

按照 Java 规范来说，我们附了默认值的，调用 myClass.getEntitlements() 方法返回的肯定是一个空集合嘛。

但是，这个老哥说当 new MyClass 对象的时候，这个字段变成了 null：

他就觉得很奇怪，于是抛出了这个问题。

然后另外有人立马补充了一下。说不仅是 list/set/map，任何其他 non-primitive 类型都会出现这个问题：

啥意思呢，拿我们前面的案例来说就是，你用 1.16.16 这个版本，不加 @Builder.Default 注解，运行结果是符合预期的：

但是加上 @Builder.Default 注解，运行结果会变成这样：

build 倒是正确了，但是 new 对象的时候，你把默认值直接给干没了。

看到这个运行结果的第一个感觉是很奇怪，第二个感觉是这肯定是 lombok 的 BUG。

问题抛出来之后，紧接着就有老哥来讨论了：

这个哥们直接喊话官方：造孽啊，这么大个 BUG 还有没有人管啦？

同时他还抛出了一个观点：老实说，为字段生成默认值的最直观方法就是从字段初始化中获取值，而不是需要额外的 Builder.Default 注解来标记。

这个观点，和我前面的想法倒是不谋而合。但是还是那句话：一切解释权归官方所有，你要用，就得遵守我制定的规范。

那么到底是改了啥导致产生了这么一个奇怪的 BUG 呢？

注意 omega09 这个老哥的发言的后半句：field it will be initialized twice.

initialized twice，初始化两次，哪来的两次？

我们把目光放到这里来：

@NoArgsConstructor，这是个啥东西？

这不就是让 lombok 给我们搞一个无参构造函数吗？

搞无参构造函数的时候，不是得针对有默认值的字段，进行一波默认值的初始化吗？

这个算一次了。

前面我们分析了 @Builder.Default 也要对有默认值的字段初始化一次。

所以是 twice，而且这两次干得都是同一个活。

开发者一看，这不行啊，得优化啊。

于是把 @NoArgsConstructor 的初始化延迟到了 @Builder.Default 里面去，让两次合并为一次了。

这样一看，用 Builder 模式的时候确实没问题了，但是用 new 的时候，默认值就没了。

这是一种经典的顾头不顾尾的解决问题的方式。

作者可能也没想到，大家在使用的时候会把 @Builder 和 @NoArgsConstructor 两个注解放在一起用。

作者可能还觉得委屈呢：这明明就是两种不同的对象构建方式啊，二选一就行了，你要放在一起？哎哟，你干嘛~

接着一个叫做 davidje13 的老哥接过了话茬，顺着 omega09 老哥的话往下说，他除了解释两个注解放在一起使用的场景外，还提到了一个词：least-surprise。

least-surprise，是一个软件设计方面的词汇，翻译过来就是最小惊吓原则。

简单来说就是我们的程序所表现出的行为，应该尽量满足在其领域内具有一致性、显而易见、可预测、遵循惯例。

比如我们认为的惯例是 new 对象的时候，如果有默认值会附上默认值。

结果你这个就搞没了，就不遵循惯例了。

当然，你还是可以拿出那句万金油的话：一切解释权归官方所有，你要用，就得遵守我制定的规范。我的规范就是不让你们混用。

这就是纯纯的耍无赖了，相当于是做了一个违背祖宗的决定。

然而这个问题似乎并没有官方人员参与讨论，直到这个时候，2018 年 3 月 27 日：

rspiller 就是官方人员，他说：我们正在调查此事。

此时，距离这个问题提出的时间已经过去了一年。

我是比较吃惊的，因为我认为这是一个比较严重的 BUG 了，程序员在使用的时候会遇到一些就类似于我认为这个字段一定是有默认值的，但是实际上却变成了 null 这种莫名其妙的问题。

在官方人员介入之后，这个问题再次活跃起来。

一位 xak2000 老哥也发表了自己的看法，并艾特了官方人员：

他的观点我是非常认同的，给你翻译一波。

他说，导致这个问题的原因是为了消除可能出现的重复初始化。但实际上，与修改 POJO 字段的默认初始化这种完全出乎意料的行为相比，重复初始化的问题要小得多。

当然，解决这个问题的最佳方法是以某种方式摆脱双重初始化，同时又不破坏字段初始化器。

但如果这不可能，或者太难，或者时间太长，那么，就让重复初始化发生吧！

然后把“重复初始化”写到 @Builder.Default javadocs 中，大不了再给这几个字加个粗。

如果有人确实写了一些字段初始化比较复杂的程序，这可能会导致一些问题，但比起该初始化却没有初始化带来的问题要少得多。

在当前的这个情况下，当突然抛出一个空指针异常的时候，我真的很蒙蔽啊。

当然了，也有人提出了不一样的看法：

这个哥们的核心思路刚刚相反，就是呼吁大家不要把 @Builder 和 @NoArgsConstructor 混着用。

从“点赞数”你也能看出来，大家都不喜欢这个方案。

而这个 BUG 是在 2018 年 7 月 26 日，1.18.2 版本中才最终解决的：

projectlombok.org/changelog

此时，距离这个问题提出，已经过去了一年又四个月。

值得注意的是，在官方的描述里面，用的是 FEATURE 而不是 BUGFIX。

个中差异，你可以自己去品一品。

但是现在 Lombok 都已经发展到 1.18.32 版本了，1.16.x 版本应该没有人会去使用了。

所以，大家大概率是不会踩到这个坑的。

我觉得这个事情，了解“坑”具体是啥不重要，而是稍微走进一下开源项目维护者的内心世界。

开源不易，有时候真的就挺崩溃的。

编译时注解

既然聊到 Lombok 了，顺便也简单聊聊它的工作原理。

Lombok 的核心工作原理就是编译时注解，这个你知道吧？

不知道其实也很正常，因为我们写业务代码的时候很少自定义编译时注解，顶天了搞个运行时注解就差不多了。

其实我了解的也不算深入，只是大概知道它的工作原理是什么样的，对于源码没有深入研究。

但是我可以给你分享一下两个需要注意的地方和可以去哪里了解这个玩意。

以 Lombok 的日志相关的注解为例。

首先第一个需要注意的地方是这里：

log 相关注解的源码位于这个部分，可以看到很奇怪啊，这些文件是以 SCL.lombok 结尾的，这是什么玩意？

这是 lombok 的小心思，其实这些都是 class 文件，但是为了避免污染用户项目，它做了特殊处理。

所以你打开这类文件的时候选择以 class 文件的形式打开就行了，就可以看到里面的具体内容。

比如你可以看看这个文件：

lombok.core.handlers.LoggingFramework

你会发现你们就像是枚举似的，写了很多日志的实现：

这个里面把每个注解需要生成的 log 都硬编码好了。正是因为这样，Lombok 才知道你用什么日志注解，应该给你生成什么样的 log。

比如 log4j 是这样的：

private static final org.apache.logging.log4j.Logger log = org.apache.logging.log4j.LogManager.getLogger(TargetType.class);

而 SLF4J 是这样的：

private static final org.slf4j.Logger log = org.slf4j.LoggerFactory.getLogger(TargetType.class);

第二个需要注意的地方是找到入口:

这些 class 文件加载的入口在于这个地方，是基于 Java 的 SPI 机制：

AnnotationProcessorHider 这个类里面有两行静态内部类，我们看其中一个， AnnotationProcessor ，它是继承自 AbstractProcessor 抽象类：

javax.annotation.processing.AbstractProcessor

这个抽象类，就是入口中的入口，核心中的核心。

在这个入口里面，初始化了一个类加载器，叫做 ShadowClassLoader：

它干的事儿就是加载那些被标记为 SCL.lombok 的 class 文件。

然后我是怎么知道 Lombok 是基于编译时注解的呢？

其实这玩意在我看过的两本书里面都有写，有点模糊的印象，写文章的时候我又翻出来读了一遍。

首先是《深入理解 Java 虚拟机(第三版)》的第四部分程序编译与代码优化的第 10 章：前端编译与优化一节。

里面专门有一小节，说插入式注解的：

Lombok 的主要工作地盘，就在 javac 编译的过程中。

在书中的 361 页，提到了编译过程的几个阶段。

从 Java 代码的总体结构来看，编译过程大致可以分为一个准备过程和三个处理过程：

• 1.准备过程：初始化插入式注解处理器。


• 2.解析与填充符号表过程，包括：
  
  
  
  
  • 词法、语法分析。将源代码的字符流转变为标记集合，构造出抽象语法树。
  
  
  • 填充符号表。产生符号地址和符号信息。
  
  
  
  


• 3.插入式注解处理器的注解处理过程：插入式注解处理器的执行阶段，本章的实战部分会设计一个插入式注解处理器来影响Javac的编译行为。


• 4.分析与字节码生成过程，包括：
  
  
  
  
  • 标注检查。对语法的静态信息进行检查。
  
  
  • 数据流及控制流分析。对程序动态运行过程进行检查。
  
  
  • 解语法糖。将简化代码编写的语法糖还原为原有的形式。（java中的语法糖包括泛型、变长参数、自动装拆箱、遍历循环foreach等，JVM运行时并不支持这些语法，所以在编译阶段需要还原。）
  
  
  • 字节码生成。将前面各个步骤所生成的信息转换成字节码。
  
  
  
  

如果说 javac 编译的过程就是 Lombok 的工作地盘，那么其中的“插入式注解处理器的注解处理过程”就是它的工位了。

书中也提到了 Lombok 的工作原理：

第二本书是《深入理解 JVM 字节码》，在它的第 8 章，也详细的描述了插件化注解的处理原理，其中也提到了 Lombok：

最后画了一个示意图，是这样的：

如果你看懂了书中的前面的十几页的描述，那么看这个图就会比较清晰了。

总之，Lombok 的核心原理就是在编译期对于 class 文件的魔改，帮你生成了很多代码。

如果你有兴趣深入了解它的原理的话，可以去看看我前面提到的这两本书，里面都有手把手的实践开发。

我就不写了，一个原因是因为确实门槛较高，写出来生涩难懂，对我们日常业务开发帮助也不大。

另外一个原因那不是因为我懒嘛。

荒腔走板

周末去了一趟都江堰。

问道青城山，拜水都江堰。读大学的时候就知道这句话了，所以从大学算起，都江堰景区去过的次数，没有十次也有七八次了。

之前每次去就是觉得：哇，好大的山；哇，好急的水；哇，这个一点也不像鱼嘴的地方为什么叫鱼嘴；哇，这个鱼嘴看介绍很牛逼，但是我感觉我上我也行的样子。

这次去的时候，我和 Max 同学算是自己做了一次攻略，看了相关的介绍视频，比较系统的了解了一下鱼嘴、飞沙堰、宝瓶口的作用。

如果你也有兴趣的话，推荐看看 B 站“星球研究所”有一期将都江堰的视频，简短且直观，很不错。

看视频的时候才知道原来这里面有这么多门道，并惊叹于古人的智慧和劳动能力。顺应自然规律，因时制宜，建造了都江堰水利工程，并一直沿用了约 2300 年。

当我们真的走进景区，看到鱼嘴、飞沙堰、宝瓶口就在眼前的时候，才真正明白了视频里面说的“四六分水、二八排沙”是怎么回事，“深淘摊，低作堰”又是怎么回事。

水旱从人，不知饥谨，时无荒年，天下谓之天府也。

成都不能没有都江堰。

李冰父子，配享太庙。

为什么很多人不推荐你用JWT?

如果你经常看一些网上的带你做项目的教程，你就会发现 有很多的项目都用到了JWT。那么他到底安全吗？为什么那么多人不推荐你去使用。这个文章将会从全方面的带你了解JWT 以及他的优缺点。

什么是JWT?

这个是他的官网JSON Web Tokens - jwt.io

这个就是JWT

JWT 全称JSON Web Token

如果你还不熟悉JWT，不要惊慌！它们并不那么复杂！

你可以把JWT想象成一些JSON数据，你可以验证这些数据是来自你认识的人。

当然如何实现我们在这里不讲，有兴趣的可以去自己了解。

下面我们来说一下他的流程：

为什么说JWT很烂？

首先我们用JWT应该就是去做这些事情：

• 用户注册网站


• 用户登录网站


• 用户点击并执行操作


• 本网站使用用户信息进行创建、更新和删除 信息

这些事情对于数据库的操作经常是这些方面的

• 记录用户正在执行的操作


• 将用户的一些数据添加到数据库中


• 检查用户的权限，看看他们是否可以执行某些操作

之后我们来逐步说出他的一些缺点

大小

这个方面毋庸置疑。

比如我们需要存储一个用户ID 为xiaou

如果存储到cookie里面，我们的总大小只有5个字节。

如果我们将 ID 存储在 一个 JWT 里。他的大小就会增加大概51倍

这无疑就增大了我们的宽带负担。

冗余签名

JWT的主要卖点之一就是其加密签名。因为JWT被加密签名，接收方可以验证JWT是否有效且可信。

但是，在过去20年里几乎每一个网络框架都可以在使用普通的会话cookie时获得加密签名的好处。

事实上，大多数网络框架会自动为你加密签名（甚至加密！）你的cookie。这意味着你可以获得与使用JWT签名相同的好处，而无需使用JWT本身。

实际上，在大多数网络身份验证情况下，JWT数据都是存储在会话cookie中的，这意味着现在有两个级别的签名。一个在cookie本身上，一个在JWT上。

令牌撤销问题

由于令牌在到期之前一直有效，服务器没有简单的方法来撤销它。

以下是一些可能导致这种情况危险的用例。

注销并不能真正使你注销！

想象一下你在推特上发送推文后注销了登录。你可能会认为自己已经从服务器注销了，但事实并非如此。因为JWT是自包含的，将在到期之前一直有效。这可能是5分钟、30分钟或任何作为令牌一部分设置的持续时间。因此，如果有人在此期间获取了该令牌，他们可以继续访问直到它过期。

可能存在陈旧数据

想象一下用户是管理员，被降级为权限较低的普通用户。同样，这不会立即生效，用户将继续保持管理员身份，直到令牌过期。

JWT通常不加密

因此任何能够执行中间人攻击并嗅探JWT的人都拥有你的身份验证凭据。这变得更容易，因为中间人攻击只需要在服务器和客户端之间的连接上完成

安全问题

对于JWT是否安全。我们可以参考这个文章

JWT （JSON Web Token） （in）security - research.securitum.com

同时我们也可以看到是有专门的如何攻击JWT的教程的

高级漏洞篇之JWT攻击专题 - FreeBuf网络安全行业门户

总结

总的来说，JWT适合作为单次授权令牌，用于在两个实体之间传输声明信息。

但是，JWT不适合作为长期持久数据的存储机制，特别是用于管理用户会话。使用JWT作为会话机制可能会引入一系列严重的安全和实现上的问题，相反，对于长期持久数据的存储，更适合使用传统的会话机制，如会话cookie，以及建立在其上的成熟的实现。

但是写了这么多，我还是想说，如果你作为自己开发学习使用，不考虑安全，不考虑性能的情况下，用JWT是完全没有问题的，但是一旦用到生产环境中，我们就需要避免这些可能存在的问题。

首发公众号:【赵侠客】

引言

我相信作为一名java开发者你一定听过或者看过类似《你还在用for循环遍历List吗？》、《JDK8都10岁了，你还在用for循环遍历List吗？》这类鄙视在Java中使用for循环遍历List的水文。这类文章说的其实就是使用Java8中的Stream.foreach()来遍历元素，在技术圈感觉使用新的技术就高大上，开发者们也都默许接受新技术的很多缺点，而使用老的技术或者传统的方法就会被人鄙视，被人觉得Low，那么使用forEach()真的很高大上吗？它真的比传统的for循环好用吗？本文就列出10大推荐使用for而不是forEach()的理由。

理由一、for性能更好

在我的固有认知中我是觉得for的循环性能比Stream.forEach()要好的，因为在技术界有一条真理：

越简单越原始的代码往往性能也越好

而且搜索一些文章或者大模型都是这么觉得的，可时我并没有找到专业的基准测试证明此结论。那么实际测试情况是不是这样的呢？虽然这个循环的性能差距对我们的系统性能基本上没有影响，不过为了证明for的循环性能真的比Stream.forEach()好我使用基准测试用专业的实际数据来说话。我的测试代码非常的简单，就对一个List<Integer> ids分别使用for和Stream.forEach()遍历出所有的元素，以下是测试代码：

@State(Scope.Thread)

public class ForBenchmark {

    private List<Integer> ids ;

    @Setup

    public void setup() {

        ids = new ArrayList<>();

        //分别对10、100、1000、1万、10万个元素测试

        IntStream.range(0, 10).forEach(i -> ids.add(i));

    }

    @TearDown

    public void tearDown() {

        ids = new ArrayList<>();

    }

    @Benchmark

    public void testFor() {

        for (int i = 0; i <ids.size() ; i++) {

            Integer id = ids.get(i);

        }

    }



    @Benchmark

    public void testStreamforEach() {

        ids.stream().forEach(x->{

            Integer id=x;

        });

    }



    @Test

    public void testMyBenchmark() throws Exception {

        Options options = new OptionsBuilder()

                .include(ForBenchmark.class.getSimpleName())

                .forks(1)

                .threads(1)

                .warmupIterations(1)

                .measurementIterations(1)

                .mode(Mode.Throughput)

                .build();

        new Runner(options).run();

    }

}

我使用ArrayList分对10、100、1000、1万，10万个元素进行测试，以下是使用JMH基准测试的结果，结果中的数字为吞吐量，单位为ops/s，即每秒钟执行方法的次数：

从使用Benchmark基准测试结果来看使用for遍历List比Stream.forEach性能在元素越小的情况下优势越明显，在10万元素遍历时性能反而没有Stream.forEach好了，不过在实际项目开发中我们很少有超过10万元素的遍历。

所以可以得出结论：

在小List(万元素以内)遍历中for性能要优于Stream.forEach

理由二、for占用内存更小

Stream.forEach()会占用更多的内存，因为它涉及到创建流、临时对象或者对中间操作进行缓存。for 循环则更直接，操作底层集合，通常不会有额外的临时对象。可以看如下求和代码，运行时增加JVM参数-XX:+PrintGCDetails -Xms4G -Xmx4G输出GC日志：

• 使用for遍历

List<Integer> ids = IntStream.range(1,10000000).boxed().collect(Collectors.toList());

int sum = 0;

for (int i = 0; i < ids.size(); i++) {

    sum +=ids.get(i);

}

System.gc();

//GC日志

[GC (System.gc()) [PSYoungGen: 392540K->174586K(1223168K)] 392540K->212100K(4019712K), 0.2083486 secs] [Times: user=0.58 sys=0.09, real=0.21 secs]                               

从GC日志中可以看出，使用for遍历List在GC回收前年轻代使用了392540K，总内存使用了392540K，回收耗时0.20s

• 使用stream

List<Integer> ids = IntStream.range(1,10000000).boxed().collect(Collectors.toList());

int sum = ids.stream().reduce(0,Integer::sum);

System.gc();

//GC日志

[GC (System.gc()) [PSYoungGen: 539341K->174586K(1223168K)] 539341K->212118K(4019712K), 0.3747694 secs] [Times: user=0.55 sys=0.83, real=0.38 secs]                              

从GC日志中可以看出，回收前年轻代使用了539341K，总内存使用了539341K，回收耗时0.37s ，从内存占用情况来看使用for会比Stream.forEach()占用内存少37%，而且Stream.foreach() GC耗时比for多了85%。

理由三、for更易控制流程

我们使用for遍历List可以很方便的使用break、continue、return来控制循环，而使用Stream.forEach在循环中是不能使用break、continue，特别指出的使用return是无法中断Stream.forEach循环的，如下代码：

List<Integer> ids = IntStream.range(1,4).boxed().collect(Collectors.toList());

ids.stream().forEach(i->{

    System.out.println(""+i);

    if(i>1){

        return;

    }

});

System.out.println("==");

for (int i = 0; i < ids.size(); i++) {

    System.out.println(""+ids.get(i));

    if(ids.get(i)>1){

        return;

    }

}

输出：

forEach-1

forEach-2

forEach-3

==

for-1

for-2

从输出结果可以看出在Stream.forEach中使用return后循环还会继续执行的，而在for循环中使用return将中断循环。

理由四、for访问变量更灵活

这点我想是很多人在使用Stream.forEach中比较头疼的一点，因为在Stream.forEach中引用的变量必须是final类型，也就是说不能修改forEach循环体之外的变量，但是我们很多业务场景就是修改循环体外的变量，如以下代码:

Integer sum=0;

for (int i = 0; i < ids.size(); i++) {

    sum++;

}



ids.stream().forEach(i -> {

    //报错

    sum++;

});

像上面的这样的代码在实际中是很常见的，sum++在forEach中是不被允许的，有时为了使用类似的方法我们只能把变量变成一个引用类型：

AtomicReference<Integer> sum= new AtomicReference<>(0);

ids.stream().forEach(i -> {

    sum.getAndSet(sum.get() + 1);

});

所以在访问变量方面for会更加灵活。

理由五、for处理异常更方便

这一点也是我使用forEach比较头疼的，在forEach中的Exception必须要捕获处理，如下代码：

public void testException() throws Exception {

  List<Integer> ids = IntStream.range(1, 4).boxed().collect(Collectors.toList());

  for (int i = 0; i < ids.size(); i++) {

      //直接抛出Exception

      System.out.println(div(i, i - 1));

  }



  ids.stream().forEach(x -> {

      try {

          //必须捕获Exception

          System.out.println(div(x, x - 1));

      } catch (Exception e) {

          throw new RuntimeException(e);

      }

  });

}



private Integer div(Integer a, Integer b) throws Exception {

    return a / b;

}

我们在循环中调用了div()方法，该方法抛出了Exception，如果是使用for循环如果不想处理可以直接抛出，但是使用forEach就必须要自己处理异常了，所以for在处理异常方面会更加灵活方便。

理由六、for能对集合添加、删除

在for循环中可以直接修改原始集合（如添加、删除元素），而 Stream 不允许修改基础集合，会抛出 ConcurrentModificationException，如下代码：

List<Integer> ids = IntStream.range(0, 4).boxed().collect(Collectors.toList());

for (int i = 0; i < ids.size(); i++) {

    if(i<1){

        ids.add(i);

    }

}

System.out.println(ids);



List<Integer> ids2 = IntStream.range(0, 4).boxed().collect(Collectors.toList());

ids2.stream().forEach(x -> {

    if(x<1){

        ids2.add(x);

    }

});

System.out.println(ids2);

输出：

[0, 1, 2, 3, 0]

java.util.ConcurrentModificationException

如果你想在循环中添加或者删除元素foreach是无法完成了，所以for处理集合更方便。

理由七、for Debug更友好

Stream.forEach()使用了Lambda表达示，一行代码可以搞定很多功能，但是这也给Debug带来了困难，如下代码：

List<Integer> ids = IntStream.range(0, 4).boxed().collect(Collectors.toList());

for (int i = 0; i < ids.size(); i++) {

    System.out.println(ids.get(i));

}

List<Integer> ids2 = IntStream.range(0, 4).boxed().collect(Collectors.toList());

ids2.stream().forEach(System.out::println);

以下是DeBug截图：

我们可以看出使用for循环Debug可以一步一步的跟踪程序执行步骤，但是使用forEach却做不到，所以for可以更方便的调试你的代码，让你更快捷的找到出现问题的代码。

理由八、for代码可读性更好

Lambda表达示属于面向函数式编程，主打的就是一个抽象，相比于面向对象或者面向过程编程代码可读性是非常的差，有时自己不写的代码过段时间后自己都看不懂。就比如我在文章《解密阿里大神写的天书般的Tree工具类，轻松搞定树结构！》一文中使用函数式编程写了一个Tree工具类，我们可以对比一下面向过程和面向函数式编程代码可读性的差距：

• 使用for面向过程编程代码：

 public static List<MenuVo> makeTree(List<MenuVo> allDate,Long rootParentId) {

      List<MenuVo> roots = new ArrayList<>();

      for (MenuVo menu : allDate) {

          if (Objects.equals(rootParentId, menu.getPId())) {

              roots.add(menu);

          }

      }

      for (MenuVo root : roots) {

           makeChildren(root, allDate);

      }

      return roots;

  }

  public static MenuVo makeChildren(MenuVo root, List<MenuVo> allDate) {

      for (MenuVo menu : allDate) {

          if (Objects.equals(root.getId(), menu.getPId())) {

              makeChildren(menu, allDate);

              root.getSubMenus().add(menu);

          }

      }

      return root;

  }

• 使用forEach面向函数式编程代码：

public static <E> List<E> makeTree(List<E> list, Predicate<E> rootCheck, BiFunction<E, E, Boolean> parentCheck, BiConsumer<E, List<E>> setSubChildren) {

      return list.stream().filter(rootCheck).peek(x -> setSubChildren.accept(x, makeChildren(x, list, parentCheck, setSubChildren))).collect(Collectors.toList());

}

private static <E> List<E> makeChildren(E parent, List<E> allData, BiFunction<E, E, Boolean> parentCheck, BiConsumer<E, List<E>> children) {

    return allData.stream().filter(x -> parentCheck.apply(parent, x)).peek(x -> children.accept(x, makeChildren(x, allData, parentCheck, children))).collect(Collectors.toList());

}

对比以上两段代码，可以看出面向过程的代码思路非常的清晰，基本上可以一眼看懂代码要做什么，反观面向函数式编程的代码，我想大都人一眼都不知道代码在干什么的，所以使用for的代码可读性会更好。

理由九、for更好的管理状态

for循环可以轻松地在每次迭代中维护状态，这在Stream.forEach中可能需要额外的逻辑来实现。这一条可理由三有点像，我们经常需要通过状态能控制循环是否执行，如下代码：

boolean  flag = true;

for (int i = 0; i < 10; i++) {

    if(flag){

        System.out.println(i);

        flag=false;

    }

}



AtomicBoolean flag1 = new AtomicBoolean(true);

IntStream.range(0, 10).forEach(x->{

    if (flag1.get()){

        flag1.set(false);

        System.out.println(x);

    }

});

这个例子说明了在使用Stream.forEach时，为了维护状态，我们需要引入额外的逻辑，如使用AtomicBoolean，而在for循环中，这种状态管理是直接和简单的。

理由十、for可以使用索引直接访问元素

在某些情况下，特别是当需要根据元素的索引（位置）来操作集合中的元素时，for就可以直接使用索引访问了。在Stream.forEach中就不能直接通过索引访问，比如我们需要将ids中的数字翻倍：

List<Integer> ids = IntStream.range(0, 4).boxed().collect(Collectors.toList());

for (int i = 0; i < ids.size(); i++) {

   ids.set(i,i*2);

}



List<Integer> ids2 = IntStream.range(0, 4).boxed().collect(Collectors.toList());

ids2=ids2.stream().map(x->x*2).collect(Collectors.toList());

我们使用for循环来遍历这个列表，并在每次迭代中根据索引i来修改列表中的元素。这种操作直接且直观。而使用Stream.foreach()不能直接通过索引下标访问元素的，只能将List转换为流，然后使用map操作将每个元素乘以2，最后，我们使用Collectors.toList()将结果收集回一个新的List。

总结

本文介绍了在实际开发中更推荐使用for循环而不是Stream.foreach()来遍历List的十大理由，并给出了具体的代码和测试结果，当然这并不是说就一定要使用传统的for循环，要根据自己的实际情况来选择合适的方法。通过此案件也想让读者明白在互联网世界中你所看到的东西都是别人想让你看到的，这个世界是没有真相的，别人想让你看到的就是所谓的”真相“，做为吃瓜群众一定不能随波逐流，要有鉴别信息真假的能力和培养独立思考的能力。

DTO、BO、PO、VO是什么

在讨论这些是什么的时候，建议先看看我的这篇文章：写好业务代码的经典案例 - 掘金 (juejin.cn)

在上面我的这篇文章中提到的缺乏模型抽象，无边界控制，就是正好对应的DTO BO PO VO这些模型的概念

如何对模型进行抽象，控制边界，可用看看我的这篇文章 ：为啥建议用MapperStruct，不建议用BeanUtils.copyProperties拷贝数据？ - 掘金 (juejin.cn)

在后端开发中，比如传统的MVC架构和现在流行的DDD架构，经常会使用到下列几种对象的概念

• DTO (Data Transfer Object) 数据传输对象： DTO设计模式用于将数据从服务端传输到客户端，或者在不同的服务之间传递。通常，DTO包含了特定业务场景需要的数据结构，并且不包含任何业务逻辑。它简化了不同服务或模块之间的交互，使得各个层之间的耦合度降低。


• BO (Business Object) 业务对象： BO代表了业务逻辑层中的对象，封装了与某个业务相关的数据以及针对这些数据的操作逻辑。一个BO可能由多个实体属性组成，并处理涉及多个实体的复杂业务逻辑。


• PO (Persistent Object) 持久化对象： PO主要用来表示数据库表的一条记录，它的属性和数据库表的字段相对应。通常在持久层（如Hibernate、JPA等ORM框架）中使用，主要用于操作数据库，如保存、更新和查询数据。


• VO (Value Object) 值对象： VO是视图层的对象，通常用于封装展示给用户的数据，它可以和数据库表对应，也可以根据UI界面需求进行定制。VO的主要目的是在页面展示时只携带必要的数据，从而避免把大量不必要的数据暴露给前端。

举个实际代码的例子，这里暂不给出VO，在最后的总结会讲这个VO

• 这个就是PO

@Data

public class User implements Serializable{

    private Long id;



    private String username;



    private String password;



    private String identityCard;



    private String gender;



    private String location;



    private String userImage;



    private String phoneNumber;



    private String createTime;



    private String updateTime;



    @TableLogic

    private int isDelete;

}

• UserDTO

@Data

public class UserDTO implements Serializable{

    private Long id;



    private String username;



    private String password;



    private String identityCard;



    private String gender;



    private String location;



    private String userImage;



    private String phoneNumber;

}

• UserLoginBO、UserUpdateBO ...

@Data

public class UserLoginBO implements Serializable{

    private String username;



    private String password;

}



@Data

public class UserUpdateBO implements Serializable{

    private Long id;



    private String username;



    private String password;



    private String identityCard;



    private String gender;



    private String location;



    private String userImage;



    private String phoneNumber;

}

从上面这个例子大家能看出来区别不

UserDTO是一个大的入口，它可以接收整个模块的参数

BO则是在进入Service层之前对UserDTO的数据进行过滤，并且对边界进行控制

最后在进入infra层之前转为PO

其实BO也可以像UserDTO那样，直接一个UserBO包含UserLoginBO和UserUpdateBO，单纯的做模型转换，不做值过滤也可以

在后端开发中怎么用的

总结

为什么我们通篇没有讲关于VO的事情呢？

我个人的理解是DTO能解决的事情没有必要再加一个VO，我们可以弄一个全局配置，将DTO里面为null值的字段全都过滤掉

这样就没有说将数据传给前端的时候需要加多一个VO

给出代码示例，这样配置就可以把DTO中为null值过滤掉，不会序列化发给前端

@Configuration

public class GlobalConfig extends WebMvcConfigurationSupport {



    @Override

    protected void configureMessageConverters(List<HttpMessageConverter<?>> converters) {

        super.configureMessageConverters(converters);

        converters.add(mappingJackson2HttpMessageConverter());

    }

    /**

     * 自定义mappingJackson2HttpMessageConverter

     * 目前实现：空值忽略，空字段可返回

     */

    private MappingJackson2HttpMessageConverter mappingJackson2HttpMessageConverter() {

        ObjectMapper objectMapper = new ObjectMapper();

        objectMapper.configure(SerializationFeature.FAIL_ON_EMPTY_BEANS, false);

        objectMapper.setSerializationInclusion(JsonInclude.Include.NON_NULL);

        return new MappingJackson2HttpMessageConverter(objectMapper);

    }

}