在电商系统或任何涉及订单操作的场景中，用户多次点击“提交订单”按钮可能会导致重复订单提交，造成数据冗余和业务逻辑错误，导致库存问题、用户体验下降或财务上的错误。因此，防止订单重复提交是一个常见需求。

常见的重复提交场景

防止重复提交的需求

常用解决方案

前端防重机制：在前端按钮点击时禁用按钮或加锁，防止用户多次点击。

后端幂等处理：

• 利用Token机制：在订单生成前生成一个唯一的Token，保证每个订单提交时只允许携带一次Token。


• 基于数据库的唯一索引：通过对订单字段（如订单号、用户ID）创建唯一索引来防止重复数据的插入。


• 分布式锁：使用Redis等分布式缓存加锁，保证同一时间只允许处理一个订单请求。

功能实践

Spring Boot 提供了丰富的工具和库，今天我们基于Spring Boot框架，可以利用 Token机制 和 Redis分布式锁 来防止订单的重复提交。

功能原理与技术实现

通过Redis的原子性操作，我们可以确保高并发情况下多个请求对同一个订单的操作不会冲突。

Token机制

Token机制是一种常见的防止重复提交的手段，通常的工作流程如下：

这种机制确保每次提交订单时都需要一个有效且唯一的Token，从而有效防止重复提交。

Redis分布式锁

在多实例的分布式环境中，Token机制可以借助 Redis 来实现更高效的分布式锁：

流程设计

功能实现

依赖配置（pom.xml）

<dependency>

    <groupId>org.springframework.boot</groupId>

    <artifactId>spring-boot-starter-data-redis</artifactId>

</dependency>

<dependency>

    <groupId>org.springframework.boot</groupId>

    <artifactId>spring-boot-starter-web</artifactId>

</dependency>

application. properties

# Thymeleaf ??

spring.thymeleaf.prefix=classpath:/templates/

spring.thymeleaf.suffix=.html

spring.thymeleaf.mode=HTML

spring.thymeleaf.encoding=UTF-8

spring.thymeleaf.cache=false



spring.redis.host=127.0.0.1

spring.redis.port=23456

spring.redis.password=pwd

订单Token生成服务

生成Token并存储到Redis： 当用户请求生成订单页面时，服务器生成一个唯一的UUID作为订单Token，并将其与用户ID一起存储在Redis中。

package com.example.demo.service;



import lombok.extern.slf4j.Slf4j;

import org.springframework.beans.factory.annotation.Autowired;

import org.springframework.data.redis.core.RedisTemplate;

import org.springframework.stereotype.Service;



import java.util.UUID;

import java.util.concurrent.TimeUnit;



@Service

@Slf4j

public class OrderTokenService {



    @Autowired

    private RedisTemplate<String, String> redisTemplate;

    // 生成订单Token

    public String generateOrderToken(String userId) {

        String token = UUID.randomUUID().toString();

        // 将Token存储在Redis中，设置有效期10分钟

        redisTemplate.opsForValue().set("orderToken:" + userId, token, 10, TimeUnit.MINUTES);

        return token;

    }

    // 验证订单Token

    public boolean validateOrderToken(String userId, String token) {

        String redisToken = redisTemplate.opsForValue().get("orderToken:" + userId);

        log.info("@@ 打印Redis中记录的redisToken ：{} `VS` @@ 打印当前请求过来的token ：{}", redisToken, token);

        if (token.equals(redisToken)) {

            // 验证成功，删除Token

            redisTemplate.delete("orderToken:" + userId);

            return true;

        }

        return false;

    }

}

订单控制器

订单提交与验证Token： 提交订单时，系统会检查用户传递的Token是否有效，若有效则允许提交并删除该Token，确保同一Token只能提交一次。

package com.example.demo.controller;



import com.example.demo.entity.Order;

import com.example.demo.service.OrderTokenService;

import org.springframework.beans.factory.annotation.Autowired;

import org.springframework.http.HttpStatus;

import org.springframework.http.ResponseEntity;

import org.springframework.web.bind.annotation.*;



@RestController

@RequestMapping("/order")

public class OrderController {



    @Autowired

    private OrderTokenService orderTokenService;

    // 获取订单提交的Token

    @GetMapping("/getOrderToken")

    public ResponseEntity<String> getOrderToken(@RequestParam String userId) {

        String token = orderTokenService.generateOrderToken(userId);

        return ResponseEntity.ok(token);

    }

    // 提交订单

    @PostMapping("/submitOrder")

    public ResponseEntity<String> submitOrder(Order order) {

        // 校验Token

        if (!orderTokenService.validateOrderToken(order.getUserId(), order.getOrderToken())) {

            return ResponseEntity.status(HttpStatus.BAD_REQUEST).body("订单重复提交，请勿重复操作");

        }



        // 此处处理订单逻辑

        // ...

        

        // 假设订单提交成功

        return ResponseEntity.ok("订单提交成功");

    }

}

前端实现

前端通过表单提交订单，并在每次提交前从服务器获取唯一的订单Token：

<script>



    document.getElementById('orderForm').addEventListener('submit', function(event) {

    event.preventDefault();



    const userId = document.getElementById('userId').value;

    if (!userId) {

        alert("请填写用户ID");

        return;

    }



    // 先获取Token，再提交订单

    fetch(`/order/getOrderToken?userId=${userId}`)

        .then(response => response.text())

        .then(token => {

            document.getElementById('orderToken').value = token;



            // 提交订单请求

            const formData = new FormData(document.getElementById('orderForm'));

            fetch('/order/submitOrder', {

                method: 'POST',

                body: formData

            })

            .then(response => response.text())

            .then(result => {

                document.getElementById('message').textContent = result;

            })

            .catch(error => {

                document.getElementById('message').textContent = '订单提交失败，请重试';

            });

        })

        .catch(error => {

            document.getElementById('message').textContent = '获取Token失败';

        });

});



</script>

为了验证功能，我们在代码中增加 Thread.sleep(2000); 来进行阻塞。

然后快速点击提交表单，可以看到提示表单重复提价的信息

**技术选型与优化：**通过Redis结合Token机制，我们有效地防止了订单的重复提交，并通过Token的唯一性和时效性保证了订单操作的幂等性。

• Redis缓存：通过Redis的分布式锁和高并发处理能力，确保系统在高并发情况下仍然可以正常运行，并发订单提交的场景中不会出现Token重复使用问题。


• UUID：使用UUID生成唯一的Token，保证Token的唯一性和安全性。


• Token时效性：Token通过设置Redis的TTL（过期时间）来控制有效期，避免无效Token长期占用资源。

总结

防止订单重复提交的关键在于：

这套基于Token机制和Redis的解决方案具有简单、高效、可扩展的特点，适合各种高并发场景下防止重复订单提交。

背景

cron service 在执行定时任务时，需要能够实时查看该任务的执行日志以确保程序正确的工作。为了能够在尽可能短的时间内实现该功能，我们需要一个足够简单的方案。

方案如何选择？

我相信大多数开发者第一个想到的就是 WebSocket ，然后是 HTTP/SSE 。WebSocket 在很多情况下是实至名归的万金油选择。但这这里他太重了，对服务端和客户端具有侵入性需要花费额外的时间来集成到项目中。

那么 SSE 呢，为什么不是他？
虽然 SSE 即轻量又实时，但 SSE 无法设置请求头。这导致无法使用缓存和通过请求头设置的 Token。而且作为长链接他还一直占用并发额度。

• WebSocket：❌
  
  
  
  • 优势：
    
    
    
    • 实时性高
    
    
    • 不会占用 HTTP 并发额度
    
    
    
    
  
  
  • 劣势：
    
    
    
    • 复杂度较高，需要在客户端和服务器端都进行特殊的处理
    
    
    • 消耗更多的服务器资源。
    
    
    
    
  
  
  
  


• SSE(Server-Sent Events)：❌
  
  
  
  • 优势：
    
    
    
    • 基于HTTP协议，不需要在服务端和客户端做额外的处理
    
    
    • 实时性高
    
    
    
    
  
  
  • 劣势：
    
    
    
    • 无法设置请求头
    
    
    • 占用 HTTP 并发额度
    
    
    
    
  
  
  
  


• HTTP：✅
  
  
  
  • 优势：
    
    
    
    • 简单易用，不需要在服务端和客户端做额外的处理。
    
    
    • 支持的功能丰富，如缓存，压缩，认证等功能。
    
    
    
    
  
  
  • 劣势：
    
    
    
    • 实时性差，取决于轮询时间间隔。
    
    
    • 每次HTTP请求都需要建立新的连接（仅针对 HTTP/0.x 而言）并可能阻塞同源的其他请求而导致性能问题。¹²
      
      
      
      • HTTP/1.x 支持持久连接以避免每次请求都重新建立 TCP 连接，但数据通信是串行的。
      
      
      • HTTP/2.x 支持持久连接且支持并行的数据通信。
      
      
      
      
    
    
    
    
  
  
  
  

以上列出的优缺点是仅对于本文所讨论的场景（即Web 端的实时日志）而言，这三种数据交互技术在其他场景中的优缺点不在本文讨论范围内。

实现

HTTP 轮询已经是老熟人了，不再做介绍。本文的着重于实时日志的实现及优化。

sequenceDiagram



participant 浏览器



participant 服务器



Note right of 浏览器: 首先，获取日志文件最后 X bytes 的内容



浏览器->>服务器: 最新的日志文件有多大？



服务器->>浏览器: 日志文件大小: Y bytes



浏览器->>服务器: 从 Y - X bytes 处返回内容



服务器->>浏览器: 日志文件大小: Y1 bytes, 日志内容: XXXX



  



loop 持续轮询获取最新的日志



浏览器->>服务器: 从 Y1 bytes 处返回内容



服务器->>浏览器: 日志文件大小: Y2 bytes, 日志内容: XXXX



end

上方是基本工作原理的流程图。
实现的关键点在于

• 前端如何知道日志文件当前的大小


• 服务端如何从指定位置获取日志文件内容

这两点都可以通过 HTTP Header 来解决。Content-Range HTTP 响应头会包含完整文件的大小，而 Range HTTP 请求头可以指示服务器返回指定位置的文件内容。

因此在服务端不需要额外的逻辑，仅通过 Web 端代码就可以实现实时日志功能。

代码实现

篇幅限制，代码不会处理异常情况

首先，根据上述流程图。我们需要获取日志文件的大小。

const res = await fetch(URL, {  

  method: "GET",  

  headers: {  Range: "bytes=0-0"  }

});



const contentRange = res.headers.get("Content-Range") || "";  

const match = /bytes (\d+)-(\d+)\/(\d+)/.exec(contentRange);  



// 日志文件大小

const total = Number.parseInt(match[3], 10);

Range: "bytes=0-0" 指定仅获取第一个字节的内容，以免较大的日志文件导致响应时间过长。

我们发起了一个 GET 请求并将 Range 请求头设置为 bytes=0-0 如果服务器能够正确处理 Range 请求头，响应中将包含一个 Content-Range 列其中将包含日志文件的完整大小，可以通过正则解析拿到。

现在我们已经拿到了日志文件的大小并存储在名为 total 的变量中。然后根据 total 获取到最后 10 KB 的日志内容。

const res = await fetch(url, {  

  method: "GET",  

  headers: {  

    Range: `bytes=${total - 1000 * 10}-`

  }

});



const contentRange = res.headers.get("Content-Range") || "";

const match = /bytes (\d+)-(\d+)\/(\d+)/.exec(contentRange);



// 下一次请求的起始位置

const start = Number.parseInt(match[2], 10) + 1;



// 日志内容

const content = await res.text();

现在我们发起了一个 GET 请求并将 Range 请求头设置为 bytes=${total - 1000 * 10}- 以获取最后 10 KB 的日志内容。并且通过正则解析拿到了下一次请求的起始位置。

现在我们已经拿到了日志文件的大小和最后 10 KB 的日志内容。接下来就是持续轮询去获取最新的日志。轮询代码区别仅在于将 Range 标头设置为 bytes=${start}- 以便获取最新的日志。

const res = await fetch(url, {  

  method: "GET",  

  headers: {  

    Range: `bytes=${start}-`

  }

});



const contentRange = res.headers.get("Content-Range") || "";

const match = /bytes (\d+)-(\d+)\/(\d+)/.exec(contentRange);



// 下一次请求的起始位置

start = Number.parseInt(match[2], 10) + 1;



// 日志内容

const content = await res.text();

以上，基本的功能已经实现了。日志内容保存在名为 content 的变量中。

优化

HTTP 轮询常因其高延迟为人诟病，我们可以通过指数退避的方式来尽可能的降低延时且不会显著的增加服务器负担。

指数退避是一种常见的网络重试策略，它会在每次重试时将等待时间乘以一个固定的倍数。这样做的好处是，当网络出现问题时，重试的时间间隔会逐渐增加，直到达到最大值。

一个简单的实现如下：

/**

 * 使用指数退避策略获取日志.

 */

export class ExponentialBackoff {

  private readonly base: number;

  private readonly max: number;

  private readonly factor: number;

  private retries: number;



  /**

   * @param base 基础延迟时间 默认 1000ms (1秒)

   * @param max 最大延迟时间 默认 60000ms (1分钟)

   * @param factor 延迟时间增长因子 默认 2

   */

  constructor(base: number = 1000, max: number = 60000, factor: number = 2) {

    this.base = base;

    this.max = max;

    this.factor = factor;

    this.retries = 0;

  }



	/**

	 * 获取下一次重试的延迟时间.

	 */

	next() {

    const delay = Math.min(this.base * Math.pow(this.factor, this.retries), this.max);

    this.retries++;

    return delay;

  }



  /**

	 * 重置重试次数.

	 */

  reset() {

    this.retries = 0;

  }

}

值得一提的是带有 Range 标头的请求成功时会返回 206 Partial Content 状态码。而在请求的范围超出文件大小时会返回 416 Range Not Satisfiable 状态码。我们可以通过这两个状态码来判断请求是否成功。

成功时调用 reset 方法重置重试次数，失败时调用 next 方法获取下一次重试的延迟时间。

总结

即使再优秀的方案也不是银弹，真正合适的方案需要考虑的不仅仅是技术本身，还有业务场景，团队技术栈，团队技术水平等等。在选择技术方案时，我们需要权衡各种因素，而不是盲目的选择最流行的技术。

当我们责备现有的技术方案为何如此糟糕时，或许在那个时间点上，这个方案是最合适的。

感谢以下网友的帮助和建议：齐洛格德

Footnotes

序言

提示信息（tooltip）是一种常见的 GUI 元素。在可视化领域，tooltip 通常指用户将鼠标悬停在图元上或者图表区域时弹出的明细数据信息框。如果是桌面环境，通常会在用户将指针悬停在元素上而不单击它时显示 tooltip；如果是移动环境，通常会在长按（即点击并按住）元素时显示 tooltip。

这样一个小小的组件，却可以十分有效地丰富图表的数据展现能力和图表交互效果，同时在实际业务领域的用途也非常广泛。

近些年来，业界主要图表库（如ECharts、G2等）都提供了 tooltip 的配置能力和默认渲染能力，以达到开箱即用的效果。VChart 更不例外，提供了更加灵活的 tooltip 展示与配置方案。

通过使用 VChart，你既可以显示图表中任何系列的图元所携带的数据信息（mark tooltip）：

也可以显示某个特定维度项下的所有图元的数据信息（dimension tooltip）：

乃至可以灵活地自定义 tooltip，甚至在其中插入子图表，拓展交互的边界：

本文将通过一些实战案例，详细讲述 VChart 提示信息的重点用法、自定义方式以及设计细节。

示例一：可触及的 tooltip，与 Amazon 的安全三角形

为了不对用户的鼠标交互进行干扰，VChart 的 tooltip 默认不会响应鼠标事件。但是在某些情况，用户却希望鼠标可以移到 tooltip 中进行一些额外的交互行为，比如点击 tooltip 中的按钮和链接，或者选取并复制一些数据。

为了满足这类需求，tooltip 支持在 spec 中配置 enterable 属性。如果不配置或者配置 enterable: false，默认效果是这样的，鼠标无法移到 tooltip 元素内：

而如果配置 enterable: true，效果如以下截图所示：

图表简化版 spec 为：

const spec = {

  type: 'waterfall',

  data: [], // 数据略

  legends: { visible: true, orient: 'bottom' },

  xField: 'x',

  yField: 'y',

  seriesField: 'type',

  total: {

    type: 'field',

    tagField: 'total'

  },

  title: {

    visible: true,

    text: 'Chinese quarterly GDP in 2022'

  },

  tooltip: {

    enterable: true // TOOLTIP SPEC

  }

};



const vchart = new VChart(spec, { dom: CONTAINER_ID });

vchart.renderSync();

简单对比两个 tooltip 的效果，可以发现后者在鼠标靠近 tooltip 时，tooltip 便适时地停住了。

这个小小的交互细节里却有些文章，灵感来源直接来自 Amazon 的官网实现。

这个例子也许已经为人熟知，我们简单回顾一下。这首先要从普通网站的下拉菜单开始讲起：

在一个设计欠佳的菜单组件里（如 bootstrap），鼠标从一级菜单移入二级菜单往往是很困难的，很容易触发二级菜单的隐藏策略，从而变成一场无聊的打地鼠游戏。

但是 Amazon 早期官网的菜单，由于用户使用频率高，根本无法接受这样的体验。于是他们完美地解决了这个问题，并成为一个交互优化的经典案例。

其思路的核心，便是检测鼠标移动的方向。如果鼠标移动到下图的蓝色三角形中，当前显示的子菜单将继续打开一小会儿：

在鼠标的每个位置，你可以想象鼠标当前位置与下拉菜单的右上角和右下角之间形成一个三角形。如果下一个鼠标位置在该三角形中，说明用户可能正在将鼠标移向当前显示的子菜单。Amazon 利用这一点实现了很好的效果。只要鼠标停留在该蓝色三角形中，当前子菜单就会保持打开。如果鼠标移出该三角形，他们会立即切换子菜单，使其感觉非常敏捷。

整体效果类似于下图所示：

正所谓，上帝在细节中（God is in the details）。从这个交互优化里，我们看到的不仅是一个精妙的算法，而是一个科技巨头对于产品和用户体验的态度。Amazon 的数百亿市值有多少是从这些很小很小，但是明显很用心的产品细节中积累起来的呢？

VChart 的 tooltip 也一样，着重参考了 Amazon 的交互优化。如果配置 enterable: true，在每个时刻，都会存在一个这样的“安全三角形”，三个顶点分别是鼠标光标以及 tooltip 的两个端点，取面积最大的三角形：

如果鼠标在下一刻滑到这个三角形区域中， tooltip 便为鼠标“停留一会儿”，直到鼠标移到 tooltip 区域内。

但是在鼠标移到 tooltip 区域之前，tooltip 并不会永远停下来等待鼠标。如果鼠标过于缓慢地靠近 tooltip，tooltip 还是会离开的（变成一场失败、却又在意料之中的奔赴）。这样便可以同时保证用户鼠标有足够的行动自由度。以下示例特地将鼠标移动速度放慢，便可以实现既进入三角形区域，又不会被 tooltip “挡路”：

作为对比，ECharts 的 tooltip 虽然同样支持 enterable 属性，但是 ECharts 主要通过简单的 tooltip 缓动来支持鼠标移入，鼠标仍需要不停地“追逐” tooltip 才能移至其中，灵活性便打了折扣。以下为 ECharts 的效果：

示例二：灵活的 pattern，内容与样式的自由配置

为了尽最大可能满足更多业务方的需求，VChart 的 tooltip 支持比较灵活的内容和样式配置。下文将以官网 demo（http://www.visactor.io/vchart/demo…

在这个图表中，用户配置了一条 y=10000 的标注线。同时要求在 dimension tooltip 中实现：

• 数据项从大到小排序；


• 比标注线高的数据项标红（条件格式）；


• 在 tooltip 内容的最后一行加上标注线所代表的数据。

同时，这个 tooltip 的位置还拥有以下特征：

• dimension tooltip 的位置固定在光标上方；


• mark tooltip 的位置固定在数据项下方。

如以下动图所示：

这个示例实际上代表了很多不同类型的业务需求。下面拆解来看一下：

基本 tooltip 内容配置

首先，剥去自定义内容和样式的部分，这个图表的最简 spec 和基本 tooltip 配置如下：

const markLineValue = 10000;

const spec = {

  type: 'line',

  data: {

    values: [

      { type: 'Nail polish', country: 'Africa', value: 4229 },

      // 其他数据略

    ]

  },

  stack: false,

  xField: 'type',

  yField: 'value',

  seriesField: 'country',

  legends: [{ visible: true, position: 'middle', orient: 'bottom' }],

  markLine: [

    {

      y: markLineValue,

      endSymbol: { visible: false },

      line: { style: { /* 样式配置略 */ }}

    }

  ],

  tooltip: { // TOOLTIP SPEC

    mark: {

      title: {

        value: datum => datum.type

      },

      content: [

        {

          key: datum => datum.country,

          value: datum => datum.value

        }

      ]

    },

    dimension: {

      title: {

        value: datum => datum.type

      },

      content: [

        {

          key: datum => datum.country,

          value: datum => datum.value

        }

      ]

    }

  }

};



const vchart = new VChart(spec, { dom: CONTAINER_ID });

vchart.renderSync();

显示效果如下：

观察 spec 不难发现，mark tooltip 和 dimension tooltip 分别用回调方式配置了 tooltip 的显示内容。其中：

• title.value 显示的是数据项中对应于 xField 的内容；


• content.key 显示的是数据项中对应于 seriesField（也是区分出图例项的 field）的内容；


• content.value 显示的是数据项中对应于 yField 的内容。

回调是 tooltip 内容的基本配置方式，用户可以在 title 和 content 中自由配置回调函数来实现数据绑定和字符串的格式化。

Tooltip 内容的排序、增删、条件格式

我们再来看一下 dimension tooltip 的 spec：

{

  tooltip: { // TOOLTIP SPEC

    mark: { /* ...略 */ },

    dimension: {

      title: {

        value: datum => datum.type

      },

      content: [

        {

          key: datum => datum.country,

          value: datum => datum.value

        }

      ]

    }

  }

}

不难发现，content 配置的数组只包含 1 个对象，但是上图显示出来却有 4 行内容。为什么呢？

其实在 dimension tooltip 中发生了和折线图元类似的 data join 过程：由于在数据中，seriesField 划分出了 4 个数据组（图例项有 4 个），因此在经过笛卡尔积后，真实 tooltip 内容行数为 content 数组成员数量乘以 4。在数据组装过程中，每个数据组都要依次走一遍 content 数组成员里的回调。

我们把 spec 中的 tooltip 内容配置称为 TooltipPattern，tooltip 所需数据称为 TooltipData，最终的 tooltip 结构称为 TooltipActual。数据组装过程可以表示为：

$MakeTooltip(TooltipPattern, TooltipData) = TooltipActual$

在本例中，经过这个过程，TooltipPattern 中的回调在 TooltipActual 中消失（回调已被执行 4 次），且由 1 行变成了 4 行。

这个过程完整的执行流程如下：

那么回到示例中的用户需求，用户希望将 tooltip 内容行由大到小排序。那么这个步骤自然要在 TooltipActual 生成之后执行，也就是上图中的 “updateTooltipContent” 过程。

Tooltip spec 中支持配置 updateContent 回调来对 TooltipActual 的 content 部分进行操作。排序可以这样写：

{

  tooltip: { // TOOLTIP SPEC

    mark: { /* ...略 */ },

    dimension: {

      title: {

        value: datum => datum.type

      },

      content: [

        {

          key: datum => datum.country,

          value: datum => datum.value

        }

      ],

      updateContent: prev => {

        // 排序

        prev.sort((a, b) => b.value - a.value);

      }

    }

  }

}

updateContent 回调的第一个参数为已经计算好的 TooltipActual。加上回调以后，排序生效：

在 tooltip 中实现条件格式以及新增一行也是一样的方法，可以直接在 updateContent 回调中处理：

{

  updateContent: prev => {

    // 排序

    prev.sort((a, b) => b.value - a.value);

    // 条件格式：比标注线高的数据项标红

    prev.forEach(item => {

      if (item.value >= markLineValue) {

        item.valueStyle = {

          fill: 'red'

        };

      }

    });

    // 新增一行

    prev.push({

      key: 'Mark Line',

      value: markLineValue,

      keyStyle: { fill: 'orange' },

      valueStyle: { fill: 'orange' },

      // 自定义 shape 的 svg path

      shapeType: 'M44.3,22.1H25.6V3.3h18.8V22.1z M76.8,3.3H58v18.8h18.8V3.3z M99.8,3.3h-9.4v18.8h9.4V3.3z M12.9,3.3H3.5v18.8h9.4V3.3z',

      shapeColor: 'orange',

      hasShape: true

    });

  }

}

调试 spec，回调生效，最后效果如下：

Tooltip 样式和位置

VChart tooltip 支持将 tooltip 固定于某图元附近或者鼠标光标附近。在本例中，mark tooltip 固定于图元的下方，而 dimension tooltip 固定于鼠标光标的上方，可以这样配置：

{

  tooltip: { // TOOLTIP SPEC

    mark: {

      // 其他配置略

      position: 'bottom' // 显示在下方

      positionAt: 'mark' // 固定在图元附近，由于这是默认值，这行可以删掉

    },

    dimension: {

      // 其他配置略

      position: 'top', // 显示在上方

      positionAt: 'pointer' // 固定在鼠标光标附近

    }

  }

}

而样式配置可以在 tooltip spec 上的 style 配置项下进行自定义。style 支持配置 tooltip 组件各个组成部分的统一样式，详细配置项可参考官网文档（http://www.visactor.io/vchart/opti…

最后效果如下，完整 spec 可见官网 demo（http://www.visactor.io/vchart/demo…

示例三：锦上添花，可按需修改的 tooltip dom 树

VChart 的 tooltip 共支持两种渲染模式：

• Dom 渲染，适用于桌面或移动端浏览器环境；


• Canvas 渲染，适用于移动端小程序、node 环境等非浏览器环境。

对于 dom 版本的 tooltip，为了更好的支持业务方的自定义需求，VChart 开放了对 tooltip dom 树的修改接口。下文将以官网 demo（http://www.visactor.io/vchart/demo…

在这个示例中，用户要求在 tooltip 的底部增加一个超链接，用户点击链接后，便可以自动跳转到 Google，对 tooltip 标题进行进一步搜索。这个示例要求两个能力：

• 示例一介绍的 enterable 能力，开启后鼠标会被允许滑入 tooltip 区域，这是在 tooltip 中实现交互的前提；


• 在默认 tooltip 上绘制自定义的 dom 元素。

为了实现第二个能力，tooltip 支持了回调 updateElement，这个回调配在 tooltip spec 顶层。这个示例的 tooltip 配置如下：

{

  tooltip: { // TOOLTIP SPEC

    enterable: true,

    updateElement: (el, actualTooltip, params) => {

      // 自定义元素只加在 dimension tooltip 上

      if (actualTooltip.activeType === 'dimension') {

        const { changePositionOnly, dimensionInfo } = params;

        // 判断本次 tooltip 显示是否仅改变了位置，如果是的话退出

        if (changePositionOnly) { return; }

        // 改变默认 tooltip dom 的宽高策略

        el.style.width = 'auto';

        el.style.height = 'auto';

        el.style.minHeight = 'auto';

        el.getElementsByClassName('value-box')[0].style.flex = '1';

        for (const valueLabel of el.getElementsByClassName('value')) {

          valueLabel.style.maxWidth = 'none';

        }

        // 删除上次执行回调添加的自定义元素

        if (el.lastElementChild?.id === 'button-container') {

          el.lastElementChild.remove();

        }

        // 添加新的自定义元素

        const div = document.createElement('div');

        div.id = 'button-container';

        div.style.margin = '10px -10px 0px';

        div.style.padding = '10px 0px 0px';

        div.style.borderTop = '1px solid #cccccc';

        div.style.textAlign = 'center';

        div.innerHTML = `href="https://www.google.com/search?q=${dimensionInfo[0]?.value}"

          style="text-decoration: none"

          target="_blank"

        >Search with Google`;

        el.appendChild(div);

      } else {

        // 对于 mark tooltip，删除上次执行回调添加的自定义元素

        if (el.lastElementChild?.id === 'button-container') {

          el.lastElementChild.remove();

        }

      }

    }

  }

}

updateElement在每次 tooltip 被激活或者更新时触发，在触发时，TooltipActual 已经计算完毕，且 dom 节点也已经准备好。回调的第一个参数便是本次将要显示的 tooltip dom 根节点。目前不支持替换该节点，只支持对该节点以及其孩子进行修改。

这个配置的设计最大限度地复用了 VChart tooltip 的内置逻辑，同时提供了足够自由的自定义功能。你可以随心所欲地定制 tooltip 显示内容，并且复用任何你没有覆盖的逻辑。

比如，你可以对 tooltip 的大小进行重新定义，而不用关心窗口边界的躲避策略是否会出问题。事实上 VChart 会自动把 tooltip 定位逻辑复用在修改过的 dom 上：

这个回调还可以进一步封装，比如在 react-vchart 中将用户侧的 react 组件插入 tooltip。目前这个封装主要由业务侧自主进行，后续 VChart 也有计划提供官方支持。

示例四：完全自定义，由业务托管 tooltip 渲染

若要更进一步，VChart tooltip 最高级别的自定义，便是让 VChart 完全将 tooltip 渲染交给用户。有以下两种方式可以选择：

• 用户自定义 tooltip handler


• 用户使默认 tooltip 失效，监听 tooltip 事件

再结合示例二、示例三的铺垫，便可以带出整个 tooltip 模块的设计架构。熟悉了架构便更容易了解每条渲染路径以及各个层级的关系。

由上图可见，示例三对应的是 “Custom DOM Render” 的自定义，示例二对应了 “Custom TooltipActual” 部分的自定义。而示例四，便是对应整个 “Tooltip Events” 以及 “Custom TooltipHandler” 的自定义。

由于上图中，“Tooltip Events” 和 “Custom TooltipHandler” 纵跨了多个层级，因此它覆盖的默认逻辑是最多的，体现在：

• 当给图表设置了自定义 tooltip handler 后，内置的 tooltip 将不再起作用。


• VChart 不感知、不托管自定义 tooltip 的渲染，需要自行实现 tooltip 渲染，包括处理原始数据、tooltip 内容设计，以及根据项目环境创建组件并设置样式。


• 当图表删除时会调用当前 tooltip handler 的release函数，需要自行实现删除。

目前，火山引擎 DataWind 正是使用自定义 tooltip handler 的方式实现了自己的图表 tooltip。DataWind 支持用户对tooltip 进行富文本渲染，甚至支持了 tooltip 内渲染图表的能力。

另外，也可以参考官网示例（http://www.visactor.io/vchart/demo…

自定义 tooltip handler 的核心是调用 VChart 实例方法 setTooltipHandler，部分示例代码如下：

vchart.setTooltipHandler({

  showTooltip: (activeType, tooltipData, params) => {

    const tooltip = document.getElementById('tooltip');

    tooltip.style.left = params.event.x + 'px';

    tooltip.style.top = params.event.y + 'px';

    let data = [];

    if (activeType === 'dimension') {

      data = tooltipData[0]?.data[0]?.datum ?? [];

    } else if (activeType === 'mark') {

      data = tooltipData[0]?.datum ?? [];

    }

    tooltipChart.updateData(

      'tooltipData',

      data.map(({ type, value, month }) => ({ type, value, month }))

    );

    tooltip.style.visibility = 'visible';

  },

  hideTooltip: () => {

    const tooltip = document.getElementById('tooltip');

    tooltip.style.visibility = 'hidden';

  },

  release: () => {

    tooltipChart.release();

    const tooltip = document.getElementById('tooltip');

    tooltip.remove();

  }

});

其他特性一览

VChart tooltip 包含一些其他的高级特性，下文将简要介绍。

在任意轴上触发 dimension tooltip

Dimension tooltip 一般最适合用于离散轴，ECharts 同时支持连续轴上的 dimension tooltip（axis tooltip）。而 VChart 支持了在连续轴、时间轴乃至在一个图表中的任意一个轴上触发 dimension tooltip。

以下示例展示了 dimension tooltip 在连续轴（时间轴）上汇总离散数据的能力（这个 case 和一般的 dimension tooltip 刚好相反）：

一般的 dimension tooltip 会在离散轴（纵轴）触发 tooltip，汇总连续数据（对应于时间轴）。而 VChart 同时支持这两种方式的 tooltip。

Demo 地址：http://www.visactor.io/vchart/demo…

长内容支持：换行和局部滚动

过长的内容在 tooltip 上一般是 bad case。但是为了使长内容的浏览体验更好，VChart tooltip 可以配置多行文本以及内容区域局部滚动。如以下示例：

局部滚动 Demo 地址：http://www.visactor.io/vchart/demo…

多行文本配置项：http://www.visactor.io/vchart/opti…

结语

Tooltip 在提升用户浏览图表的体验中扮演着重要的角色。本文介绍了 VChart tooltip 的基本使用方法、技术设计以及多层面的自定义方案。然而为了保证行文清晰，VChart tooltip 还有一些其他的用法细节本文没有涉及，想了解更多可以查阅官网 demo 以及文档。

然而需要提醒的是，虽然 tooltip 能够有效传递数据与信息、以及增加图表的互动能力，但过分依赖它们可能会导致用户体验下降。合理地利用 tooltip，让它们在需要时出现而不干扰用户的主要任务，是设计和开发中应保持的平衡。

希望本文能为你在配置 VChart tooltip 时提供有用的指导。愿你在图表中创造更加直观、轻松且愉快的用户体验时，VChart 能成为你强大的伙伴。

github：github.com/VisActor/VC…

相关参考：

快要高考了，最近身边发生了不少事，感触颇深，我想记录一下。大家都知道高考是唯一公平竞争的机会，也是寒门贵子唯一一次想翻身的机会。但是，每个人情况和起点不一致，考试是公平的，但出身是不公平的，出身在河南落后的农村的小镇做题家和出身在上海的繁华大都市的国际学校的先进教育资源一样吗？答案可想而知。

身边有个亲人出身河南农村，这几天刚大学本科毕业，通过校招拿到了某物流领域独角兽公司的offer，base杭州，待遇是6k左右底薪，思考再三，他弟弟选择拒掉了offer，原因是，觉得靠自己这个收入全年无休也买不起杭州的房子，还要跟对象常年异地（对象在老家教师），于是选择去卷老家的编制岗，至少不用考虑买房，还能顾上了家庭，但是他的父母却表示不理解：说一辈子都没出息了，作为农民出身辛苦一辈子供出来的大学生，还要继续留在那个贫穷落后的小地方。为此他感到很苦恼，如何做才能不负如来不负卿！

同样，他说，比起其他同样出身在农村的孩子已经好很多了，至少有个月薪三千的稳定工作，很多农村的孩子都是提前辍学，进厂打螺丝或者失业待家，甚至娶不起农村媳妇，只能通过玩游戏，对抗父母证明自己的存在感，不然要被周围人的流言蜚语的唾沫星子淹死。提到这里甚至还有一丝欣慰。

他说，你不懂，像我这样出身农村的底层孩子，大多数在高考前就已经被淘汰掉了，因为太多穷苦老百姓，觉得读书没有直接去社会上进厂打工来的实在，孩子叛逆不想上学，也不会管太多，更不会觉得人生被毁掉了，相反，早点出去打过工挣钱才是农村人的常态，就这样，穷人的孩子干着穷苦的工作，攒点钱早点结婚生子，一代又一代，恶性循环，也不会觉得有任何不对，因为身边的环境和周围的人大多命运也都是这样。

形成鲜明对比的是，另一个同学，出身在江浙沪独生子，他说，从小只要学习不好，父母就感觉天塌了，因为他父母是很早一批的大学生，虽然他父母也是农村人的孩子，但是是最早一批的大学生，吃到了知识改变命运的红利，甚至不惜任何代价，帮他找资源，托关系，请到了他的老师给他在家补课开小灶，他说他学习一直不好，但是就是这么一路走过来的，甚至他父亲还帮他联系到了211院校的校长，讲到这里，大家意识到差距了吧。他说他学习很差，但被父母一路逼下去读到了研究生。。。毕业后家人关系托底去了某国有五大行，待遇不用多说大家也都懂。

同样，出身农村，学习很差就要回农村继续种地，娶个媳妇生个娃，干着廉价的劳动力，甚至都不知道好日子好工作是什么意思，因为资源和眼界有限，接触不到，也没见过，也无法给孩子形容出来，更没法用言语具体说服叛逆期的孩子。只好为了多挣钱去大城市，离开家人，最后挣点钱回到家了，孩子不理解，继续叛逆，等到了懂事的年纪，已经没有机会翻身了。这里声明：并不是我歧视农村，农村环境好，农村人淳朴，农村土地辽阔，除了经济医疗交通教育不发达，农家乐也非常有趣。

别的行业咱不敢说，至少计算机行业对比传统行业，给了穷人一次走向小康的机会，但这种机会也不会一直都有，互联网寒冬的背景下，即使选择了计算机专业，大多数底层出身的孩子也无法真正的跨越阶层，因为那个时代的红利，已经褪去了。。。

最近看到了一条新闻，说曾经在衡水中学的高考状元，出身农村，声称自己是“乡下的土猪拱了城里的白菜”，报考了浙大计算机专业，三年过后了，这位高考状元却迷茫了，因为他对计算机专业并没有兴趣，当初仅仅因为觉得这个行业高薪才报名的，但是行业在变化，在这个时代下，计算机行业已经发展迅速，没有了昨日的如日中天，相反，他的眼里没有光，他厌倦了这种一天都坐在电脑面前的工作，但是未来何去何从，他依然迷茫，他只知道学习高考，却没有好好规划自己的人生，没有认真思考自己的定位，不懂得人生价值，只知道脱离贫苦。这点也许是大多数底层出身孩子的迷茫吧！

回过神来，今年高考，如果再给你一次机会，你还会像曾经一样，没有把高考当成唯一一次公平翻身的机会吗？寒门贵子想跨越阶层到底有多难？大多数人的机会，也许就这么一次吧。

前言

大家好，我是你不会困，写代码就不会困，今天分享的是总算体会到jsx写法为啥灵活

什么是jsx写法？

当谈到JavaScript中的JSX写法时，人们往往会想到React和Vue这样的流行前端框架。JSX作为一种在JavaScript中编写类似于HTML的语法，为前端开发者提供了更灵活和直观的方式来构建用户界面。

JSX的灵活性体现在多个方面。首先，JSX允许开发者在JavaScript中嵌入HTML标记，使得代码更易读和维护。通过使用JSX，开发者可以在同一个文件中编写JavaScript逻辑和界面布局，而无需频繁切换不同的文件。这种混合编程风格提高了开发效率，同时也方便了代码的组织和调试。

其次，JSX支持在标记中使用JavaScript表达式，这使得动态生成界面变得更加简单。开发者可以在JSX中直接使用JavaScript变量、函数调用和逻辑控制语句，从而动态地渲染页面内容。这种灵活性使得开发者能够根据不同的数据状态和条件来动态展示内容，提升了用户体验。

另外，JSX还支持在标记中使用循环和条件语句，比如map函数和条件渲染，从而实现列表展示、条件展示等常见的UI需求。这种功能使得开发者可以更方便地处理复杂的UI逻辑，同时简化了代码的编写和维护。

此外，JSX的组件化特性也为前端开发带来了很多好处。通过将UI拆分成独立的组件，开发者可以更好地组织和管理代码，提高代码的重用性和可维护性。JSX中的组件可以嵌套使用，形成复杂的UI结构，同时每个组件可以单独管理自己的状态和逻辑，使得代码更加清晰和可扩展。

今天在开发的时候发现，这两个即可开启总计列

show-summary

:summary-method="getSummaries"

但是产品的需求比较麻烦，需要渲染多行，查了相关的文档，好像没有这种渲染的demo，翻看项目的代码，有一部分代码的实现比较巧妙，使用的是jsx写法，然后就尝试着去实现

要在vue里面使用jsx写法，在script标签使用<script lang="jsx">，即可使用

getSummaries(param) {

      const { columns } = param

      const sums = []

      const nullHtml = '-'

      columns.forEach((column, index) => {

        if (index === 0) {

          sums[index] = '总计'

          return

        }

        if (this.totalSum.summaryReceivableComparisons) {

          sums[index] = (

            <div>

              {this.totalSum.summaryReceivableComparisons.map((item) => (

                <div class='cell-item' key={item.invoiceCurrency}>

                  <p>

                    {this.formatValue(

                      item[column.property],

                      column.property.includes('Ratio')

                        ? 'percentage'

                        : 'thousandth'

                    )}

                  </p>

                </div>

              ))}

            </div>

          )

        } else {

          sums[index] = nullHtml

          return

        }

      })

      return sums

    },

上面的代码使用了map来遍历，将对应的html返回，el-table的总计列即可生效，来应对不同的需求

总结

总的来说，JSX作为JavaScript中的一种扩展语法，为前端开发带来了更灵活、直观和高效的开发体验。通过使用JSX，开发者可以更轻松地构建交互丰富、动态变化的用户界面，同时提高了代码的可读性和可维护性。JSX的灵活性和表现力使其成为现代前端开发中不可或缺的一部分。

前言

2024年9月17日，Java开发者们迎来了期待已久的JDK23版本。

下载地址：jdk.java.net/23/

文档地址：jdk.java.net/23/release-…

为 JDK 21 之后的第一个非 LTS 版本，最终的 12 个 JEP 特性包括：

JEP 455：模式、instanceof 和 switch 中的原始类型（Primitive Types in Patterns, instanceof, and switch，预览）

JEP 466：类文件 API（Class-File API，第二轮预览）

JEP 467：Markdown 文档注释（Markdown Documentation Comments）

JEP 469：Vector API（第八轮孵化）

JEP 471：废弃 sun.misc.Unsafe 中的内存访问方法以便于将其移除（Deprecate the Memory-Access Methods in sun.misc.Unsafe for Removal）

JEP 473：流收集器（Stream Gatherers，第二轮预览）

JEP 474：ZGC：默认的分代模式（ZGC: Generational Mode by Default）

JEP 476：模块导入声明（Module Import Declarations，预览）

JEP 477：隐式声明的类和实例主方法（Implicitly Declared Classes and Instance Main Methods，第三轮预览）

JEP 480：结构化并发（Structured Concurrency，第三轮预览）

JEP 481：作用域值（Scoped Values，第三轮预览）

JEP 482：灵活的构造函数体（: Flexible Constructor Bodies，第二轮预览）

基本上每次JDK的升级，在带来一些新功能的同时，也会提升一些性能。

一些优秀的语法，也能提升开发效率。

除了编程语言升级能提升开发效率之外，一些好的开发工具或者设备，也可以。

2 提升开发效率

显示器可以提升开发效率？

答：是真的。

2.1 屏幕尺寸

在之后的一段时间内，我尝试过一些不同品牌和型号的外接显示器。

常见的显示器的屏幕比是16:9。

而我现在正在用的明基RD280U显示器的屏幕比是3:2。

跟我的笔记本电脑屏幕相比，高度是笔记本电脑的两倍了。

我第一次使用时，就明显感觉到，明基RD240Q显示器的屏幕更高一些，一屏可以多看十几行代码。

在开发过程中，每次滚动屏幕，都可以多看几行代码，如果次数多了，可以多看很多行代码，真的可以提高开发效率。

2.2 专业编程模式

我后来才知道明基RD280U是一个专业的编程显示器，专门给程序员设计的。

屏幕正下方的这个按键，可以调整编程模式，可以优化IDE上代码的显示效果，让代码更加清晰：

2.3 背光灯

我们之前在晚上编程的时候，经常需要打开台灯，才能让屏幕看到更清楚。

为了解决这个问题，明基RD280U提供了Moonhalo背光灯的功能，下面这张图是我在关灯的情况下拍摄的：

可以看到屏幕有黄色的背景灯光。

下面的这张灯光图更直观：

可以让你沉浸在开发中，不被打扰。

3 全方位呵护

明基RD280U显示器使用了莱茵认证护眼技术，实现了：低蓝光、无屏闪的效果。

3.1 护眼模式

在夜间开发，可以切换夜间保护模式：

如果切换成自动模式，当外面环境变亮时，屏幕会自动变暗。当外面环境变暗时，屏幕会自动变暗。

保护我们的眼睛。

智慧蓝光模式是为了减少蓝光对眼睛的刺激，提供更舒适的视觉体验。

我们可以调节让自己眼睛感到舒服的蓝光。

3.2 抗反射面板

当我们的屏幕出现其他的灯光直射时，笔记本电脑的效果是这样的：

代码完全看不清楚。

而明基RD280U显示器，即使遇到强光也能看清代码。

这是我非常喜欢的设计。

4 软件协同

明基RD280U显示器为了方便我们操作，还提供了一个驱动软件：Display Pilot2。

里面包含了画面切换，快速搜索，桌面分区和键盘快速切换功能。

我们可以在电脑上直接控制显示器：

文章前面介绍的这些功能，都可以直接在电脑上通过Display Pilot2进行控制。

比如开启显示器的Moonhalo背光灯。

新增的flow功能可以设置特定时间场景下的一些显示器的参数。

5 总结

本文主要介绍了JDK23的12项新特性，涵盖了语言预览、API增强、性能优化等多个方面，可能会对开发者的工作流程和编程习惯产生深远的影响。

同时也介绍了我正在使用的明基RD280U显示器的一些优秀的功能，比如：屏幕尺寸更大、专业编程模式、Moonhalo背光灯、护眼功能（夜间防护功能、智慧蓝光）、抗反射面板、display pilot2功能，能够提升开发效率和保护我们的眼睛。

非必须项

处理器（CPU）天梯图

显卡（GPU）天梯图

如何选择显示器

选择电脑显示器时，有几个关键因素需要考虑：

根据你的具体需求和预算，综合考虑上述因素，选择最适合你的显示器。 并不是配置越高越好，重点是根据你的显卡和CPU来看，实现极致性价比，需要对应电脑配置能带动的最大区间，比方说 英特尔 i5-12400F（6核心12线程，睿频4.4GHz）+ 华硕DUAL-RTX 4060-8G游戏显卡能带起来的刷星率极限基本就是165Hz左右，那么你配置2K，180Hz的显示器就够用了，当然你有钱也可以整个4K，200+Hz的

关于外围设备（键鼠、耳机、音响等）

这个看个人喜好以及预算来决定吧，比方说有线还是无线，机械还是非机械等等....

不同价位装机性价比清单（根据目前市场上）

装机其实主要花费就在显卡（GPU）和处理器（CPU）上，显卡（GPU）金额占比超过50%比比皆是，处理器（CPU）金额占比一般是在百分之20%~30%，其他配件金额占比20%~30%左右。

如果预算足够建议优先升级显卡

CPU分为盒装和散片，预算充足盒装，预算不足散片也能用

3K推荐

• CPU: Intel 12代酷睿i5 12400F
• 显卡: 华硕DUAL RTX 3050 6G
• 内存: 威刚D4 16GB 3200MHz
• 硬盘: 英睿达 500GB PCI-E 4.0 M.2
• 主板: 圣旗H610M
• 电源: 爱国者额定500W
• 跑分: 107W±
• 合计：3.5K左右

4K极致性价比

4K-6K这个价位其实CPU最佳的就是就是在下图区间 同理可自行对比GPU天梯图

• CPU: 英特尔 i5-12400F（6核心12线程，睿频4.4GHz）
• 显卡: 华硕DUAL-RTX 4060-8G游戏显卡 升级选项: +299元升级至华硕TX-RTX 4060-O8G-GAMING天选白三风扇
• 散热: 动力火车四铜管白色强劲散热器
• 主板: 华硕PRIME B760M-FD4（支持AURA神光同步）
• 内存: 雷克沙DDR4 16GB 3200MHz高频内存
• 硬盘: 雷克沙500GB NVMe PCIe SSD（读速高达3300MB/S）
• 电源: 源之力静音大师额定600W安规3C白色
• 机箱: 动力火车琉璃海景房
• 合计：4K左右

5K极致性价比

6K极致性价比

7K极致性价比

8K极致性价比

1W极致性价比

1W预算以上可能考虑的不单单是配置了，还有外观之类的，可以DIY定制之类的

1.2W极致性价比

1.3w极致性价比

总结下，其实根据CPU、GPU天梯图就可以找到自己的目标区间，其他配置看个人预算来就行，核心就是两大件！如果有装机高手，欢迎留言交流，有不懂的，欢迎提问。后续会根据问题持续补充

Electron实现静默打印小票

静默打印流程

1.渲染进程通知主进程打印

//渲染进程 data是打印需要的数据

window.electron.ipcRenderer.send('handlePrint', data)

2.主进程接收消息,创建打印页面

//main.ts

/* 打印页面 */

let printWindow: BrowserWindow | undefined

/**

 * @Author: yaoyaolei

 * @Date: 2024-06-07 09:27:22

 * @LastEditors: yaoyaolei

 * @description: 创建打印页面

 */

const createPrintWindow = () => {

  return new Promise<void>((resolve) => {

    printWindow = new BrowserWindow({

      ...BASE_WINDOW_CONFIG,

      title: 'printWindow',

      webPreferences: {

        preload: join(__dirname, '../preload/index.js'),

        sandbox: false,

        nodeIntegration: true,

        contextIsolation: false

      }

    })



    printWindow.on('ready-to-show', () => {

      //打印页面创建完成后不需要显示,测试时可以调用show查看页面样式(下面有我处理的样式图片)

      // printWindow?.show()

      resolve()

    })



    printWindow.webContents.setWindowOpenHandler((details: { url: string }) => {

      shell.openExternal(details.url)

      return { action: 'deny' }

    })



    if (is.dev && process.env['ELECTRON_RENDERER_URL']) {

      printWindow.loadURL(`${process.env['ELECTRON_RENDERER_URL']}/print.html`)

    } else {

      printWindow.loadFile(join(__dirname, `../renderer/print.html`))

    }

  })

}



ipcMain.on('handlePrint', (_, obj) => {

   //主进程接受渲染进程消息,向打印页面传递数据

  if (printWindow) {

    printWindow!.webContents.send('data', obj)

  } else {

    createPrintWindow().then(() => {

      printWindow!.webContents.send('data', obj)

    })

  }

})

3.打印页面接收消息，拿到数据渲染页面完成后通知主进程开始打印

<!doctype html>

<html>

<head>

  <meta charset="UTF-8" />

  <title>打印</title>

  <style>

  </style>

</head>



<body>



</body>

<script>

  window.electron.ipcRenderer.on('data', (_, obj) => {

  //这里是接受的消息,处理完成后将html片段放在body里面完成后就可以开始打印了

  //样式可以写在style里,也可以内联

    console.log('event, data: ', obj);

  //这里自由发挥

    document.body.innerHTML = '处理的数据'

  //通知主进程开始打印

    window.electron.ipcRenderer.send('startPrint')

  })

</script>

</html>

这个是我处理完的数据样式,这个就是print.html

4,5.主进程接收消息开始打印,并且通知渲染进程打印状态

ipcMain.on('startPrint', () => {

  //这里如果不指定打印机使用的是系统默认打印机,如果需要指定打印机,

  //可以在初始化的时候使用webContents.getPrintersAsync()获取打印机列表,

  //然后让用户选择一个打印机,打印的时候将打印机名称传过来

  printWindow!.webContents.print(

    {

      silent: true,

      margins: { marginType: 'none' }

      //deviceName:如果要指定打印机传入打印机名称

    },

    (success) => {

      //通知渲染进程打印状态

      if (success) {

        mainWindow.webContents.send('printStatus', 'success')

      } else {

        mainWindow.webContents.send('printStatus', 'error')

      }

    }

  )

})

完毕~

问题描述

公司有个内部项目是用 Electron 来开发的，有个功能需要像浏览器一样加载第三方站点。

本来一切安好，但是某天打开某个站点的链接，导致 整个客户端直接变成了该站点的页面。

这一看就是该站点做了特殊的处理，经排查网页源码后，果然发现了有这么一句代码。

    if (window.top !== window.self) {

      window.top.location = window.location;

    }

翻译一下就是：如果当前窗口不是顶级窗口的话，将当前窗口设置为顶级窗口。

奇怪的是两者不是 跨域 了吗，为什么 iframe 还可以影响顶级窗口。

先说一下我当时的一些解决办法：

后续内容就是一点复盘工作。

场景复现（Web端）

一开始怀疑是客户端的问题，所以我用在纯 Web 上进行了一次对比验证。

这里我们新建两个文件：1.html 和 2.html，我们称之为 页面A 和 页面B。

然后起了两个本地服务器来模拟同源与跨域的情况。

页面A：http://127.0.0.1:5500/1.html

页面B：http://127.0.0.1:5500/2.html 和 http://localhost:3000/2.html

符合同源策略

<body>

  <h1>这是页面A</h1>

  <!-- 这是同源的情况 -->

  <iframe id="iframe" src="http://127.0.0.1:5500/2.html" />

  

  <script>

    iframe.onload = () => {

      console.log('iframe loaded..')

      console.log('子窗口路径', iframe.contentWindow.location.href)

    }

  </script>

</body>

<body>

  <h2>这是页面B</h2>



  <script>

    console.log('page2...')

    console.log(window === window.top)

    console.log('顶部窗口路径', window.top.location.href)

  </script>

</body>

我们打开控制台可以看到 页面A 和 页面B 是可以 互相访问 到对方窗口的路径。

如果这个时候在 页面B 加上文章开头提到的 代码片段，那么显然页面将会发生变化。

跨域的情况

这时候我们修改 页面A 加载 页面B 的地址，使其不符合同源策略。

理所应当的是，两个页面不能够相互访问了，这才是正常的，否则内嵌第三方页面可以互相修改，那就太不安全了。

场景复现（客户端）

既然 Web 端是符合预期的，那是不是 Electron 自己的问题呢？

我们通过 electron-vite 快速搭建了一个 React模板的electron应用，版本为：electron@22.3.27，并且在 App 中也嵌入了刚才的 页面B。

function App(): JSX.Element {

  return (

    <>

      <h1>这是Electron页面</h1>

      <iframe id="iframe" src="http://localhost:3000/2.html"/>

    </>

  )

}

export default App

对不起，干干净净的 Electron 根本不背这个锅，在它身上的表现如同 Web端 一样，也受同源策略的限制。

那么肯定是我的项目里有什么特殊的配置，通过对比主进程的代码，答案终于揭晓。

new BrowserWindow({

    ...,

    webPreferences: {

        ...,

        webSecurity: false // 就是因为它

    }

})

Electron 官方文档 里是这么描述 webSecurity 这个配置的。

webSecurity boolean (可选) - 当设置为 false, 它将禁用同源策略 (通常用来测试网站), 如果此选项不是由开发者设置的，还会把 allowRunningInsecureContent设置为 true. 默认值为 true。

也就是说，Electron本身是有一层屏障的，但当该属性设置为 false 的时候，我们的客户端将会绕过同源策略的限制，这层屏障也就消失了，因此 iframe 的行为表现得像是嵌套了同源的站点一样。

解决方案

把这个配置去掉，确实是可以解决这个问题，但考虑到可能对其他功能造成的影响，只能采取其他方案。

如文章开头提到的，用 webview 替换 iframe。

webview 是 Electron的一个自定义元素（标签），可用于在应用程序中嵌入第三方网页，它默认开启安全策略，直接实现了主应用与嵌入页面的隔离。

因为目前这个需求是仅作展示，不需要与嵌套页面进行交互以及复杂的通信，因此在一开始的开发过程中，并没有使用它，而是直接采用了 iframe。

而 iframe 也能够实现类似的效果，只需要添加一个 sandbox 属性可以解决。

MDN 中提到，sandbox 控制应用于嵌入在 <iframe> 中的内容的限制。该属性的值可以为空以应用所有限制，也可以为空格分隔的标记以解除特定的限制。

如此一来，就算是同源的，两者也不会互相干扰。

总结

这不是一个复杂的问题，发现后及时修复了，并没有造成很大的影响（还好是自己人用的平台）。

写这篇文章的主要目的是为了记录这次事件，让我意识到在平时开发过程中，把注意力过多的放在了 业务、样式、性能等这些看得见的问题上，可能很少关注甚至忽略了 安全 这一要素，以为前端框架能够防御像 XSS 这样的攻击就能安枕无忧。

谨记，永远不要相信第三方，距离产生美。

如有纰漏，欢迎在评论区指出。

写在开头

日常我们在页面中使用特殊字体，一般操作都是直接由前端来全量引入设计师提供的整个字体包即可，具体操作如下：

<template>

  <div class="font">橙某人</div>

</template>



<style scoped>

@font-face {

  font-family: "orange";

  src: url("./orange.ttf");

}

.font {

  font-family: "orange";

}

</style>

很简单吧🤡，但有时应用场景不同，可能需要我们考虑一下性能问题。

一般来说，我们常见的字体包整个是非常大的，小的有几M到十几M，大的可能去到上百M都有，特别是中文类的字体包会相对英文类的要更大一些。

如本文案例，我们仅需在用户输入完后加载对应的字体包即可，这样能避免性能的损耗。

为此，我们需要把整个字体包拆分、细致化、子集化，让它能达到按需引入的效果。

那么这要如何来做这个事情呢？这个方案单单前端可做不了，我们需要配合后端一起，下面就来看看具体的实现过程吧。😗

前端

前端小编用 Vue 来编写，具体如下：

<template>

  <div>

    <input v-model="name" />

    <button @click="handleClick">生成</button>

    <div v-if="showName" class="font">{{ showName }}</div>

  </div>

</template>



<script>

export default {

  data() {

    return {

      name: "",

      showName: "",

    };

  },

  methods: {

    handleClick() {

      // 创建link标签

      const linkElement = document.createElement("link");

      linkElement.setAttribute("rel", "stylesheet");

      linkElement.setAttribute("type", "text/css");

      linkElement.href = `http://localhost:3000?name=${encodeURIComponent(this.name)}`;

      document.body.appendChild(linkElement);

      // 优化显示效果

      setTimeout(() => {

        this.showName = this.name;

      }, 300);

    },

  },

};

</script>



<style>

.font {

  font-family: orange;

  font-size: 50px;

}

</style>

应该都能看懂吧，主要就是生成了一个 <link /> 标签并插入到文档中，标签的请求地址指向我们服务端，至于服务端会返回什么你可以先猜一猜。👻

服务端

服务端小编选择用 Koa2 来编写，你也可以选择 Express 或者 Egg ，甚至 Node 也是可以的，差异不大，具体逻辑如下：

const koa = require("koa2");

const fs = require("fs");

const FontMin = require("fontmin");



const app = new koa();



/** @name 优化，缓存已经加载过的字体包进内存 **/

const fontFamilyMap = {};



/** @name 加载字体包 **/

function loadFontLibrary(fontPath, fontFamily) {

  if (fontFamilyMap[fontFamily]) return fontFamilyMap[fontFamily];

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

    fs.readFile(fontPath, (error, file) => {

        if (error) {

          reject(new Error(error.message));

        } else {

          fontFamilyMap[fontFamily] = file;

          resolve(file);

        }

    });

  });

}



app.use(async (ctx) => {

  const { name } = ctx.query;

  // 设置返回文件类型

  ctx.set("Content-Type", "text/css");



  const fontPath = "./font/orange.ttf";

  const fontFamily = "orange";

  if (!fs.existsSync(fontPath)) return (ctx.body = "字体包读取失败");



  const fontMin = new FontMin();

  const fontFile = await loadFontLibrary(fontPath, fontFamily);

  fontMin.src(fontFile);



  const getFontCSS = () => {

    return new Promise((resolve) => {

      fontMin

        .use(FontMin.glyph({ text: name }))

        .use(FontMin.css({ base64: true, fontFamily }))

        .run((error, files) => {

          if (error) {

            console.log("error", error.message);

          } else {

            const fontContent = files?.[1]?.contents;

            resolve(fontContent);

          }

      });

    });

  };



  const fontCSS = await getFontCSS();



  ctx.body = fontCSS;

});



app.listen(3000);



console.log("服务器开启: http://localhost:3000/");

我们主要是采用了 Fontmin 库来完成整个字体包的按需加载功能，这个库是第一个纯 JavaScript 字体子集化方案。

可能有后端是 Java 或者其他技术栈的小伙伴，你们也不用担心，据小编和公司后端同事了解，不同技术栈也是有对应的库可以解决的，需要的可以自行查查看。

至此，本篇文章就写完啦，撒花撒花。

希望本文对你有所帮助，如有任何疑问，期待你的留言哦。

老样子，点赞+评论=你会了，收藏=你精通了。

iframe（Inline Frame）是一种在网页中嵌套其他网页的 HTML 元素。通过 iframe，开发者可以在一个页面中加载另一个页面的内容，提升用户体验和功能性。下面将详细探讨 iframe 的原理、使用场景以及注意事项，并提供相应的代码示例。

一、iframe 的原理

iframe 是一种 HTML 标签，其基本语法如下：

<iframe src="https://example.com" width="600" height="400" frameborder="0"></iframe>

• src：指定要加载的网页地址。


• width 和 height：定义 iframe 的宽度和高度。


• frameborder：控制边框显示（在 HTML5 中不推荐使用）。

当浏览器遇到 iframe 标签时，会发起一个独立的网络请求来加载指定的 URL。这使得嵌入的内容在主文档之外独立渲染。

二、使用场景

三、注意点

```http

X-Frame-Options: DENY

```

四、示例代码

以下是一个综合示例，展示了如何使用 iframe 加载一个 YouTube 视频并应用响应式设计：

<!DOCTYPE html>

<html lang="en">

<head>

    <meta charset="UTF-8">

    <meta name="viewport" content="width=device-width, initial-scale=1.0">

    <title>Iframe Example</title>

    <style>

        .responsive-iframe {

            position: relative;

            padding-bottom: 56.25%; /* 16:9 Aspect Ratio */

            height: 0;

            overflow: hidden;

        }

        .responsive-iframe iframe {

            position: absolute;

            top: 0;

            left: 0;

            width: 100%;

            height: 100%;

        }

    </style>

</head>

<body>



<h1>嵌入 YouTube 视频</h1>

<div class="responsive-iframe">

    <iframe src="https://www.youtube.com/embed/VIDEO_ID" frameborder="0" allowfullscreen></iframe>

</div>



</body>

</html>

结论

iframe 是一种强大的网页嵌入技术，能够增强网页功能和用户体验。在使用时，需要充分考虑安全性、性能和跨域问题，以确保良好的用户体验。通过合理配置和使用，iframe 可以为网页增加更多的互动性和功能性。

---09/19ヾ(￣▽￣)ByeBye

1、背景

与后端对接口时，看到有一个get请求的接口，它的参数是放在body中的

******get请求参数可以放在body中？？

随即问了后端，后端大哥说在postman上是可以的，还给我看了截图

可我传参怎么也调不通！

下面就来探究到底是怎么回事

2、能否发送带有body参数的get请求

项目中使用axios来进行http请求，使用get请求传参的基本姿势：

// 参数拼接在url上

axios.get(url, {

  params: {}

})

如果想要将参数放在body中，应该怎么做呢？

查看axios的文档并没有看到对应说明，去github上翻看下axios源码看看

在lib/core/Axios.js文件中

可以看到像delete、get、head、options方法，它们只接收两个参数，不过在config中有一个data

熟悉的post请求，它接收的第二个参数data就是放在body的，然后一起作为给this.request作为参数

所以看样子get请求应该可以在第二个参数添加data属性，它会等同于post请求的data参数

顺着源码，再看看lib/adapters/xhr.js，上面的this.request最终会调用这个文件封装的XMLHttpRequest

export default isXHRAdapterSupported && function (config) {

  return new Promise(function dispatchXhrRequest(resolve, reject) {

    let requestData = config.data



    // 将config.params拼接在url上

    request.open(config.method.toUpperCase(), 

                 buildURL(fullPath, config.params, config.paramsSerializer), true);

    

    // 省略若干代码

    ...



    // Send the request

    request.send(requestData || null);

  });

}

最终会将data数据发送出去

所以只要我们传递了data数据，其实axios会将其放在body发送出去的

2.1 实战

本地起一个koa服务，弄一个简单的接口，看看后端能否接收到get请求的body参数

router.get('/api/json', async (ctx, next) => {

	console.log('get请求获取body： ', ctx.request.body)

  

	ctx.body = ctx.request.body

})



router.post('/api/json', async (ctx, next) => {

	console.log('post请求获取body： ', ctx.request.body)



	ctx.body = ctx.request.body

})

为了更好地比较，分别弄了一个get和post接口

前端调用接口：

const res = await axios.get('/api/json', {

  data: {

    id: 1,

    type: 'GET'

  }

})





const res = await axios.post('/api/json', {

  data: {

    id: 2,

    type: 'POST'

  }

})

console.log('res--> ', res)

在axios的send处打一个断点

可以看到数据已经被放到body中了

后端已经接收到请求了，但是get请求无法获取到body！

结论：

• 前端可以发送带body参数的get请求，但是后端接收不到


• 这就是接口一直调不通的原因

3、这是为何呢？

我们查看WHATGW标准，在XMLHttpRequest中有这么一个说明：

大概意思：如果请求方法是GET或HEAD ，那么body会被忽略的

所以我们虽然传递了，但是会被浏览器给忽略掉

这也是为什么使用postman可以正常请求，但是前端调不通的原因了

因为postman并没有遵循WHATWG的标准，body参数没有被忽略

3.1 fetch是否可以？

fetch.spec.whatwg.org/#request-cl…

答案：也不可以，fetch会直接报错

总结

新年快乐！在这个快速发展的前端世界里，咱们工程师面临的挑战也是一个接一个。今天，咱们就来聊聊前端实时通信这个话题。

想想看，你在使用那些传统的HTTP客户端时，比如axios，是否遇到过这样的问题：与React、Vue等框架的结合不够紧密，导致开发效率低下；在性能方面表现不佳，尤其是在处理频繁或重复的请求时；还有那略显臃肿的体积，以及混乱的响应数据类型定义？

哎呀妈呀，这些问题听着就让人头大。但别急，有个叫做alovajs的工具，可能会让你眼前一亮。

alovajs是一个轻量级的请求策略库，它不仅提供了与axios相似的API设计，让你能更快上手，还解决了上述的那些问题。它如何解决？咱们来一探究竟。

首先，alovajs能够与UI框架深度融合，自动管理请求相关的数据。这意味着你在Vue或React等框架中使用alovajs时，不再需要手动创建和维护请求状态，大大提高了开发效率。

其次，alovajs默认开启了内存缓存和请求共享，这些功能可以在提高请求性能的同时，提升用户体验并降低服务端的压力。比如，当你实现一个列表页，用户点击列表项进入详情页时，alovajs可以智能地使用缓存数据，避免不必要的重复请求。

最后，alovajs的体积只有4kb+，仅是axios的30%左右，而且它提供了更加直观的响应数据TS类型定义，对于重度使用Typescript的同学来说，这绝对是个福音。

说了这么多，是不是有点心动了？如果你对alovajs感兴趣，可以访问它的官网查看更多详细信息：alovajs官网。也欢迎你在评论区分享你对alovajs的看法和使用经验，让我们一起交流学习吧！
有任何问题，你可以加入以下群聊咨询，也可以在github 仓库中发布 Discussions，如果遇到问题，也请在github 的 issues中提交，我们会在最快的时间解决。

早上刚来，就看到仓库那边不停发消息说，我们的某个功能用不了了。赶紧放下早餐加紧看。

原来是调的一个三方接口报错了：

javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target

	at sun.security.ssl.Alert.createSSLException(Alert.java:131)

	at sun.security.ssl.TransportContext.fatal(TransportContext.java:353)

	at sun.security.ssl.TransportContext.fatal(TransportContext.java:296)

	at sun.security.ssl.TransportContext.fatal(TransportContext.java:291)

	at sun.security.ssl.CertificateMessage$T12CertificateConsumer.checkServerCerts(CertificateMessage.java:652)

	at sun.security.ssl.CertificateMessage$T12CertificateConsumer.onCertificate(CertificateMessage.java:471)

	at sun.security.ssl.CertificateMessage$T12CertificateConsumer.consume(CertificateMessage.java:367)

	at sun.security.ssl.SSLHandshake.consume(SSLHandshake.java:376)

	at sun.security.ssl.HandshakeContext.dispatch(HandshakeContext.java:444)

	at sun.security.ssl.HandshakeContext.dispatch(HandshakeContext.java:422)

	at sun.security.ssl.TransportContext.dispatch(TransportContext.java:183)

	at sun.security.ssl.SSLTransport.decode(SSLTransport.java:154)

	at sun.security.ssl.SSLSocketImpl.decode(SSLSocketImpl.java:1279)

	at sun.security.ssl.SSLSocketImpl.readHandshakeRecord(SSLSocketImpl.java:1188)

	at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:401)

	at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:373)

查看原因：

由于JVM默认信任证书不包含该目标网站的SSL证书，导致无法建立有效的信任链接。

奥...原来是他们把接口从http改为了https,导致我们获取数据报错了。再看看他们的证书，奥...新的。

好了，看看我们的逻辑，这其实是一个获取对方生成的PDF文件的接口

PdfReader pdfReader = new PdfReader(url);

url就是他们给的链接，是这行代码报的错。这时候，开始研究，在网上扒拉，找到了初版方案

尝试1

写一个程序专门获取安全证书，这代码有点长，全贴出来影响阅读。我给扔我hithub上了github.com/lukezhao6/I… 将这个文件贴到本地，执行javac InstallCert.java将其进行编译

编译完长这样：

然后再执行java InstallCert http://www.baidu.com （这里我们用百度举例子，实际填写的就是你想要获取证书的目标网站）

报错不用怕，因为它会去检查目标服务器的证书，如果出现了SSLException,表示证书可能存在问题，这时候会把异常信息打印出来。

在生成的时候需要输入一个1

这样，我们需要的证书文件就生成好了

这时候，将它放入我们本地的 jdk的lib\security文件夹内就行了

重启，这时候访问是没有问题了。阶段性胜利。

但是，但是。一顿操作下来，对于测试环境的docker，还有生产环境貌似不能这么操作。 放这个证书文件比较费事。

那就只能另辟蹊径了。

尝试2

搜到了，还有两种方案。

1.通过System.setProperty("javax.net.ssl.trustStore", "你的jssecacerts证书路径");

2.程序启动命令-Djavax.net.ssl.trustStore=你的jssecacerts证书路径 -Djavax.net.ssl.trustStorePassword=changeit

我尝试了第一种，System.setProperty可以成功，但是读不到文件，权限什么的都是ok的。
检查了蛮多地方

• 路径格式问题


• 文件是否存在


• 文件权限


• 信任库密码


• 系统属性优先级

貌似都是没问题的，但肯定又是有问题的，因为没起作用。但是想着这样的接口有4个，万一哪天其他三个也改了，我又得来一遍。所以就算研究出来了，还是不能稳坐钓鱼台。有没有一了百了的方法嘞。

尝试3

还真找到了：这个错是因为对方网站的证书不被java信任么，那咱不校验了，直接全部信任。这样就算其他接口改了，咱也不愁。而且这个就是获取pdf，貌似安全性没那么重。那就开搞。

代码贴在了下方，上边的大概都能看懂吧，下方的我加了注释。

URL console = new URL(url);

HttpURLConnection conn = (HttpURLConnection) console.openConnection();

if (conn instanceof HttpsURLConnection)  {

    SSLContext sc = SSLContext.getInstance("SSL");

    sc.init(null, new TrustManager[]{new TrustAnyTrustManager()}, new java.security.SecureRandom());

    ((HttpsURLConnection) conn).setSSLSocketFactory(sc.getSocketFactory());

    ((HttpsURLConnection) conn).setHostnameVerifier(new TrustAnyHostnameVerifier());

}

conn.connect();

InputStream inputStream = conn.getInputStream();

PdfReader pdfReader = new PdfReader(inputStream);

inputStream.close();

conn.disconnect();

private static class TrustAnyTrustManager implements X509TrustManager {

    //这个方法用于验证客户端的证书。在这里，方法体为空，表示不对客户端提供的证书进行任何验证。

    public void checkClientTrusted(X509Certificate[] chain, String authType) throws CertificateException {

    }

    //这个方法用于验证服务器的证书。同样，方法体为空，表示不对服务器提供的证书进行任何验证。

    public void checkServerTrusted(X509Certificate[] chain, String authType) throws CertificateException {

    }

    //这个方法返回一个信任的证书数组。在这里，返回空数组，表示不信任任何证书，也就是对所有证书都不做任何信任验证。

    public X509Certificate[] getAcceptedIssuers() {

        return new X509Certificate[]{};

    }

}

//这个方法用于验证主机名是否可信。在这里，无论传入的主机名是什么，方法始终返回 true，表示信任任何主机名。这就意味着对于 SSL 连接，不会对主机名进行真实的验证，而是始终接受所有主机名。

private static class TrustAnyHostnameVerifier implements HostnameVerifier {

    public boolean verify(String hostname, SSLSession session) {

        return true;

    }

}

解决了解决了，这样改算是个比较不错的方案了吧。

1 问题背景

顾问反馈大屏在反复切换的过程中，页面会出现白屏，导致后续的操作无法进行，只能通过刷新页面才能恢复正常。

2 问题复现

测试同事经过几分钟的快速切换导航后，复现了，报错了如下内容

问题如果复现了，其实就解决了一半了

3 查找问题

经过复现后，发现除了上面的报错，每当页面崩溃前，chrome总会有下方的warning。然后基于cesium封装的地图就会崩溃。

翻译成中文：警告：目前有了太多激活的webgl上下文，最早的上下文将会丢失

4 排查问题

经过和地图组的人沟通，得到一个结论WebGL一个页面上最多有16个实例

• 怀疑echarts在下方菜单切换过程中，没有进行销毁

检查了代码中的echats的页面在销毁的时候，发现都进行了dispose，排除了这个的原因

• 怀疑起echarts的3d的饼状图
  之前设计师设计了一个3d的饼状图，参考了 3d柄图环图，一个页面上有多这个组件。
  效果如下：

5 锁定组件进行验证

加入了类似的代码，进行验证后解决了此问题

6 总结

const canvasArr = myChart.getDom().getElementsByTagName('canvas');

for(let i=0; i<canvasArr.length; i++){

    canvasArr[i].getContext('webgl').getExtension('WEBGL_lose_context').loseContext()

}

7 参考文档

• github.com/ecomfe/echa…