prop_c.setProperty(key, value);

public synchronized V put(K key, V value) {

    // Make sure the value is not null

    if (value == null) {

        throw new NullPointerException();

    }

    }

role.haveRole("ADMIN_USE")

3. 日志打印居然sout和log混合双打

先不说双打的事，对于上图这个，应该输出包括堆栈信息，不然定位问题很麻烦，有人可能会说e.getMessage()最好，可是生产问题看多了发现还是打堆栈好；还有如果不是定向返回信息，仅仅是记录日志，完全没必要catch多个异常，一个Exception足够了，不知道原作者这么写的意思是啥；还是就是打印日志要用logger，用sout打印在控制台，那我日志文件干啥；

4.提交的代码没有技术经理把关，下发生产包是个人就可以发导致生产环境代码和本地代码或者数据库数据出现不一致的现象，数据库数据的同步是生产最容易忘记执行的一个事情；比如我的这家公司上传文件模板变化了，但是没同步，导致出问题时开发环境复现问题真是麻烦；

5.随意更改生产数据库，出不出问题全靠开发的职业素养；

6.Maven依赖的问题，Maven引pom，而pom里面却是另一个pom文件，没有生成的jar供引入，是的，我们可以在dependency里加上

<type>pom

来解决这个问题，但是公司内的，而且实际也是引入这个pom里面的jar的，我实在不知道这么做的用意是什么，有谁知道；求教 

以上这些都是我最近一家公司出现的问题，除了默默接受还能怎么办；

那有什么优点呢：

解决之道

怎么解决这些问题呢，首先对于现有的新项目或升级的项目来说，spring的application.xml/yml 完全可以写我们的配置，开发环境没必要整外部文件，如果是生产环境我们可以在脚本或启动命令添加 nohup java -Dfile.encoding=UTF-8 -Dspring.config.location=server/src/main/config/application.properties -jar xxx.jar & 来告诉jar包引哪里的配置文件；也可以加上动态配置，都很棒的，

其次就是规范代码，养成良好的规范，跟着节奏，不要另辟蹊径；老老实实的，如果原项目上迭代，不要动源代码，追加即可，没有时间去重构的；

我也曾是个快乐的童鞋，也有过崇高的理想，直到我面前堆了一座座山，脚下多了一道道坑，我。。。。。。！

Hermes 是一款由 Facebook 开源的轻量级 JavaScript 引擎，专门针对 React Native 应用进行了优化。与传统的 JavaScript 引擎（例如 JavaScriptCore 和 V8）相比，Hermes 具有以下优势：

启动时间更快： Hermes 使用预编译字节码(AOT)，而不是即时编译（JIT），这可以显著缩短应用的启动时间。

更小的内存占用： Hermes 的体积小巧，占用内存更少，这对于移动设备尤为重要。

更小的应用包大小： 由于 Hermes 的体积小巧，因此可以减小 React Native 应用的包大小。

高效的性能的原因

先看下面这幅图:

Hermes Engine 的设计初衷是为了优化 React Native 应用的性能。它通过对 JavaScript 代码的提前编译，将其转化为字节码，从而减少了运行时的解析时间。这种预编译机制使得应用启动速度显著提升，用户体验更加流畅。

在 CPU 利用率方面，Hermes 也有显著的优势。
通过优化 JavaScript 执行和垃圾回收过程，Hermes 提供了更快的启动时间和更低的内存占用。研究表明，使用 Hermes 的应用在性能上有显著提升，用户体验更加流畅

内存占用和包大小优化

Hermes 采用了优化的内存管理机制，如内存池和高效的垃圾回收算法，能够减少应用在运行时的内存占用。这对于资源受限的移动设备尤为关键。使用 Hermes 编译的应用包体积通常更小。这对于需要快速下载安装的应用很有优势，也有助于提高应用在应用商店的排名。上图就是 Stock RN 应用基于 Hermes 引擎的内存优化后的实际效果。

良好的兼容性

Hermes 提供了强大的调试工具，帮助开发者快速定位和解决问题。其集成的调试功能使得开发者能够实时监控应用的性能，及时发现并修复潜在的性能瓶颈。
Hermes 得到了 Facebook 和开源社区的广泛支持，拥有丰富的文档和活跃的开发者社区。开发者可以轻松获取资源和支持，促进了 Hermes 的快速发展和普及。

一些小众第三方库不支持 Hermes 引擎

虽然，大多数比较有名的第三方库都是支持 Hermes引擎的，但是有一个小小的问题，有些比较小众的第三方库，是不支持 hermes 引擎的，这个时候，你可需要想办法自己改写下这个第三方库，或者给作者提建议。
如，腾讯云 cos ，React Native 的库，就是不支持 Hermes 引擎的。相关issue 在这里：

github.com/TencentClou…

不过，对于这个问题，你完全可以使用 restful api 呀，所以，解决问题的方式太多了，不要因为一个小众的三方库而放弃恐怖的性能提升，多少有点不值当。

实际应用案例

许多知名应用已经开始采用 Hermes Engine，以提升其性能。例如，Facebook 和 Instagram 的部分功能已成功迁移至 Hermes，用户反馈显示应用的启动时间和流畅度均有显著改善。这些成功案例进一步验证了 Hermes 的强大实力。

如何用上Hermes 引擎

如果你在使用 Expo 做移动端跨端研发，那么恭喜你，默认就是使用的 Hermes 引擎，无需任何配置，如果你想显式配置，也无妨，甚至你可以指定 ios 使用jsc 引擎。

{

  "expo": {

    "jsEngine": "hermes",

    "ios": {

      "jsEngine": "jsc"

    }

  }

}

如果你使用的是 React Native 0.70 或更高版本，则 Hermes 引擎将默认启用。如果你使用的是较早版本的 React Native，则可以按照 React Native 文档 中的说明启用 Hermes 引擎。配置简单的就啰嗦。小伙伴们，React Native 要吊打 Flutter了 吗？拍拍砖？

给前端以福利，给编程以复利。大家好，我是大家的林语冰。

00. 观前须知

在 Web 开发领域，Vite 如今已如雷贯耳。

自 2020 年 4 月发布以来，Vite 的人气蒸蒸日上。目前 Vite 在 GitHub 上的收藏数量已超过 64k，每周下载量超过 1200 万次，现在为 Nuxt、Remix、Astro 等大多数开源框架提供支持。

尽管众口嚣嚣，我们意识到许多开发者可能仍然不熟悉 Vite 是什么鬼物，也不熟悉 Vite 在推动现代 Web 框架和工具的开发中扮演的重要角色。

在本文中，我们将科普 Vite 的知识储备，以及 Vite 如何在短短几年后发展成为现代 Web 的重量级角色。

免责声明

本文属于是语冰的直男翻译了属于是，略有删改，仅供粉丝参考。英文原味版请传送 What is Vite (and why is it so popular)?。

01. Vite 是什么鬼物？

Vite 的发音为 /vit/，在法语中是“快速”或“迅捷”的意思，不得不说 Vite 名副其实。

简而言之，Vite 是一种现代 JS 构建工具，为常见 Web 模式提供开箱即用的支持和构建优化，兼具 rollup 的自由度和成熟度。

Vite 还与 esbuild 和原生 ES 模块强强联手，实现快速无打包开发服务器。

Vite 是由“Vue 之父”尤雨溪（Evan You）构思出来的，旨在通过减少开发者在启动开发服务器和处理文件编辑后重载时遭遇的性能瓶颈，简化打包过程。

02. Vite 的核心特性

运行 Vite 时，你会注意到的第一个区别在于，开发服务器会即时启动。

这是因为，Vite 采用按需方法将你的应用程序提供给浏览器。Vite 不会首先打包整个源码，而是响应浏览器请求，将你编写的模块即时转换为浏览器可以理解的原生 ESM 模块。

Vite 为 TS、PostCSS、CSS 预处理器等提供开箱即用的支持，且可以通过不断增长的插件生态系统进行扩展，支持所有你喜欢的框架和工具。

每当你在开发期间更改项目中的任意文件时，Vite 都会使用应用程序的模块图，只热重载受影响的模块（HMR）。这允许开发者预览他们的更改，及其对应用程序的影响。

Vite 的 HMR 速度惊人，可以让编辑器自动保存，并获得类似于在浏览器开发工具中修改 CSS 时的反馈循环。

Vite 还执行 依赖预构建（dependency pre-bundling）。在开发过程中，Vite 使用 esbuild 来打包你的依赖并缓存，加快未来服务器的启动速度。

此优化步骤还有助于加快 lodash 等导出许多迷你模块的依赖的加载时间，因为浏览器只加载每个依赖的代码块（chunk）。这还允许 Vite 在依赖中支持 CJS 和 UMD 代码，因为它们被打包到原生 ESM 模块中。

当你准备好部署时，Vite 将使用优化的 rollup 设置来构建你的应用程序。Vite 会执行 CSS 代码分割，添加预加载指令，并优化异步块的加载，无需任何配置。

Vite 提供了一个通用的 rollup 兼容插件 API，适用于开发和生产，使你可以更轻松地扩展和自定义构建过程。

03. Vite 的优势

使用 Vite 有若干主要优势，包括但不限于：

03-1. 开源且独立

Vite 由开源开发者社区“用爱发电”，由来自不同背景的开发者团队领导，Vite 核心仓库最近贡献者数量已突破 900 人。

Vite 得到积极的开发和维护，不断实现新功能并解决错误。

03-2. 本地敏捷开发

开发体验是 Vite 的核心，每次点击保存时，你都能感受到延迟。我们常常认为重载速度是理所当然的。

但随着您的应用程序增长，且重载速度逐渐停止，你将感恩 Vite 几乎能够保持瞬间重载，而无论应用程序大小如何。

03-3. 广泛的生态系统支持

Vite 的方案人气爆棚，大多数框架和工具都默认使用 Vite 或拥有一流的支持。通过选择使用 Vite 作为构建工具，这些项目维护者可以在它们之间共享一个统一基建，且随着时间的推移共同改良 Vite。

因此，它们可以花更多的时间开发用户需要的功能，而减少重新造轮子的时间。

03-4. 易于扩展

Vite 对 rollup 插件 API 的押注得到了回报。插件允许下游项目共享 Vite 核心提供的功能。

我们有很多高质量的插件可供使用，例如 vite-plugin-pwa 和 vite-imagetools。

03-5. 框架构建难题中的重要角色

Vite 是现代元框架构建的重要组成部分之一，这是一个更大的工具生态系统的一部分。

Volar 提供了在代码编辑器中为 Vue、MDX 和 Astro 等自定义编程语言构建可靠且高性能的编辑体验所需的工具。Volar 允许框架向用户提供悬停信息、诊断和自动补全等功能，并共享 Volar 作为为它们提供支持的通用基建。

另一个很好的例子是 Nitro，它是一个服务器工具包，用于创建功能齐全的 Web 服务器，开箱即用地支持每个主要部署平台。Nitro 是一个与框架无关的库 UnJS 的奇妙集合的一部分。

04. Vite 的未来

在最近的 ViteConf 大会的演讲中，尤雨溪表示，虽然 Vite 取得了巨大进展，但仍面临一些已知的问题和挑战。

Vite 目前使用 rollup 进行生产构建，这比 esbuild 或 Bun 等原生打包器慢得多。

Vite 还尽可能减少开发和生产环境之间的不一致性，但考虑到 rollup 和 esbuild 之间的差异，某些不一致性无法避免。

尤雨溪现在领导一个新团队开发 rolldown，这是一个基于 Rust 的 rollup 移植，在 “JS 氧化编译器 OXC”之上构建了最大的兼容性。

这个主意是用 rolldown 替代 Vite 中的 rollup 和 esbuild。Vite 将拥有一个单独基建，兼具 rollup 的自由度和 esbuild 的速度，消除不一致性，使代码库更易于维护，并加快构建时间。

rolldown 目前处于早期阶段，但已经显示出有希望的结果。rolldown 现已开源，rolldown 团队正在寻找贡献者来辅助实现这一愿景。

与此同时，Vite 团队在每个版本中不断改良 Vite。这项工作从上游的为 Vitest 和 Nuxt Dev SSR 提供​​动力的引擎 vite-node 开始，现已发展成为框架作者对 Vite API 的完整修订版。

新版 Environment API 预计在 Vite 6 中发布，这将是自 Vite 2 发布以来 Vite 最大的变化之一。这将允许在任意数量的环境中通过 Vite 插件管道运行代码，解锁对 worker、RSC 等的一流支持。

Vite 正在开辟一条前进的道路，并迅速成为 JS 生态系统事实上的构建工具。

参考文献

粉丝互动

本期话题是：如何评价人气爆棚的 Vite，你最喜欢或期待 Vite 的哪个功能？你可以在本文下方自由言论，文明科普。

欢迎持续关注“前端俱乐部”，给前端以福利，给编程以复利。

坚持阅读的小伙伴可以给自己点赞！谢谢大家的点赞，掰掰~

先赞后看，南哥助你Java进阶一大半

geeksforgeeks.org官网给出了Facebook评论系统的高级设计图，Facebook的评论竟然是支持实时刷新的。也就是说用户不用刷新帖子，只要帖子有新的评论就会自动推送到用户端，这里Facebook使用的便是每天在全球有超过20亿设备在使用的WebSocket技术。

我是南哥，一个Java学习与进阶的领路人。

相信对你通关面试、拿下Offer进入心心念念的公司有所帮助。

⭐⭐⭐本文收录在《Java学习/进阶/面试指南》：https://github/JavaSouth

精彩文章推荐

• 面试官没想到一个ArrayList，我都能跟他扯半小时


• 《我们一起进大厂》系列-Zookeeper基础


• 再有人问你WebSocket为什么牛逼，就把这篇文章发给他！


• 全网把Kafka概念讲的最透彻的文章，别无二家


• 可能是最漂亮的Java I/O流详解

1. 评论系统设计

1.1 评论表如何设计

评论系统的表要这么设计，每条评论的id标识要么是根评论id、要么是回复评论id。如果是根评论，那parent_comment_id字段就为空；而回复别人的评论，parent_comment_id字段指向根评论id。

CREATE TABLE `comments` (

  `comment_id` INT AUTO_INCREMENT PRIMARY KEY,  -- 评论唯一ID

  `user_id` INT NOT NULL,                       -- 用户ID

  `content` TEXT NOT NULL,                      -- 评论内容

  `parent_comment_id` INT DEFAULT NULL,         -- 如果是回复，则指向原始评论ID

  `post_id` INT NOT NULL,                       -- 被评论的帖子或内容ID

  `like_count` INT DEFAULT 0,                   -- 点赞数量

  `create_time` TIMESTAMP DEFAULT CURRENT_TIMESTAMP,  -- 评论创建时间

);

我们还要给评论加上点赞数，南哥给大家看看抖音的评论设计。

用户可以给每条评论打上点赞，所以我们应该再设计一个点赞表。其实抖音这种评论模式叫嵌套式评论结构，嵌套式评论注重用户对话交流，用户可以很方便地查看一个对话里的所有回复，我们看下抖音评论里有着展开10条回复的按钮。

其他评论模式设计还有平铺式评论结构，像微信朋友圈，或者Github的issue都是平铺式评论结构。这种设计更适合用户关注重点在发布的内容本身，而不是对话。大家有没发现微信朋友圈的特点是对话比较少点，点赞反而更多。

来看看点赞表设计。

CREATE TABLE `comment_likes` (

  `user_id` INT NOT NULL,                       -- 点赞用户ID

  `comment_id` INT NOT NULL,                    -- 被点赞的评论ID

  `liked_timeMESTAMP DEFAULT CURRENT_TIMESTAMP,  -- 点赞时间

);

1.2 评论数据存储

抖音每天产生视频几百万、上千万，每个视频的评论高的甚至有上万条评论，要怎么样的数据查询设计才能支持每天亿级的评论？

南哥先假设我们用MySQL作为实际的数据存储，这么高的并发肯定不能让查询直接冲击数据库 。再分库分表也是没用。

Elasticsearch官网这么宣传它的产品：

Elasticsearch 极其快速，快到不可思议

当用户发表评论时，我们首先把评论写入MySQL数据库，再使用异步机制把评论同步到Elasticsearch中。当在用户请求查询评论时，优先从 Elasticsearch 中进行查询。

// 评论存储到MySQL、Elasticsearch

public void storeComment(Comment comment) {

    // 将评论存入 MySQL

    commentRepository.save(comment);



    // 异步将评论同步到 Elasticsearch

    CompletableFuture.runAsync(() -> {

        elasticsearchService.indexComment(comment);

    });

}

1.3 事务控制

大家想一想以上设计，有哪些需要进行事务控制？

例如comment_likes点赞表的插入和comment评论表的更新，用户为某一个评论点赞，会在comment_likes表插入一条新记录，同时会更新comment表的点赞数量。

但是，从用户需求的角度来看，用户并不在意点赞数的强一致性和实时性，这点不使用事务也可以接受。

我曾经和老外程序员在论坛聊过，他说他们的点赞后端分布式服务用的本地缓存，即使每一个服务的本地缓存相对不太一致，对系统完全没有影响。

// 事务控制

@Transactional

public void likeComment(int commentId, int userId) {

    // 插入一条点赞记录

    commentLikesRepository.insert(userId, commentId);



    // 更新评论表中的点赞数量，假设有一个专门的方法来处理这个更新

    commentRepository.incrementLikeCount(commentId);

}

1.4 点赞数加入Redis

点赞数相比评论来说，量更加巨大，用户点赞时直接落到MySQL数据库肯定不合理，服务器扛不住也没必要扛。

假如点赞数没有进行事务控制。南哥打算这样处理，用户点赞后，后端服务接受到点赞请求，把用户内容、点赞数放到Redis里，这里采用Redis五大基本类型之一：Map。

// Map结构

comment_like_key = [comment_id_6:like_count = 66, comment_id_7:like_count = 77]

我们需要查询点赞数时直接从高性能内存数据库Redis查询。

当然这还没完，MySQL数据库和Elasticsearch的点赞量需要去同步更新，我们设置定时任务每个一段时间完成数据同步任务。上文的comment_likes点赞记录表同样需要记录，把点赞放到Redis时进行异步添加点赞记录即可。

// 定时任务数据同步任务

@Scheduled(fixedRate = 10000)

public void syncLikes() {

    // 从 Redis 中读取最新的点赞数据

    Map<Integer, Integer> likes = redisService.fetchAllLikes();



    // 同步到 MySQL 和 Elasticsearch

    likes.forEach((commentId, likeCount) -> {

        commentRepository.updateLikeCount(commentId, likeCount);

        elasticsearchService.updateLikeCount(commentId, likeCount);

    });

}

戳这，《JavaSouth》作为一份涵盖Java程序员所需掌握核心知识、面试重点的神秘文档。

我是南哥，南就南在Get到你的点赞点赞。

创作不易，不妨点赞、收藏、关注支持一下，各位的支持就是我创作的最大动力❤️

Visual Studio Code 是由微软开发的一款开源的代码编辑器，它有了一个丰富的插件市场，提供了很多实用的插件。本文就来分享 2024 年开发必备的 VS Code 插件！

功能强化

驼峰翻译助手

纠结怎么取变量? 中文一键翻译转换成常用大小驼峰等格式。

change-case

Change-case插件提供了一种简单的方法来将单词或变量名更改为各种情况，包括驼峰命名（camelCase）、下划线命名（snake_case）、标题命名（TitleCase）等多种格式。

Codelf

变量命名神器，搜索 Github、Bitbucket、Google Code、Codeplex、Sourceforge、Fedora Project、GitLab 中的项目以查找实际使用的变量名称。

Surround

用于在代码块周围添加包装代码片段。该插件支持语言标识符、多选区操作、完全可自定义、自定义包装代码片段，并为每个包装代码片段单独分配快捷键。

Duplicate Action

一键复制并创建文件或文件夹，提高了开发过程中的文件操作效率。

CSS Peek

它允许开发者直接从HTML文档中快速跳转到匹配的CSS样式定义，并提供预览功能，从而大大提高CSS样式的查找和编辑效率。

Regex Previewer

可以实时预览正则表达式匹配结果，并适用于多种前端框架和语言，同时提供快捷键操作、全局和多行选项等便捷功能，以提升开发效率。

Code Spell Checker

Code Spell Checker 插件可以检查单词拼写是否出现错误，检查的规则遵循 camelCase （驼峰拼写法）。

Markdown Preview Enhanced

支持实时预览 Markdown 文件效果，并具备导出 PDF、支持数学公式、流程图等多种高级功能，提供了丰富的定制选项和兼容性，极大地提升了 Markdown 文档的编辑和预览体验。

Markdown All in One

用于提供Markdown编辑的全方位支持，包括实时预览、语法提示、目录生成、表格生成等多种功能。

i18n-ally

主要用于国际化多语言开发，提供内联提示、快速修改key值对应的语言文件、统一管理翻译、自动翻译等功能。

GitHub Repositories

在 VS Code 中快速打开 Github 仓库，无需克隆到本地。

Turbo Console Log

一键生成有意义的 console.log 消息，支持多语言、多光标操作，提供可定制的日志类型和输出格式，提高调试效率。

indent-rainbow

一款代码缩进可视化插件，它通过为文本前面的缩进着色，使缩进更具可读性。

Remote-SSH

允许开发者通过 SSH 协议连接到远程服务器或虚拟机，直接在本地 VS Code 编辑器中操作远程服务器上的代码，实现无缝的远程开发体验。主要功能包括远程连接、无缝的代码编辑和调试、扩展兼容性、多种连接选项、优化的性能以及支持多个远程服务器同时连接等。

前端框架

ES7+ React/Redux/React-Native snippets

提供了许多速记前缀来加速开发并帮助开发人员为 React、Redux、GraphQL 和 React Native 创建代码片段和语法。

Typescript React Code Snippets

此插件包含了使用 Typescript 的 React 代码片段，它支持 Typescript(.ts) 或 TypeScript React (.tsx) 等语言。以下是使用 TypeScript 创建 React 组件的两个片段。

• 默认导出 React：

• 导出 React 组件：

Vue - Official

Vue 官方扩展。

Vue 3 Snippets

这个插件包含了所有的 Vue.js 2 和 Vue.js 3 的 api 对应的代码片段。

Vue VSCode Snippets

此插件将 Vue 2 Snippets 和 Vue 3 Snippets 添加到 Visual Studio Code 中。

React Native Tools

允许在不同的模拟器或仿真器上轻松运行和调试代码，从命令面板快速运行 react-native 命令，而无需在终端中手动运行命令，并使用 IntelliSense 浏览 React Native 的函数、对象和参数等。

JavaScript (ES6) code snippets

通过此插件可以使用预定义的 ES6 语法片段速记，从而提高开发效率。这个 VS Code 插件可以自定义，因为它不特定于任何框架。

Tailwind CSS IntelliSense

专为使用 Tailwind CSS 的开发者设计，提供实时的类名建议、自动完成、文档预览等功能，以提升 Tailwind CSS 的开发效率和代码质量。

Git 集成

GitLens

该插件增强了 VS Code 中的 Git，并从每个存储库中释放隐藏数据。可以快速查看代码的编写者、轻松导航和探索 Git 存储库、通过丰富的可视化效果和强大的比较命令获取有效信息，以及执行更多操作，帮助我们更好地理解代码。

Git History

该插件用于查看 Git 日志和文件历史记录并比较分支或提交。

Git Graph

Git Graph 插件用于可视化查看存储库的 Git 操作，并从图形中轻松执行Git操作。

统计分析

Import Cost

在项目中导入多个包时可能会出现性能问题，Import Cost 就用于查看将特定库导入项目的成本。该插件会显示导入库的大小，如果大小为绿色，则表示库很小，而红色表示库很大。

Time Master

从编程活动中自动生成的指标、见解和时间跟踪。它是一个开源项目，独立于网络环境，安全轻量。

VS Code Counter

VS Code Counter 插件用于统计项目代码的行数，安装插件之后，右键点击需要统计代码的文件夹，选择“Count lines in directory”，这时就会在项目根目录出现一个名为 .VSCodeCounter 的文件夹，包含了不同格式的结果，编辑器会打开其中的的 .md 格式。结果中会显示代码总行数，不同格式文件行数，不同路径文件函数等。代码行数中有纯代码行数、空白行数、注释行数。

AI 编程辅助

GitHub Copilot

GitHub Copilot 是 Github 推出的一款 AI 结对编程工具，可以帮助开发者更快、更智能地编写代码，不过该插件并不是免费的。

Tabnine

Tabnine 是一款 AI 代码助手，可加速和简化软件开发，同时保证代码的私密性、安全性和合规性。

Codeium

一个基于 AI 技术的免费代码加速工具包，为VSCode提供70多种语言的快速自动补全、聊天和搜索功能，支持IDE内聊天和多种编程语言的建议。

TONGYI Lingma

通义灵码是阿里云推出的一款基于通义大模型的智能编码辅助工具，提供实时续写、自然语言生成代码、单元测试生成、代码注释生成、代码解释、研发智能问答、异常报错排查等能力。

CodeGeeX

CodeGeeX 是一款基于大模型的智能编程助手，它完善了代码的生成与补全，自动为代码添加注释，此外，它还针对代码问题的智能问答，当然还包括代码解释，实现代码，修复代码bug等非常丰富的功能。

代码美化

Highlight Matching Tag

用于实时高亮显示匹配的标签对，方便用户在 HTML 或 XML 代码中快速找到配对的标签。它可以在点击一个标签时，自动显示配对的标签，并通过下划线或其他样式来指示它们之间的对应关系。

TODO Highlight

实时高亮显示代码中的TODO、FIXME等标记，支持自定义关键字和正则表达式匹配，方便开发者快速识别、管理和追踪待办事项。

Todo Tree

用于在Visual Studio Code中搜索、管理和高亮代码中的待办事项标记（如TODO、FIXME等）。它支持自定义标签、颜色编码、实时更新、过滤与排序等功能，并以可视化的树形结构展示待办事项列表，方便开发者快速定位、编辑和跟踪代码中的待办事项。

Better comments

该插件对不同类型的注释会附加了不同的颜色，更加方便区分，帮助我们在代码中创建更人性化的注释。

Colorize

Colorize 会给颜色代码增加一个当前匹配代码颜色的背景。它通过 CSS 变量、预处理器变量、hsl/hsla 颜色、跨浏览器颜色、exa、rgb、rgba和argb的彩色背景将 CSS 颜色可视化，帮助开发者快速区分颜色。

Image preview

通过此插件，当鼠标悬浮在图片的链接上时，可以实时预览该图片，除此之外，还可以看到图片的大小和分辨率。

CodeSnap

CodeSnap 用于对代码的进行截图和共享。屏幕截图可以用文本或形状进行注释，并通过链接共享或包含在网站或文档中。只需使用 ctrl + shift + P 并输入 CodeSnap，然后按回车键，CodeSnap 窗口就会打开。

Error Lens

Error Lens 是一款把代码检查(错误、警告、语法问题)进行突出显示的插件。Error Lens 通过使诊断更加突出，增强了语言的诊断功能，突出显示了由该语言生成的诊断所在的整行，并在代码行的位置以行方式在线打印了诊断消息。

Pretty TypeScript Errors

Pretty TypeScript Errors 旨在使 TypeScript 的错误信息更易读、更人性化。随着 TypeScript 类型复杂性的增加，错误消息可能会变得混乱不堪，充满了难以理解的括号和“...”。这个扩展通过重新格式化或解释 TypeScript 编译器产生的原始错误信息，来帮助开发者更容易地理解发生了什么。

编辑器美化

Power Mode

Power Mode 旨在通过添加视觉特效来增强编程体验，通过了诸如粒子效果、烟火、火焰、魔法效果等特效，让编程过程更加生动有趣。

One Dark Pro

一款编辑器主题。

Dracula Official

一款编辑器主题。

GitHub Theme

一款编辑器主题。

Winter Is Coming Theme

一款编辑器主题。

Ayu

一款编辑器主题。

vscode-icons

VSCode 官方出品的图标库。

Material Icon Theme

该插件根据最新的 Material Design 主题为文件和文件夹提供图标。它可以帮助我们识别文件并为编辑器添加自定义的外观。

Peacock

允许开发者为 Visual Studio Code 的工作区界面（如侧边栏、底栏和标题栏）自定义颜色，以区分不同的项目或编码环境。

看过剧版《三体》的读者或许都记得一个名场面：来自三体的智子封锁了人类科技，还向地球人发出了「你们是虫子」的宣告。但没有超能力的普通人史强却在蝗群漫天飞舞的麦田中喊出：「把我们人类看成是虫子的三体人，他们似乎忘了一个事实，那就是虫子从来就没有被真正地战胜过」。

三体人看到的是单个虫子脆弱的一面 —— 你可以轻松踩死一只蚂蚁，打死一只蝗虫、蜜蜂。但他们没有看到的是，当这些虫子集结在一起时，它们可以涌现出远超个体简单相加的力量。

科学家们很早就发现了这种力量，并将其命名为「群体智能」（Swarm Intelligence）。这种智能不是由某个中央大脑控制，而是通过个体间的简单互动和信息交换自然形成的。它是一种集体智慧的体现，是自然界中一种奇妙而高效的协作方式。

其实，从宏观上说，人类社会的不断发展和演化也是一种群体智能现象，绝大多数文明成果都是人类个体在长期群体化、社会化的生产生活中逐渐演化形成的产物。

那么，人工智能的发展能否借鉴这种模式？答案自然是「能」。但长期以来，由于机器的个体智能化程度较低等原因，「群体智能」迟迟难以涌现。

生成式 AI 的发展或许可以推动这些问题的解决，也让「群体智能」获得了新一轮的关注。

「这波生成式 AI 相当于把个体的智能化水平提升上去了。而个体智能的提升，意味着群体的智能有望实现指数级增长。」在近期的一次访谈中，RockAI CEO 刘凡平向机器之心表达了这样的观点。

RockAI 是一家成立于 2023 年 6 月的 AI 初创，他们自研了国内首个非 Attention 机制的 Yan 架构通用大模型，并将这个大模型部署在了手机、PC、无人机、机器人等多种端侧设备上，还尝试让自己的大模型在这些设备上实现「自主学习」能力。

而这一切均服务于一个宏大的目标 —— 让每一台设备都拥有自己的智能，而且是可以像人类一样实时学习、个性化自主进化的系统。刘凡平认为，当这些拥有不同能力、不同个性的智能单元得以协同，即可完成数据共享、任务分配和策略协调，涌现出更为宏大、多元的群体智能，最终实现个性化与群体智能的和谐统一，开启人与机器的智能新时代。

那这一切怎么去实现呢？在访谈中，刘凡平和邹佳思（RockAI 联合创始人）向机器之心分享了他们的路线图和最新进展。

一条不同于 OpenAI 的 AGI 路线

前面提到，「群体智能」的研究进展受限于单个个体的智能化程度，所以研究者们首先要解决的问题就是让单个个体变得足够聪明。

要说「聪明」，OpenAI 的模型可以说是出类拔萃。但从目前的情况来看，他们似乎更侧重于训练出拥有超级智能的单个大模型。而且，这条路线走起来并不容易，因为它高度依赖海量的数据和计算资源，这在能源、数据和成本上都带来了可持续性的问题。 

此外，通过一个超级智能模型来处理所有任务是一种高度中心化的模式，这在实践中容易出现智能增长的瓶颈，因为单一模型缺乏灵活的适应能力和协作效应，导致其智能提升速度受到限制。

那么，OpenAI 未来有没有可能也走群体智能的路线？这个问题目前还没有明确答案。但可以看到的一点是，以该公司和其他大部分公司当前采用的 Transformer 架构去构建群体智能的单个个体可能会遇到一些障碍。

首先是高算力需求的障碍。以 Attention 机制为基础的 Transformer 架构对计算资源的需求非常高，其计算复杂度为 O (n^2)（n 为序列长度）。这意味着随着输入序列的增长，计算成本急剧增加。在构建群体智能时，我们需要多个单元大模型协同工作，而这些单元大模型往往部署在低算力的设备上（如无人机、手机、机器人等）。如果不经过量化、裁剪等操作，Transformer 架构的模型很难在低算力设备上直接部署。所以我们看到，很多公司都是通过这些操作让模型成功在端侧跑起来。

但对于群体智能来说，光让模型跑起来还不够，还要让它们具备自主学习的能力。在刘凡平看来，这一点至关重要。

他解释说，在一个没有自主学习的群体中，最聪明的个体会主导其他智能体的决策，其他智能体只能跟随它的指引。这种情况下，群体智能的上限就是最聪明个体的水平，无法超越。但通过自主学习，每个智能体都可以独立提升自身的智能水平，并逐渐接近最聪明的个体。而且，自主学习促进了知识共享，类似于人类的知识传承。这样，群体中的所有智能体都会变得更聪明，群体整体的智能水平有望实现指数级增长，远远超出简单的个体累加。

而量化、裁剪等操作最致命的问题，就是破坏了模型的这种自主学习能力。「当一个模型被压缩、量化、裁剪之后，这个模型就不再具备再学习的能力了，因为它的权重已经发生了变化，这种变化基本是不可逆的。这就像我们把一个螺丝钉钉入墙中，如果在敲入的过程中螺丝钉受到损坏，那么想要把它取出来重新使用就变得很困难，让它变得更锋利就变得不可能。」刘凡平解释说。

讲到这里，实现群体智能的路线其实就已经非常清晰了：

• 首先，你要在架构层面做出改变，研发出一种可以克服 Transformer 缺陷的新架构。


• 然后，你要将基于这个架构的模型部署到各种端侧设备上，让模型和这些设备高度适配。


• 接下来，更重要的一点是，这个架构的模型要能够在各种端侧设备上自主学习，不断进化。


• 最后，这些模型与端侧设备结合成的智能体要能够自主协作，共同完成任务。

这其中的每个阶段都不简单：

• 在第一阶段，新架构不止要具备低算力、部署到端侧原生无损的特点，还要具备可以媲美 Transformer 架构的性能，保证单个个体足够聪明且可以自主学习。


• 在第二阶段，「大脑和身体」的高度适配涉及感知层面和数据处理的不同模态，每种设备有着不同的需求，这增加了模型和设备适配的复杂性。 


• 在第三阶段，让模型部署之后还可以学习就意味着要挑战现有的训练、推理完全分离的机制，让模型参数在端侧也可以调整，且调整足够快、代价足够小。这就涉及到对传统反向传播机制的挑战，需要的创新非常底层。


• 在第四阶段，主要挑战是如何实现智能体之间的有效协作。这个过程要求智能体自主发现并形成完成任务的最佳方案，而不是依赖于人为设定或程序预设的方案。智能体需要根据自己的智能水平来决定协作的方式。

这些难点就决定了，RockAI 必须走一条不同于 OpenAI 的路线，挑战一些传统的已经成为「共识」的方法。

刘凡平提到，在前两个阶段，他们已经做出了一些成果，针对第三、四个阶段也有了一些实验和构想。

群体智能的单元大模型 ——Yan 1.3

第一阶段的标志性进展是一个采用 Yan 架构（而非 Transformer 架构或其变体）的大模型。这个模型的 1.0 版本发布于今年的 1 月份，为非 Attention 机制的通用自然语言大模型。据了解，该模型有相较于同等参数 Transformer 的 7 倍训练效率、5 倍推理吞吐和 3 倍记忆能力。而且，这一模型 100% 支持私有化部署应用，不经裁剪和压缩即可在主流消费级 CPU 等端侧设备上无损运行。

经过半年多的攻关，这一模型刚刚迎来了最新版本 ——Yan 1.3。

Yan 1.3 是一个 3B 参数的多模态模型，能够处理文本、语音、视觉等多种输入，并输出文本和语音，实现了多模态的模拟人类交互。

尽管参数量较小，但其效果已超越 Llama 3 8B 的模型。而且，它所用的训练语料比 Llama 3 要少，训练、推理算力也比 Llama 3 低很多。这在众多非 Transformer 架构的模型中是一个非常领先的成绩，其训练、推理的低成本也让它比其他架构更加贴近工业化和商业化。

这些出色的性能得益于高效的架构设计和算法创新。

在架构层面，RockAI 用一个名叫 MCSD（multi-channel slope and decay）的模块替换了 Transformer 中的 Attention 机制，同时保留 Attention 机制中 token 之间的关联性。在信息传递过程中，MCSD 强调了有效信息的传递，确保只有最重要的信息被传递给后续步骤，而且是以 O (n) 的复杂度往下传，这样可以提高整体效率。在验证特征有效性和 token 之间的关联性方面，MCSD 表现优秀。

**在算法层面，RockAI 提出了一种类脑激活机制。**这是一种分区激活的机制，就像人开车和写字会分别激活脑部的视觉区域和阅读区域一样，Yan 1.3 会根据学习的类型和知识范围来自适应调整部分神经元，而不是让全量的参数参与训练。推理时也是如此。具体有哪些神经元来参与运算是由仿生神经元驱动的算法来决定的。

在今年的 GTC 大会上，Transformer 论文作者之一 Illia Polosukhin 提到，像 2+2 这样的简单问题可能会使用大模型的万亿参数资源。他认为自适应计算是接下来必须出现的事情之一，我们需要知道在特定问题上应该花费多少计算资源。RcokAI 的类脑激活机制是自适应计算的一种实现思路。

这或许听起来和 MoE 有点像。但刘凡平解释说，类脑激活机制和 MoE 有着本质的区别。MoE 是通过「专家」投票来决定任务分配，每个「专家」的网络结构都是固定的，其结果是可预测的。而类脑激活机制没有「专家」，也没有「专家」投票的过程，取而代之的是神经元的选择过程。其中的每个神经元都是有价值的，选择的过程也是一个自学习的过程。

这种分区激活机制在 MCSD 的基础上进一步降低了 Yan 架构模型的训练、推理计算复杂度和计算量。

「这也符合人类大脑的运行方式。人脑的功耗只有二十几瓦，如果全部的 860 亿个神经元每次都参与运算，大脑产生的生物电信号肯定是不够用的。」刘凡平说道。目前，他们的类脑激活机制已经得到了脑科学团队的理论支持和实际论证，也申请到了相关专利。

以端侧设备为载体，迈向群体智能

在 Yan 1.3 的发布现场，我们看到了该模型在 PC、手机、机器人、无人机等端侧设备的部署情况。鉴于 Yan 1.2 发布时甚至能在树莓派上运行，这样的端侧部署进展并不令我们感到意外。

视频详情

部署了 Yan 1.3 的机器人。机器人内置硬件为 Intel Core i3。

而且我们知道，这些端侧智能体的潜力才刚刚显露。毕竟，以上创新的目标不只是让模型能够在端侧跑起来（当前很多模型都能做到这一点），而是使其具备自主学习的能力，作为「群体智能的单元大模型」持续进化。无论是 Yan 架构的「0 压缩、0 裁剪」无损部署，还是分区激活的高效计算，都是服务于这一目标。这是 RockAI 和其他专注于端侧 AI 的公司的一个本质区别。

「如果我们拿一个 10 岁的孩子和一个 30 岁的博士来比，那肯定 30 岁的博士知识面更广。但是，我们不能说这个 10 岁的孩子在未来无法达到甚至超越这位博士的成就。因为如果这个 10 岁的孩子自我学习能力足够高，他的未来成长速度可能比 30 岁的博士还要快。所以我们认为，自主学习能力才是衡量一个模型智能化程度的重要标志。」刘凡平说道。可以说，这种自主学习能力才是 RockAI 追求的「scaling law」。

为了实现这种自主学习能力，RockAI 的团队提出了一种「训推同步」机制，即让模型可以在推理的同时，实时有效且持续性地进行知识更新和学习，最终建立自己独有的知识体系。这种「训推同步」的运行方式类似于人类在说话的同时还能倾听并将其内化为自己的知识，对底层技术的要求非常高。

为此，RockAI 的团队正在寻找反向传播的更优解，方法也已经有了一些原型，并且在世界人工智能大会上进行过展示。不过，他们的方法原型目前仍面临一些挑战，比如延迟。在后续 Yan 2.0 的发布中，我们有望见到原型升级版的演示。

那么，在每一台设备都拥有了智能后，它们之间要怎么联结、交互，从而涌现出群体智能？对此，刘凡平已经有了一些初步构想。

首先，它们会组成一个去中心化的动态系统。在系统中，每台设备都拥有自主学习和决策的能力，而不需要依赖一个中央智能来控制全局。同时，它们之间又可以共享局部数据或经验，并通过快速的通信网络互相传递信息，从而在需要时发起合作，并利用其他智能体的知识和资源来提升任务完成的效率。

路线「小众」，挑战与机遇并存

纵观国内 AI 领域，RockAI 走的路可以说非常「小众」，因为里面涉及到非常底层的创新。在硅谷，有不少人在做类似的底层研究，就连「神经网络之父」Hint0n 也对反向传播的一些限制表示过担忧，特别是它与大脑的生物学机制不符。不过，大家目前都还没有找到特别有效的方法，因此这一方向还没有出现明显的技术代差。对于 RockAI 这样的国内企业来说，这既是挑战，也是机遇。

对于群体智能，刘凡平相信，这是一条迈向更广泛的通用人工智能的路线，因为它的理论基础是非常坚实的，「如果没有群体智能，就没有人类社会的文明，更不会有科技的发展」。

而且，刘凡平认为，群体智能所能带来的生产力变革比拥有超级智能的单个大模型所能带来的更全面、更多样。随着自主架构大模型的研发成功和多元化硬件生态的构建，他们相信自己正在逐渐接近这一目标。

我们也期待看到这家公司的后续进展。

参考链接：

news.sciencenet.cn/sbhtmlnews/…

lib.ia.ac.cn/news/newsde…

http://www.shxwcb.com/1205619.htm…

mp.weixin.qq.com/s/t6TurjgHH…

© THE END 

最近逛G站，偶然发现一款 iOS UI 调试工具，那就是腾讯 QMUI团队 开源的LookinSever[1]。初步体验了一下，功能还是非常强大，简单记录并分享一下。

简介

腾讯的LookinServer[2]是一款专为iOS开发者设计的UI调试工具，类似于 Xcode 自带的 UI Inspector 工具，或者以前常用的另一款软件Reveal。

基本功能

1、实时UI查看： LookinServer可以实时捕捉并显示iOS应用的UI层级结构。这包括所有的视图(Views)、控件(Controls)以及它们的属性(Properties)等。

2、层级视图展示： 通过图形化界面，开发者可以方便地浏览UI的层级关系。这有助于快速定位UI问题，例如某些视图被错误地覆盖或布局不正确。

3、属性编辑： 开发者可以直接在LookinServer中修改视图的属性（如frame、color等），并立即在应用中看到效果。这种所见即所得的调试方式大大加快了UI调整的效率。

4、视图调试： LookinServer支持对单个视图进行详细调试，包括查看其布局约束、事件响应链、以及性能指标等。

工作原理

1、数据抓取： LookinServer会将目标iOS应用中的UI数据抓取下来。这通常涉及到通过iOS的运行时(Runtime)机制和反射机制来获取应用当前的UI层级和视图信息。

2、通信机制： LookinServer客户端与iOS应用之间通过网络通信进行数据传输。应用中集成的LookinServer SDK会将视图层级、属性等数据打包发送到LookinServer客户端进行展示。

3、动态更新： 当开发者在LookinServer客户端中修改视图属性时，修改指令会通过通信机制发送回iOS应用，应用立即应用这些修改并更新显示。通过这种方式，实现了实时的UI调试。

使用场景

1、UI布局调试： 快速发现并修正UI布局问题，例如视图错位、层级不正确等。

2、UI性能优化： 查看每个视图的性能指标，找出性能瓶颈并进行优化。

3、快速迭代： 在开发过程中频繁修改UI时，通过LookinServer可以快速预览效果，减少编译和重启应用的时间。

优势

1、提高效率： 实时查看和修改UI，大大减少了传统调试方式的时间成本。

2、直观可视化： 图形化的视图层级展示，让开发者可以更直观地理解UI结构。

3、易于集成： LookinServer Framework易于集成到现有项目中，支持CocoaPods、 Swift Package Manager以及手动集成，支持OC和Swift，不需要对项目做大的改动。

小试牛刀

1、安装Lookin： 官网[3]下载并安装Lookin Mac客户端。

2、安装 LookinServer Framework：

• • 通过 CocoaPods


• • Swift项目：pod 'LookinServer', :subspecs => ['Swift'], :configurations => ['Debug']


• • ObjC项目：pod 'LookinServer', :configurations => ['Debug']


• • 通过 Swift Package Manager：github.com/QMUI/Lookin…


• • 手动集成：下面以OC项目为例。 将下载的源码导入项目中，注意Swift文件夹里面的可以删除，或者将文件LKS_SwiftTraceManager.swift不加到target里参与编译。

在Debug模式下，打开SHOULD_COMPILE_LOOKIN_SERVER宏定义。

3、简单使用： 建个项目，拖几个控件，运行，打开第一步安装的LookinMac 软件，监测到运行的项目，可以看到视图层级关系、target-action、手势、常见属性设置等，UI及时同步刷新。

注意事项

1、需要在 Debug 模式下使用 

2、使用 1.0.6及以后 的版本

总结

腾讯的LookinServer是一个强大的iOS UI调试工具，其通过实时查看、编辑和调试视图层级和属性，极大地提高了UI开发和调试的效率。通过掌握其原理和使用方法，开发者可以更高效地处理UI问题，提高应用的整体质量。

引用链接

[1] LookinSever: github.com/QMUI/Lookin…

[2] LookinServer: lookin.work/

[3] 官网: lookin.work/

你好呀，我是歪歪。

前几天我在网上冲浪，看到一个哥们在吐槽，说他工作三年多了，没使用过多线程。

虽然八股文背的滚瓜烂熟，但是没有在实际开发过程中写的都是业务代码，没有使用过线程池，心里还是慌得一比。

我只是微微一笑，这不是很正常吗？

业务代码中一般也使不上多线程，或者说，业务代码中不知不觉你以及在使用线程池了，你再 duang 的一下搞一个出来，反而容易出事。

所以提到线程池的时候，我个人的观点是必须把它吃得透透的，但是在业务代码中少用或者不用多线程。

关于这个观点，我给你盘一下。

Demo

首先我们还是花五分钟搭个 Demo 出来。

我手边刚好有一个之前搭的一个关于 Dubbo 的 Demo，消费者、生产者都有，我就直接拿来用了：

这个 Demo 我也是跟着网上的 quick start 搞的：

cn.dubbo.apache.org/zh-cn/overv…

可以说写的非常详细了，你就跟着官网的步骤一步步的搞就行了。

我这个 Demo 稍微不一样的是我在消费者模块里面搞了一个 Http 接口：

在接口里面发起了 RPC 调用，模拟从前端页面发起请求的场景，更加符合我们的开发习惯。

而官方的示例中，是基于了 SpringBoot 的 CommandLineRunner 去发起调用：

只是发起调用的方式不一样而已，其他没啥大区别。

需要说明的是，我只是手边刚好有一个 Dubbo 的 Demo，随手就拿来用了，但是本文想要表达的观点，和你使不使用 Dubbo 作为 RPC 框架，没有什么关系，道理是通用的。

上面这个 Demo 启动起来之后，通过 Http 接口发起一次调用，看到控制台服务提供方和服务消费方都有对应的日志输出，准备工作就算是齐活儿了：

上菜

在上面的 Demo 中，这是消费者的代码：

这是提供者的代码：

整个调用链路非常的清晰：

来，请你告诉我这里面有线程池吗？

没有！

是的，在日常的开发中，我就是写个接口给别人调用嘛，在我的接口里面并没有线程池相关的代码，只有 CRUD 相关的业务代码。

同时，在日常的开发中，我也经常调用别人提供给我的接口，也是一把梭，撸到底，根本就不会用到线程池。

所以，站在我，一个开发人员的角度，这个里面没有线程池。

合理，非常合理。

但是，当我们换个角度，再看看，它也是可以有的。

比如这样：

反应过来没有？

我们发起一个 Http 调用，是由一个 web 容器来处理这个请求的，你甭管它是 Tomcat，还是 Jetty、Netty、Undertow 这些玩意，反正是个 web 容器在处理。

那你说，这个里面有线程池吗？

在方法入口处打个断点，这个 http-nio-8081-exec-1 不就是 Tomcat 容器线程池里面的一个线程吗：

通过 dump 堆栈信息，过滤关键字可以看到这样的线程，在服务启动起来，啥也没干的情况下，一共有 10 个：

朋友，这不就是线程池吗？

虽然不是你写的，但是你确实用了。

我写出来的这个 test 接口，就是会由 web 容器中的一个线程来进行调用。所以，站在 web 容器的角度，这里是有一个线程池的：

同理，在 RPC 框架中，不管是消费方，还是服务提供方，也都存在着线程池。

比如 Dubbo 的线程池，你可以看一下官方的文档：

cn.dubbo.apache.org/zh-cn/overv…

而对于大多数的框架来说，它绝不可能只有一个线程池，为了做资源隔离，它会启用好几个线程池，达到线程池隔离，互不干扰的效果。

比如参与 Dubbo 一次调用的其实不仅一个线程池，至少还有 IO 线程池和业务线程池，它们各司其职：

我们主要关注这个业务线程池。

反正站在 Dubbo 框架的角度，又可以补充一下这个图片了：

那么问题来了，在当前的这个情况下？

当有人反馈：哎呀，这个服务吞吐量怎么上不去啊？

你怎么办？

你会 duang 的一下在业务逻辑里面加一个线程池吗？

大哥，前面有个 web 容器的线程池，后面有个框架的线程池，两头不调整，你在中间加个线程池，加它有啥用啊？

web 容器，拿 Tomcat 来说，人家给你提供了线程池参数调整的相关配置，这么一大坨配置，你得用起来啊：

tomcat.apache.org/tomcat-9.0-…

再比如 Dubbo 框架，都给你明说了，这些参数属于性能调优的范畴，感觉不对劲了，你先动手调调啊：

你把这些参数调优弄好了，绝对比你直接怼个线程池在业务代码中，效果好的多。

甚至，你在业务代码中加入一个线程池之后，反而会被“反噬”。

比如，你 duang 的一下怼个线程池在这里，我们先只看 web 容器和业务代码对应的部分：

由于你的业务代码中有线程池的存在，所以当接受到一个 web 请求之后，立马就把请求转发到了业务线程池中，由线程池中的线程来处理本次请求，从而释放了 web 请求对应的线程，该线程又可以里面去处理其他请求。

这样来看，你的吞吐量确实上去了。

在前端来看，非常的 nice，请求立马得到了响应。

但是，你考虑过下游吗？

你的吞吐量上涨了，下游同一时间处理的请求就变多了。如果下游跟不上处理，顶不住了，直接就是崩给你看怎么办？

而且下游不只是你一个调用方，由于你调用的太猛，导致其他调用方的请求响应不过来，是会引起连锁反应的。

所以，这种场景下，为了异步怼个线程池放着，我觉得还不如用消息队列来实现异步化，顶天了也就是消息堆积嘛，总比服务崩了好，这样更加稳妥。

或者至少和下游勾兑一下，问问我们这边吞吐量上升，你们扛得住不。

有的小伙伴看到这里可能就会产生一个疑问了：歪师傅，你这个讲得怎么和我背的八股文不一样啊？

巧了，你背过的八股文我也背过，现在我们来温习一下我们背过的八股文。

什么时候使用线程池呢？

比如一个请求要经过若干个服务获取数据，且这些数据没有先后依赖，最终需要把这些数据组合起来，一并返回，这样经典的场景：

用户点商品详情，你要等半天才展示给用户，那用户肯定骂骂咧咧的久走了。

这个时候，八股文上是怎么说的：用线程池来把串行的动作改成并行。

这个场景也是增加了服务 A 的吞吐量，但是用线程池就是非常正确的，没有任何毛病。

但是你想想，我们最开始的这个案例，是这个场景吗？

我们最开始的案例是想要在业务逻辑中增加一个线程池，对着一个下游服务就是一顿猛攻，不是所谓的串行改并行，而是用更多的线程，带来更多的串行。

这已经不是一个概念了。

还有一种场景下，使用线程池也是合理的。

比如你有一个定时任务，要从数据库中捞出状态为初始化的数据，然后去调用另外一个服务的接口查询数据的最终状态。

如果你的业务代码是这样的：

//获取订单状态为初始化的数据(0:初始化 1:处理中 2:成功 3:失败)

//select * from order where order_status=0;

ArrayList initOrderInfoList = queryInitOrderInfoList();

//循环处理这批数据

for(OrderInfo orderInfo : initOrderInfoList){

    //捕获异常以免一条数据错误导致循环结束

    try{

        //发起rpc调用

        String orderStatus = queryOrderStatus(orderInfo.getOrderId);

        //更新订单状态

        updateOrderInfo(orderInfo.getOrderId,orderStatus);  

    } catch (Exception e){

        //打印异常

    }

}

虽然你框架中使用了线程池，但是你就是在一个 for 循环中不停的去调用下游服务查询数据状态，是一条数据一条数据的进行处理，所以其实同一时间，只是使用了框架的线程池中的一个线程。

为了更加快速的处理完这批数据，这个时候，你就可以怼一个线程池放在 for 循环里面了：

//循环处理这批数据

for(OrderInfo orderInfo : initOrderInfoList){

    //使用线程池

    executor.execute(() -> {

        //捕获异常以免一条数据错误导致循环结束

        try {

            //发起rpc调用

            String orderStatus = queryOrderStatus(orderInfo.getOrderId);

            //更新订单状态

            updateOrderInfo(orderInfo.getOrderId, orderStatus);

        } catch (Exception e) {

            //打印异常

        }

    });

}

需要注意的是，这个线程池的参数怎么去合理的设置，是需要考虑的事情。

同时这个线程池的定位，就类似于 web 容器线程池的定位。

或者这样对比起来看更加清晰一点：

定时任务触发的时候，在发起远程接口调用之前，没有线程池，所以我们可以启用一个线程池来加快数据的处理。

而 Http 调用或者 RPC 调用，框架中本来就已经有一个线程池了，而且也给你提供了对应的性能调优参数配置，那么首先考虑的应该是把这个线程池充分利用起来。

如果仅仅是因为异步化之后可以提升服务响应速度，没有达到串行改并行的效果，那么我更加建议使用消息队列。

好了，本文的技术部分就到这里啦。

下面这个环节叫做[荒腔走板]，技术文章后面我偶尔会记录、分享点生活相关的事情，和技术毫无关系。我知道看起来很突兀，但是我喜欢，因为这是一个普通博主的生活气息。

荒腔走板

不知道你看完文章之后，有没有产生一个小疑问：最开始部分的 Demo 似乎用处并不大？

是的，我最开始构思的行文结构是是基于 Demo 在源码中找到关于线程池的部分，从而引出其实有一些我们“看不见的线程池”的存在的。

原本周六我是有一整天的时间来写这篇文章，甚至周五晚上还特意把 Demo 搞定，自己调试了一番，该打的断点全部打上，并写完 Demo 那部分之后，我才去睡觉的，想得是第二天早上起来直接就能用。

按照惯例周六睡个懒觉的，早上 11 点才起床，自己慢条斯理的做了一顿午饭，吃完饭已经是下午 1 点多了。

本来想着在沙发上躺一会，结果一躺就是一整个下午。期间也想过起来写一会文章，坐在电脑前又飞快的躺回到沙发上，就是觉得这个事情索然无味，当下的那一刻就想躺着，然后无意识的刷手机，原本是拿来写文章中关于源码的部分的时间就这样浪费了。

像极了高中时的我，周末带大量作业回家，准备来个悬梁刺股，弯道超车，结果变成了一睡一天，捏紧刹车。

高中的时候，时间浪费了是真的可惜。

现在，不一样了。

荒腔走板这张图片，就是我躺在沙发上的时候，别人问我在干什么时随手拍的一张。

我并不为躺了一下午没有干正事而感到惭愧，浪费了的时间，才是属于自己的时间。

很久以前我看到别人在做一些浪费时间的事情的时候，我心里可能会嘀咕几句，劝人惜时。

这两年我不会了，允许自己做自己，允许别人做别人。

背景：

最近实现一个功能需要使用iframe嵌入其它系统内部的一个页面，但嵌入后出现一个问题，就是一打开这个页面就会自动跳转到登录页，原因是被嵌入系统没有登录(没有token)肯定不让访问内部页面的，本文就是解决这个问题的。

附带相关文章：只要用iframe必遇到这6种"坑"之一（以Vue为例）

选择的技术方案：

本地系统使用iframe嵌入某个系统内部页面，那就证明被嵌入系统是安全的可使用的，所以可以通过通讯方式带一个token过去实现免登录，我用vue项目作为例子具体如下：

方法一通过url传：

// 发送方（本地系统）：

<div>

    <iframe :src="url" id="childFrame" importance="high" name="demo" ></iframe>

</div>



//被嵌入页面进行接收

url = `http://localhost:8080/dudu?mytoken={mytoken}` //  



接收方：直接使用window.location.search接收，然后对接收到的进行处理

注意：

• 如果使用这个方法最好把token加密一下，要不然直接显示在url是非常危险的行为，所以我更推荐下面方法二


• 上面接收方要在在APP.vue文件的created生命周期接收，在嵌入页面接收是不行的，这里与VUE的执行流程有关就不多说了

方法二通过iframe的通讯方式传（推荐）：

// 发送方（本地系统）：

 var params = {

    type: "setToken",

    token: "这是伟过去的token"

}

window.parent.postMessage(params, "*");







// 接收方（被嵌入系统）：在APP.vue文件的created生命周期接收

window.addEventListener( "message",

    (e)=>{

         if(e.data.type === 'setToken'){

              //这里拿到token,然后放入缓存实在免登录即可

         }

     }	

false);

注意： 上面接收方要在在APP.vue文件的created生命周期接收，在嵌入页面接收是不行的，这里与VUE的执行流程有关就不多说了

补充：

看着评论不少疑问，所以我就按我个人的思路去补充回答一下，但不绝对实用，欢迎互相指导

（1）如果不同源系统怎么办？

正常使用上述方法二进行通迅，但不带token过去因为不同源根本无法通用，直接在被嵌入页面请求token,这个要和后端沟通好怎么获取

// 接收方（被嵌入系统）：在APP.vue文件的created生命周期接收

window.addEventListener( "message",

    (e)=>{

         if(e.data.type === 'setToken'){

              //这里在被嵌入页面请求接口获取这个系统的token,然后放到缓存中免登录

         }

     }	

false);

（2）如果两个系统保存token字段相当怎么办？

例如：主系统本地存储的token叫：access_token , iframe嵌入的系统采用的token也叫：access_token

这分为两种情况：（1）同源并且token字段相同 （2）不同源并且token字段相当

（1）同源并且token字段相同

这种情况同源+token字段相同，根本不会出现需要登录的情况，因为同一个浏览器缓存都能拿到并且又是通用token

（2）不同源并且token字段相当

这种情况只有嵌入系统和本地系统两种情况它们并不会同时出现的，那么只要判断当前是那个情况就行，然后给对应的token

方案：请求在拦截器那里判断当前请求来自那个系统的页面，然后给对应的token

例如：两个系统都要传my_token字段给后端，如果都放缓存就会覆盖，所以直接本地系统放到token1缓存，嵌入系统放到token2缓存，拦截器判断后如果本来系统页面 my_token=token1，嵌入页面 my_token=token2

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

常见的重复提交场景

防止重复提交的需求

常用解决方案

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

后端幂等处理：

• 利用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院校的校长，讲到这里，大家意识到差距了吧。他说他学习很差，但被父母一路逼下去读到了研究生。。。毕业后家人关系托底去了某国有五大行，待遇不用多说大家也都懂。

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

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

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

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