起因

因为去年买的腾讯云服务器到期了，我一看续租的话要459元，作为白嫖党这是万万不能接受的！

于是我就想：能否搞一个简单的服务器，能跑基本的项目就好了。

然后我就在掘金上看到了一篇文章：如何将旧的Android手机改造为家用服务器

最后结合全网，搜到了如下两种方案:

• KSWEB
• Ternux

综合对比下，我选择用Termux试试。

前提

想要跑起来Termux，首先你要有一个安卓手机。

于是我就开始逛咸鱼，最后选了一款IQOO Neo5型号的，12+256G(有些小毛病)，花了315元，这个内存跑服务应该是够了的。

开始安装

安装Termux

1）通过github或者APKFab应用商店安装Termux。

2）更新和安装基础软件包

pkg update && pkg upgrade -y 

pkg install wget curl nano -y

安装nodejs

由于本人是前端开发，所有用的服务都是nodejs写的，所以只安装node相关的东西

pkg install nodejs

// 安装PHP或其他的同理，示例如下：

pkg install php 

安装完成后，打印一下看看是否成功了

安装其他

由于我的项目也有nodejs服务端，所以还需要安装以下：

• mysql 数据库
• ssh 远程连接
• redis 缓存
• cpolar 内网穿透（本地部署的项目，外网无法访问，用它来给外网访问）
• nginx 高性能代理

具体的教程就不展示细节了，推荐几个教程地址，仅供参考：

• 安装数据库：cloud.tencent.com/developer/a…
• 安装内网穿透：blog.csdn.net/m0_75215937…

设置完ssh后，就可以在电脑上的Xshell连接登录了，注意了：

默认端口号为8022，不是22

默认端口号为8022，不是22

默认端口号为8022，不是22

连接成功后是这样的

其中有一个用户身份验证，用户名输入whoami查看

放入几个项目

我用Xftp传入几个vue项目和nodejs项目

启动服务

项目放入后，启动的服务应该是只能局域网访问的，几个vue项目都是打包的dist文件，所以需要配置nginx代理，关键配置如下，有多少个项目，就来多少个server就行，慢慢配吧。

因为个人项目不多，也不找其他高大上的管理工具了

 # 加解密 配置

    server {

        listen       5290;

        server_name  192.168.3.155;



        location / {

            root   /data/data/com.termux/files/home/vue/rui-utils-crypt/dist;

            index  index.html index.htm;

        }



        error_page   500 502 503 504  /50x.html;

        location = /50x.html {

            root   /data/data/com.termux/files/usr/share/nginx/html;

        }

    }



    # 个人博客 配置

    server {

        listen       5173;

        server_name  192.168.3.155;



        location / {

            root   /data/data/com.termux/files/home/vue/vite-press-blog/dist;

            index  index.html index.htm;

        }



        error_page   500 502 503 504  /50x.html;

        location = /50x.html {

            root   /data/data/com.termux/files/usr/share/nginx/html;

        }

    }



    # 若依 - nodejs-vue

    server {

        listen 5000;

        server_name 192.168.3.155;



        location / {

        # dist为静态资源文件夹,dist内有index.html,

          root   /data/data/com.termux/files/home/vue/ruoyi-vue/dist;

          index  index.html index.htm;

          # 解决单页面应用中history模式不能刷新的bug

          try_files $uri $uri/ /index.html;

          # try_files $uri $uri/ =404;

        }



        # 服务器代理实现跨域

        location /prod-api/ {

            proxy_pass   http://192.168.3.155:7002/; # 将/api/开头的url转向该域名

            #如果报错则使用这一行代替上一行 proxy_pass   http://localhost:8000;  将/api/开头的url转向该域名

            rewrite "^/prod-api/(.*)$" /$1 break ; # 最终url中去掉/api前缀

        }



        # 静态资源优化 - 添加 ^~ 前缀提高匹配优先级

        location ^~ /assets/ {

            root /data/data/com.termux/files/home/vue/ruoyi-vue/dist;

            expires 12h;

            error_log /dev/null;

            access_log /dev/null;

        }





        #ERROR-PAGE-START  错误页配置，可以注释、删除或修改

        error_page 404 /404.html;



        #REWRITE-START URL重写规则引用,修改后将导致面板设置的伪静态规则失效

#         include /www/server/panel/vhost/rewrite/60.204.201.111.conf;

        #REWRITE-END



        #禁止访问的文件或目录

        location ~ ^/(.user.ini|.htaccess|.git|.env|.svn|.project|LICENSE|README.md)

        {

            return 404;

        }



        #一键申请SSL证书验证目录相关设置

        location ~ .well-known{

            allow all;

        }



        #禁止在证书验证目录放入敏感文件

        if ( $uri ~ "^/.well-known/.*.(php|jsp|py|js|css|lua|ts|go|zip|tar.gz|rar|7z|sql|bak)$" ) {

            return 403;

        }



        location ~ .*.(gif|jpg|jpeg|png|bmp|swf|ico)$

        {

            expires      30d;

            error_log /dev/null;

            access_log /dev/null;

        }



        location ~ .*.(js|css)?$

        {

            expires      12h;

            error_log /dev/null;

            access_log /dev/null;

        }

        access_log  /data/data/com.termux/files/usr/var/log/nginx/access.log;

        error_log   /data/data/com.termux/files/usr/var/log/nginx/error.log;

    }

本地访问

本人手机的ip为：192.168.3.155，端口用nginx的配置项即可，在Termux中输入nginx来启动，这样就可以本地访问了。

不知道ip的可以输入ifconfig来查看

 先访问一下192.168.3.155:5173

 可以看到，在电脑上已经能访问手机上启动的服务了。

但是我们需要外网也能访问，这就需要前面说的内网穿透了。

内网穿透

本项目的内网穿透选的是cpolar，教程见上文链接。

因为我装了sv工具，所以我输入sv up cpolar就启动了cpolar，启动后在电脑上输入手机IP + 9200端口号即可登录cpolar后台

配置本地的端口号：  配置完后，就可以在在线隧道列表菜单看到已配置的了

 然后我们就可以在公网地址访问了，复制列表的地址，打开：

至此，我们已经可以在外网访问手机上、部署的vue打包项目了。但是此时没有后端服务，接下来我们同时部署后端的服务。

部署nodejs后端

先运行以下命令，启动redis和数据库

redis-server --daemonize yes 



mysqld_safe &

然后根据nodejs的启动方法启动即可，一般为node 入口文件.js

我的启动成功如下

对应的前端地址如下：6331dea4.r5.cpolar.top/index

这个前后端是我用nodejs改写的java版若依管理后台，源码地址：gitee.com/ruirui-stud… 我以前的文章也有介绍的

最后，如果需要启动多个nodejs项目，可以用pm2管理

注意：本文的地址可能无法访问，因为手机我有别的用处，不一定随时开着

作者：前端没钱
来源：juejin.cn/post/7537893826595700788

前言

证券行业，最难的前端组件，也就是k线图了。
指标还可以添加、功能还可以扩展， 但思路要清晰。
作为一个从证券行业毕业的前端从业者，
我想分享下自己的项目经验。

1、H5 K线图，支持无限左右滑动、样式可随意定制；
2、纯canvas制作，不借助任何第三方图表库；
3、阅读本文，需要有 canvas 基础知识；

滑动K线图组件    Github Page 预览地址

股票详情页源码    Github Page 预览地址

注意：以上的 demo 还有一些 bug， 没时间修复， 预览地址是直接在 github 上部署的， 所以最好通过 vpn科学上网，否则可能访问不了，然后再在移动端打开页面。 另外， 上面的股票详情页， 还没有做自适应，等我有时间再改。

一、先看最终的效果

1、GIF动图如下

2、支持样式自定义

用可以屏幕取色器，获取东方财富的配色 codeinword.com/eyedropper

图一、图二，是参考东方财富黑白皮肤的配色， 图三是参考腾讯自选股的配色。

  

二、canvas 注意事项

1、整数坐标，会导致模糊

canvas 在画线段， 通常会出现以下代码：

cxt.moveTo(x1, y1);

cxt.lineTo(x2, y2);

cxt.lineWidth = 1;

cxt.stroke();

假设上面的两个点是（1，10）和（5，10），那么画出来的实际上是一条横线，
理论上横线的粗度是1px，且该横线被 y=10 切成两半，
上半部分粗度是 0.5px， 下半部分粗度也是 0.5px，
这样横线的整体粗度才会是 1px。

但是 canvas 不是这样处理的， canvas 默认线条会与整数对齐，
也就是横线的上部分不会是 y=9.5px， 而是 y=9px；
横线的下半部分也不是 y=10.5px， 而是 y=11px；
从而横线的粗度看起来不是1px，而是2px。

并且由于粗度被拉伸，颜色也会被淡化，那怎么解决这个问题呢？

处理方式也很简单， 通过 cxt.translate(0.5, 0.5) 将坐标往下移动 0.5 个像素，
然后接下来的所有点， 都保证是整数即可， 这样就能保证不会被拉伸。

典型的代码如下：

cxt.translate(0.5, 0.5)；

cxt.moveTo(Math.floor(x1), Math.floor(y1));

cxt.lineTo(Math.floor(x2), Math.floor(y2));

cxt.lineWidth = 1;

cxt.stroke();

在我的代码中， 也体现了类似的处理。

2、如何处理高像素比带来的模糊

设备像素比越高，理论上应该越清晰，因为原来用一个小方块来渲染1px， 现在用2个（dpr=2的情况）小方块来渲染，应该更清晰才对，但是canvas不是这样的。

例如，通过js获取父容器 div 的宽度是 width， 这时候如果设置 canvas.width = width，在设备像素比为2的时候， canvas 画出来的宽度为css对应宽度的一半， 如果强制通过 css 将 canvas 宽度设置为 width， 则 canvas 会被拉长一倍， 导致出现锯齿模糊。

注意了吗？上面所说的 canvas.width=width 与 css 设置的 #canvas { width: width } 起到的效果是不一样的。不要随便通过 css 去设置 canvas 的宽高， 容易被拉伸变形或者导致模糊。

通用的处理方式是：

//初始化高清Canvas

function initHDCanvas() {

  const rect = hdCanvas.getBoundingClientRect();

  

  //设置Canvas内部尺寸为显示尺寸乘以设备像素比

  const dpr = window.devicePixelRatio || 1;

  hdCanvas.width = rect.width * dpr;

  hdCanvas.height = rect.height * dpr;

  

  //设置Canvas显示尺寸保持不变

  hdCanvas.style.width = rect.width + 'px';

  hdCanvas.style.height = rect.height + 'px';

  

  //获取上下文并缩放

  const ctx = hdCanvas.getContext('2d');

  ctx.scale(dpr, dpr);

  

  //接下来，你可以自由发挥

}

三、样式配置

为了方便样式自定义， 我独立出一个默认的配置对象 defaultKlineConfig， 参数的含义如下图所示，其实下图这个风格的标注， 是通过 excalidraw 这个软件画的， 也是 canvas 做的开源软件， 可见 canvas 在前端可视化领域的重要性， 这个扯远了，打住。

如上图， 整个canvas 画板， 分成 5 部分，
每一部分的高度， 都可以设置，
其中主图和副图的高度，是通过比例来计算的：
mainChartHeight = restHeight * mainChartHeightPercent
其中，restHeigh 是画板总高度 height 减去其他几部分计算的， 如下：
restHeight = height - lineMessageHeight - tradeMessageHeight - xLabelHeight

十字交叉线的颜色， X轴 与 Y轴 的 tooltip 背景色、字体大小的参数如下：

四、均线计算

从上面的图可以看出， 需要画 5日均线、10日均线、20日均线， 成交量快线（10日）、成交量慢线（20日） 但是， 接口没有给出当日的均线值， 需要自己计算。

5日均线 = （过去4个成交日的收盘价总和 + 今日收盘价）/ 5

10日均线 = （过去9个成交日的收盘价总和 + 今日收盘价）/ 10

20日均线 = （过去19个成交日的收盘价总和 + 今日收盘价）/ 20

成交量快线 = （过去9日成交量 + 今日成交量）/ 10

成交量慢线 = （过去19日成交量 + 今日成交量）/ 20

所以， 当获取 lmt（一屏的蜡烛图个数）个数据时， 为了计算均线， 需要至少将前 19 个（我的代码写20）数据都获取到。当前一个均线已经获取到， 下一个均线就不需要再累加20个值再得平均数， 可以省一点计算：

今日20日均线值 = （昨日均线值 * 20 - 前面第20个的收盘价 + 今日收盘价）/ 20;

五、分层渲染

为了减少重绘，提高性能，可以将K线图做分层渲染。那分几层合适？我认为是三层。

1. 第一层， 不动层
2. 第二层，变动层
3. 第三层，交互层

不动层

首先， 网格是固定的， 也就是说，当页面拖拽、或者长按出现十字交叉的时候，底部的网格线是不变的，如果每次拖拽，都需要重绘网格，那这个其实是没有必要的开销，可以将网格放在最底层（例如 z-index：0），一次性绘制后，就不要再重绘。

变动层

由于拖拽的时候，蜡烛柱体，均线，Y轴刻度， X轴刻度， 都需要重绘， 这一块是无法改变的事实， 所以， 变动层放在中间层（例如 z-index：1），也是最繁忙的一层，并且该层不响应触摸事件。

交互层

最后， 交互层由于要捕捉用户的触摸行为， 所以，这一层要在最上层（例如 z-index：2）。

交互层监听触摸事件：当页面快速滑动， 则响应拖拽事件， 即K线图的时间线会左右滑动；当用户长按之后才滑动， 则出现十字交叉浮层。

交互层的好处是， 当响应十字交叉浮层时， 只需要绘制横线、竖线、对应X轴和Y轴的值，而不需要重绘蜡烛柱体和均线， 可以减少重绘，最大程度减少渲染压力。

六、基础几何绘制

网格线

首先计算出主图的高度 this.mainChartHeight， 将主图从上到下等分为4部分，再在左右两边画出竖线，形成主图的网格，副图是成交量图， 只需画一个矩形边框即可，用 strokeRect 即可画出。

//画出网格线

  private drawGridLine() {

    //获取配置参数

    const { gridColor, lineMessageHeight, xLabelHeight, width, height } = this.config;

    //画出K线图的5条横线

    const split = this.mainChartHeight / 4;

    this.canvasCxt.beginPath();

    this.canvasCxt.lineWidth = 0.5;

    this.canvasCxt.strokeStyle = gridColor;

    for (let i = 0; i <= 4; i++) {

      const splitHeight = Math.floor(split * i) + lineMessageHeight!;

      this.drawLine(0, splitHeight, width, splitHeight);

    }

    //画出K线图的2条竖线

    this.drawLine(0, lineMessageHeight!, 0, lineMessageHeight! + this.mainChartHeight);

    this.drawLine(width, lineMessageHeight!, width, lineMessageHeight! + this.mainChartHeight);

    //画出成交量的矩形

    this.canvasCxt.strokeRect(

      0,

      height - xLabelHeight! - this.subChartHeight,

      width,

      this.subChartHeight,

    );

  }

  

  //画出两个点形成的直线

  private drawLine(x1: number, y1: number, x2: number, y2: number) {

    this.canvasCxt.moveTo(x1, y1);

    this.canvasCxt.lineTo(x2, y2);

    this.canvasCxt.stroke();

  }

画各类均线

1、首先计算出一屏的股价最大值 max ， 股价最小值 min ，成交量最大值 maxAmount。

2、当某一个点的均线为 value， 根据最大值、最小值、索引index， 计算出坐标点（x, y）, 画均线的时候， 第一个点用 moveTo(x0, y0)，其他点用 lineTo(xn yn), 最后 stroke 连起来即可。

3、当然， 每一条线设置下颜色， 即 stokeStyle。

  //画出各类均线

  private drawLines(max: number, min: number, maxAmount: number) {

    //将宽度分成n个小区间， 一个小区间画一个蜡烛， 每个区间的宽度是 splitW

    const splitW = this.config.width / this.config.lmt!;

    //画一下5日均线

    this.canvasCxt.beginPath();

    this.canvasCxt.strokeStyle = this.config.ma5Color;

    this.canvasCxt.lineWidth = 1;

    let isTheFirstItem = true;

    for (

      let i = this.startIndex;

      i < this.arrayList.length && i < this.startIndex + this.config.lmt!;

      i++

    ) {

      const index = i - this.startIndex;

      let value = this.arrayList[i].ju5;

      if (value === 0) {

        continue;

      }

      const x = Math.floor(index * splitW + 0.5 * splitW);

      const y = Math.floor(

        ((max - value) / (max - min)) * this.mainChartHeight + this.config.lineMessageHeight!,

      );

      if (isTheFirstItem) {

        this.canvasCxt.moveTo(x, y);

        isTheFirstItem = false;

      } else {

        this.canvasCxt.lineTo(x, y);

      }

    }

    this.canvasCxt.stroke();

  }

画出蜡烛柱体

 

当收盘价大于等于开盘价， 选用上面左边红色的样式； 当收盘价小于开盘价， 选用上面右边绿色的样式。

以红色蜡烛为例， 最高点 A(x0, y0)，最低点是 B(x1, y1)，
高度 height、宽度 width 都是相对于坐标轴的，
红色矩形左上角的顶点是 D(x, y)。

为了画出红色蜡烛， 先后顺序别搞混：

1. AB 这条竖线，通过 moveTo，lineTo 画出来；
2. 定义一个矩形 cxt.rect(x, y, width, heigth)；
3. 通过 fill 将矩形内部填充为白色， 这时候白色矩形会覆盖掉红色竖线的一部分；
4. 再通过 stroke 描出矩形的红色边框

按照上面这个顺序， 竖线会被覆盖掉一部分，同时，矩形内部的白色填充不会挤压矩形的红色边框， 如果先 stroke 再 fill，容易出现白色填充覆盖红色边框，矩形可能会变模糊，或者使得红色变淡，极其不友好，所以按照我上面的顺序，可以减少不必要的麻烦。

画出文字

canvas 画出文字， 典型的代码如下

 this.canvasCxt.beginPath();

    this.canvasCxt.font = `${this.config.yLabelFontSize}px "Segoe UI", Arial, sans-serif`;

    this.canvasCxt.textBaseline = 'alphabetic';

    this.canvasCxt.fillStyle = this.config.yLabelColor;

注意textBaseline 默认对齐方式是 alphabetic， 但 middle 往往更好用， 能实现垂直居中，但我发现垂直居中也不是很居中，所以会特意加减1、2个像素；

当然还有个textAlign， 能实现水平对齐方式， 左右对齐都可以， 例如上图最左、最右的时间标签。

七、交互设计

根据上面的GIF动图， 可以知道， 本次做的移动端 K 线图， 最重要的两个交互是：

1. 快速拖拽，K线图随时间轴左右滑动
2. 长按滑动，出现十字交叉tooltip

上面的交互，其实是比较复杂的，所以需要先设计一个简单的数据结构：

1. 首先页面存放一个列表 arrayList
2. 保存一个数字标识 startIndex，表示当前屏幕从 startIndex 开始画蜡烛图

当用户往右快速拖拽时， startIndex 根据用户拖拽的距离， 适当变小； 当用户往左快速拖拽时， startIndex 根据用户拖拽的距离， 适当变大。

那 arrayList 到底多长合适， 因为股票可能有十几年的数据， 甚至上百年的数据， 我不能一次性拉取这个股票的所有数据吧？

当然，站在软件性能、消耗等角度，也不应该一次性拉取所有的数据， 我的答案是 arraylist 最多保存5屏的数据量，用户看到的屏幕， 应该是接近中间这一屏，也就是第3屏的数据， 左右两边各保存2屏数据，这样，用户拖拽的时候，可以比较流畅，而不是每次拖拽都要等拉取数据再去渲染。

那什么时候拉取新的数据呢？ 用户触摸完后，当startIndex左边的数据少于2屏，开始拉取左边的数据； 用户触摸完后，当startIndex右边的数据少于2屏，开始拉取右边的数据；

那如果用户一直往右拖拽， 是不是就一直往左边添加数据， 这个 arraylist 是不是会变得很长？

当然不是，例如，当我往 arraylist 的左边添加数据的时候，startIndex 也会跟着变动， 因为用户看到的第一条柱体，在 arraylist 的索引已经变了。当我往 arraylist 的某一边添加数据后， arraylist 的另一边如果数据超过 2 屏， 要适当裁掉一些数据， 这样 arraylist 的总数， 始终保持在 5 屏左右，就不会占用太多的存放空间。

总体思想是， 从 startIndex 开始渲染屏幕的第一条柱体， 当前屏幕的左右两边， 都预留2屏数据，防止用户拖拽频繁调用接口， 导致卡顿； 同时也控制了 arraylist 的长度， 这是虚拟列表的变形，这样设计，可以做一个 高性能 的k线图。

八、触摸事件解耦

根据上面的分析：

1. 快速拖拽， K线图左右移动
2. 长按再滑动， 出现十字交叉tooltip

以上两种拖拽，都在 touchmove 事件中触发， 那怎么区分开呢？ 典型的 touchstart、 touchmove 、 touchend 解耦如下：

let timer = null;

let startX = 0;

let startY = 0;

let isLongPress = false;



canvas.addEventListener('touchstart', (e) => {

    startX = e.touches[0].clientX;

    startY = e.touches[0].clientY;

    isLongPress = false;

    

    timer = setTimeout(() => {

        isLongPress = true;

        // 显示十字光标hover

        showCrossHair(e);

    }, 500);

});



canvas.addEventListener('touchmove', (e) => {

    if (isLongPress) {

        // 长按移动时更新十字光标位置

        updateCrossHair(e);

    } else {

        // 快按拖动时移动K线图

        clearTimeout(timer);

        moveKLineChart(e);

    }

});



canvas.addEventListener('touchend', () => {

    clearTimeout(timer);

    if (isLongPress) {

        // 长按结束隐藏十字光标

        hideCrossHair();

    }

    isLongPress = false;

});



// 关闭十字光标

function hideCrossHair() {

    // 隐藏逻辑

}

根据上面的框架， 再详细补充下代码就可以了。 然后再在 touchend 事件中， 新增或减少 arraylist 的数据量。

九、性能优化

其实， 做到上面的设计，性能已经很好了，可以监控帧率来看下滑动的流畅程度。

总结下我做了什么操作，来提高整体的性能：

1、分层渲染

将K线图画在3个canvas上。

1. 不动层只需要绘画一次；
2. 变动层根据需要而变动；
3. 交互层独立出来，不会影响其它层，变动层的大量蜡烛柱体、均线等也不会受交互层的影响

2、离屏渲染

当需要在K线上标注一些icon时， 这些 icon 可以先离屏渲染， 需要的时候， 再copy到变动层对应的位置，这样比临时抱佛脚去画，要省很多时间，也能提高新能。

3、设置数据缓冲区

就是屏幕只渲染一屏数据， 但是在当前屏的左右两边，各缓存了2屏数据， 超过5屏数据的时候，及时裁掉多余的数据， 这样arraylist的数据量始终保持在5屏， 控制了数据量，有效的控制了占用空间。

4、节流防抖

touchmove 会很频繁触发， 可通过节流来控制，减少不必要的渲染。

十、部署到GitHub Pages

1、安装gh-pages包

npm install --save-dev gh-pages

2、package.json 添加如下配置

注意， Stock 这个需要对应github的仓库名

{

  "homepage": "https://fhrddx.github.io/Stock",

  "scripts": {

    "predeploy": "npm run build",

    "deploy": "gh-pages -d build"

  }

}

3、运行部署命令

npm run build

npm run deploy

最后， 访问上面的链接（注意，在国内可能要开vpn）

fhrddx.github.io/Stock/

这样， github pages 部署成功， 访问上面链接， 可以看到如下效果。

github page 的部署需要将仓库设置为 public， 这个我挺反感的， 可以用 vercel 部署， 也就是将 github 账号与 vercel 关联起来， 项目的 package.js 的 homepage 设置为 “.” ， 然后 vercel 可以点击一下， 一键部署， 常见的命令行如下：

# 1. 安装 Vercel CLI

npm install -g vercel



# 2. 在项目根目录登录 Vercel

vercel login



# 3. 部署项目

npm run build

vercel --prod



# 或者直接部署 build 文件夹

vercel --prod --build

作者：VincentFHR
来源：juejin.cn/post/7556154928059334666

一、前因后果

1.1 目的

起因是女朋友想做小红薯的账号。她每天会先把小故事写好复制到手机上，然后按照一定的图片规格一张张裁剪，最后发布到平台上。

接着我就在想，有没有什么高效的文本转成图片并且能够自动分页的方案呢？查了很久都没找到合适的方案，最后还是决定自己写一个转换工具。

1.2 需求

总结了一下我的场景，发现需求如下：

1. 能够内容转成指定尺寸的图片
2. 能够设置字体、背景、样式
3. 支持自动换行、自定义换行
4. 支持分页
5. 支持图片下载

根据输入文本，通过 Canvas 渲染

展示全部分页图片的内容，可以批量下载

1.3 思路

基于需求，最后决定采用 Canvas 的绘制方案。思路如下：

1. 根据输入文本，完成分行、分页的计算
2. 将分页数据绘制到 Canvas
3. 批量将 Canvas 的内容导出图片进行下载

1.4 难点

做的时候发现几个核心的问题难点，分别是换行、分页的问题。

I. 换行问题

在 canvas 中进行文本绘制不同于 HTML 标签，文本是不能自动换行的。所以这个需要自己去计算什么时候换行，在哪个字符段该换行。

II. 分页问题

当内容超出当前页了，我们希望能够自动进行分页，这个就需要去计算行高和页面内容区高度。

二、设计方案

下面介绍一下 Canvas 文本渲染器的设计方案。主要会围绕着文本计算、文本绘制、导出图片来讲解。

2.1 如何计算文本

计算文本主要做的事情就是，根据用户输入的文本和想要生成的图片、字体参数，来计算需要分多少页，每一页具体要展示多少行，每一行要展示多少内容。

I. 分词

要实现换行，就要知道一句话中从哪个分词开始是超出了当前行的最大宽度。这个分词可能是某个中文字符、某个英文单词、某串数字、某个其他字符等。

这里我们只讨论简单的中英文数字的场景

所以要做的第一步，就是将输入的文本拆解成一个个分词，然后去筛选掉空的字符。

核心代码如下：

II. 分行

现在已经将文本拆分成了足够细的分词。接下来要做的就是将每个分词不断地塞入每一行中。

你可以把每一行理解成一个固定宽度的容器，一但某个分词塞不进了，就得创建一个新的容器再把这个分词塞进去。

所这个遍历的过程，需要知道行的最大宽度以及当前分词的真实宽度。最大宽度的计算规则，根据用户设置的页面宽度减去左右边距的宽度，就是内容区的最大行宽度。

代码如下：

分词的真实宽度则是用 canvas 中的 measureText 来测量字符串的宽度。

接下来就是一个累加的过程。把分词加入当前行，判断是否超出最大宽度，如果超出就新起一行。

最后遍历完后就会得出所有的分行内容。

上面是分行大致的思路，但在实际的代码实现上，会随着分词类型、换行需求的增加变得更加复杂。例如：

1. 英文单词前面需要追加空格

2. 用户想自定义空行逻辑：匹配到句号自动换行并且空一行。

III. 分页

有了分行的数据，就可以进行分页了。其实逻辑差不多，只不过一个是横向，一个是纵向。把每个页当成一个固定高度的容器，不断的把行塞进去，塞不进就新起一个页容器。

这个遍历的过程需要知道页面内容区的最大高度以及每一行的行高。行高一般是用户设置的，所以只需关注页面内容区的最大高度的计算规则。

代码如下：

分页计算流程，遍历 lines 把分行不断塞入当前页。如果超出高度就放到新的页面。最后就会得出所有分页的数据。

2.2 如何绘制

有了分页数据以后，绘制主要做的事情就是根据用户设置的样式（页面边距、字体和背景）来渲染每一页具体的内容。

I. 指定图片尺寸

通过设置 Canvas 画布的大小即可。

II. 绘制背景

背景直接通过 fillRect 绘制即可

III. 绘制内容

绘制内容的时候，主要考虑两个点：

1. 设置字体样式
2. 根据边距、行高计算每行绘制的位置

2.3 如何导出图片

导出图片就是将 Canvas 上的内容转成 DataURL 然后下载成图片

三、最后

基于上面的思路，你不仅仅可以开发一个简单的文本渲染器，你甚至可以做一个复杂的编辑器哦~

最后我将这个工具封装成了一个 npm 库，直接导入这个库就可以完成文本到图片的一个转换了。

如果感兴趣，完整代码放置在 GitHub 了：github.com/zixingtangm…

作者：唐某人丶
来源：juejin.cn/post/7485758756911857683

故事背景：

“协程奶茶连锁店” 生意火爆，总部为了高效管理，设立了 4 个核心部门，每个部门负责不同类型的任务，且有严格的 “上下班时间”（生命周期）：

• 总公司长期项目组（GlobalScope） ：负责跨门店的长期任务（如年度供应链优化），除非主动停掉，否则一直运行。
• 前台接待组（MainScope） ：负责门店前台的即时服务（如点单、结账），必须在前台营业时间内工作，打烊时全部停手。
• 后厨备餐组（ViewModelScope） ：配合前台备餐，前台换班（ViewModel 销毁）时，未完成的备餐任务必须立刻停掉。
• 临时促销组（LifecycleScope） ：负责门店外的临时促销，摊位撤掉（Activity/Fragment 销毁）时，促销活动马上终止。

这些部门本质上都是CoroutineScope，但因 “职责” 不同，它们的coroutineContext（核心配置）和 “生命周期触发条件” 不同。下面逐个拆解：

一、总公司长期项目组：GlobalScope

部门特点：

• 任务周期长（可能跨多天），不受单个门店生命周期影响。
• 没有 “自动下班” 机制，必须手动终止，否则会一直运行（可能 “加班摸鱼” 导致资源浪费）。

代码里的 GlobalScope：

import kotlinx.coroutines.GlobalScope

import kotlinx.coroutines.delay

import kotlinx.coroutines.launch



fun main() = runBlocking {

    // 启动总公司的长期任务（优化供应链）

    GlobalScope.launch {

        repeat(10) { i -> // 模拟10天的任务

            println("第${i+1}天：优化供应链中...")

            delay(1000) // 每天做一点

        }

    }



    // 模拟门店只观察3天就关门

    delay(3500)

    println("门店关门了，但总公司任务还在跑...")

}

运行结果：

第1天：优化供应链中...

第2天：优化供应链中...

第3天：优化供应链中...

门店关门了，但总公司任务还在跑...

第4天：优化供应链中...

// 即使主线程结束，任务仍在后台运行（直到JVM退出）

实现原理：

GlobalScope的coroutineContext是固定的：

object GlobalScope : CoroutineScope {

    override val coroutineContext: CoroutineContext

        get() = Dispatchers.Default + SupervisorJob()

}

• Dispatcher.Default：默认在后台线程池执行（适合计算密集型任务）。
• SupervisorJob() ：特殊的 “组长”，它的子任务失败不会影响其他子任务（比如某个门店的供应链优化失败，不影响其他门店），且没有父 Job（所以不会被其他 Scope 取消）。

为什么少用？

就像总公司的长期任务如果不手动停，会一直占用人力物力，GlobalScope启动的协程如果忘记取消，会导致内存泄漏（比如 Android 中 Activity 销毁后，协程还在访问已销毁的 View）。

二、前台接待组：MainScope

部门特点：

• 只在前台营业时间工作（比如门店 9:00-21:00），负责和顾客直接交互（必须在主线程执行）。
• 打烊时（手动调用cancel()），所有接待任务立刻停止。

代码里的 MainScope：

import kotlinx.coroutines.MainScope

import kotlinx.coroutines.delay

import kotlinx.coroutines.launch

import kotlinx.coroutines.runBlocking



fun main() = runBlocking {

    // 创建前台接待组（指定在主线程工作）

    val frontDeskScope = MainScope()



    // 启动接待任务：点单、结账

    frontDeskScope.launch {

        println("开始点单（线程：${Thread.currentThread().name}）")

        delay(1000) // 模拟点单耗时

        println("点单完成，开始结账")

    }



    // 模拟21:00打烊

    delay(500)

    println("前台打烊！停止所有接待任务")

    frontDeskScope.cancel() // 手动取消

}

运行结果：

开始点单（线程：main） // 确保在主线程执行

前台打烊！停止所有接待任务

// 后续“结账”不会执行，因为被取消了

实现原理：

MainScope的coroutineContext是：

fun MainScope(): CoroutineScope = CoroutineScope(SupervisorJob() + Dispatchers.Main)

• Dispatchers.Main：强制在主线程执行（Android 中对应 UI 线程，确保能更新 UI）。
• SupervisorJob() ：子任务失败不影响其他任务（比如一个顾客点单失败，不影响另一个顾客结账）。
• 手动取消：必须通过scope.cancel()触发（比如 Android 中在onDestroy调用）。

三、后厨备餐组：ViewModelScope

部门特点：

• 专门配合前台备餐，前台换班（ViewModel 被销毁）时，自动停止所有备餐任务（避免 “给已走的顾客做奶茶”）。

代码里的 ViewModelScope（Android 场景）：

import androidx.lifecycle.ViewModel

import androidx.lifecycle.viewModelScope

import kotlinx.coroutines.delay

import kotlinx.coroutines.launch



class TeaViewModel : ViewModel() {

    fun startPrepareTea() {

        // 后厨备餐任务（自动绑定ViewModel生命周期）

        viewModelScope.launch {

            println("开始备餐：煮珍珠...")

            delay(2000) // 模拟备餐耗时

            println("备餐完成！")

        }

    }



    // ViewModel销毁时（如Activity.finish），系统自动调用

    override fun onCleared() {

        super.onCleared()

        println("前台换班，后厨停止备餐")

    }

}

实现原理：

viewModelScope是 ViewModel 的扩展属性，其coroutineContext为：

val ViewModel.viewModelScope: CoroutineScope

    get() = CoroutineScope(ViewModelCoroutineScope.DispatcherProvider.main + job)

• Dispatcher.Main：默认在主线程（也可指定其他线程）。
• 内部 Job：和 ViewModel 绑定，当 ViewModel 的onCleared()被调用时，这个 Job 会自动cancel()，所有子协程随之终止。

四、临时促销组：LifecycleScope

部门特点：

• 在门店外的临时摊位工作，摊位撤掉（Activity/Fragment 销毁）时，自动停止所有促销活动。

代码里的 LifecycleScope（Android 场景）：

import androidx.fragment.app.Fragment

import androidx.lifecycle.lifecycleScope

import kotlinx.coroutines.delay

import kotlinx.coroutines.launch



class PromotionFragment : Fragment() {

    override fun onStart() {

        super.onStart()

        // 临时促销任务（自动绑定Fragment生命周期）

        lifecycleScope.launch {

            println("开始促销：发传单...")

            delay(3000) // 模拟促销耗时

            println("促销结束！")

        }

    }



    // Fragment销毁时，系统自动触发

    override fun onDestroy() {

        super.onDestroy()

        println("摊位撤掉，促销停止")

    }

}

实现原理：

lifecycleScope是LifecycleOwner（如 Activity/Fragment）的扩展属性，其coroutineContext为：

val LifecycleOwner.lifecycleScope: CoroutineScope

    get() = lifecycle.coroutineScope

• 内部关联Lifecycle，当生命周期走到ON_DESTROY时，自动调用cancel()。
• 默认使用Dispatchers.Main，确保能更新 UI（如更新促销进度）。

五、各 Scope 的生命周期时序图

1. GlobalScope 时序图（无自动取消）

┌───────────┐      ┌─────────────┐      ┌───────────┐

│  用户代码  │      │ GlobalScope │      │  子协程   │

└─────┬─────┘      └───────┬─────┘      └─────┬─────┘

      │                    │                  │

      │ launch协程         │                  │

      ├───────────────────>│                  │

      │                    │ 启动子协程        │

      │                    ├─────────────────>│

      │                    │                  │ 执行中...

      │                    │                  │<─────┐

      │ (无自动取消)       │                  │      │

      │                    │                  │      │

      │ (需手动cancel)     │                  │      │

      │ (否则一直运行)     │                  │      │

2. ViewModelScope 时序图（ViewModel 销毁时取消）

┌─────────────┐      ┌────────────────┐      ┌───────────┐

│   ViewModel  │      │ ViewModelScope │      │  子协程   │

└───────┬─────┘      └───────┬────────┘      └─────┬─────┘

        │                    │                     │

        │ 初始化scope        │                     │

        ├───────────────────>│                     │

        │                    │                     │

        │ launch协程         │                     │

        ├───────────────────>│                     │

        │                    │ 启动子协程           │

        │                    ├────────────────────>│

        │                    │                     │ 执行中...

        │                    │                     │

        │ onCleared()触发    │                     │

        ├───────────────────>│                     │

        │                    │ 调用Job.cancel()    │

        │                    ├────────────────────>│

        │                    │                     │ 终止执行

        │                    │                     │<─────┐

3. LifecycleScope 时序图（ON_DESTROY 时取消）

┌─────────────┐      ┌────────────────┐      ┌───────────┐

│  Activity   │      │ LifecycleScope │      │  子协程   │

└───────┬─────┘      └───────┬────────┘      └─────┘─────┘

        │                    │                     │

        │ 初始化scope        │                     │

        ├───────────────────>│                     │

        │                    │                     │

        │ launch协程         │                     │

        ├───────────────────>│                     │

        │                    │ 启动子协程           │

        │                    ├────────────────────>│

        │                    │                     │ 执行中...

        │                    │                     │

        │ 生命周期到ON_DESTROY│                     │

        ├───────────────────>│                     │

        │                    │ 调用Job.cancel()    │

        │                    ├────────────────────>│

        │                    │                     │ 终止执行

        │                    │                     │<─────┐

总结：选对 Scope，就像找对部门

Scope 类型	生命周期绑定	核心配置（coroutineContext）	适用场景
GlobalScope	无（需手动取消）	Dispatchers.Default + SupervisorJob	跨组件的长期任务（谨慎使用）
MainScope	手动控制	Dispatchers.Main + SupervisorJob	顶层 UI 组件（如 Application）
ViewModelScope	ViewModel.onCleared	Dispatchers.Main + 内部 Job	配合 ViewModel 的备餐 / 数据请求
LifecycleScope	Activity/Fragment 销毁	Dispatchers.Main + Lifecycle 关联 Job	临时 UI 任务（如促销、弹窗倒计时）

记住：Scope 的本质是给协程找个 “归属”，让协程在合适的时间开始，在该结束的时候乖乖结束，避免 “野协程” 捣乱～

作者：Android童话镇
来源：juejin.cn/post/7563197374418157604

找对象真的太难了，我不由地发出这个感慨

但其实说着也奇怪，明明我每天两点一线，上班了去工位、下班了回宿舍，根本没有其他社交，但我为什么会发出这样的感慨呢？

• 是因为总是在无聊时感到了孤独才希望有个伴，还是看见大家都有伴了才觉得自己孤独？


• 是因为看到了别人功成名就家庭和谐的嫉妒，还是吊儿郎当无所事事地调侃？


• 是因为信息茧房导致我对婚姻产生了偏见而刻意疏远，还是无能狂怒般自卑不敢去尝试？


• ……

如果是针对我个人的话，那应该是自卑了吧。这辈子30多年没什么情感经历，就只有一次相亲后“交往”的经验。那次相亲后异地聊了9个月，中间节假日只有我回去见了3次面，没有矛盾，每天都在线上花个两三个小时也都聊得很开心，但我却总觉得彼此都像个不熟的人，以至于最后“分手”时内心也毫无波澜。

“或许我根本不需要为了找个伴才选择想找对象吧。”我总是这样安慰自己，其实安慰的次数不多，因为我没有经常想。

我每天两点一线的生活很规律，很轻松，最重要的是，我已经非常习惯了。所以从某种程度来讲，“客观上”，我并没有真的想找对象、也没有主动去尝试结交新朋友，“主观上”，现在的社会风向和经济形势，不太利于我尝试告别单身，即便 A 股沪指最近持续性突破十年新高。

光是想，不去做，那可不就是“太难了”。

其实，有那么一瞬间我也想结婚

可怜的是，这并不是基于我个人的想法，而是外界的干扰。我记得我31岁生日那天，凌晨6点过还在睡梦中，外公外婆就打来电话，祝我生日快乐。我很诧异，因为我没想到农忙时节呢，他们还没忙忘了，也因为居然这么早，鸡鸭才刚叫。然后一如既往地说：不要太节约了，吃点好的，照顾好自己……然后，快点找对象，天天瞌睡都睡不好，揪心得很哦。结了婚他们就放心了，不然他们死了都不安心哦。

或许80多岁的老人家觉得，任何事情，只要你想要，那就能发生。我想要天上掉金子，天上就会掉金子；我想要地里喷石油，地里就会喷石油；我想要找对象，自然就有对象……

我倒是习以为常了，只不过那一整天，就没有第二个人祝我生日快乐了。不管是朋友同事，还是父母亲戚，即便是早我一天过生日、而我在生日前一天给她发去生日祝福的堂姐，都没有。

其实我也是习以为常了，可能因为我的生日也是我爷爷的忌日，我总是刻意淡忘它，大部分时候过生日我自己都会忘记，10岁之后就没有任何一次庆祝生日的行为——10岁那年父母要都外出打工，自此再次成为留守儿童。

但今年有那么一瞬间，突然觉得难得只有两个80多岁的老人还记得我生日，一直让他们失望有点于心不忍，更何况，正常来讲，我还能“忤逆”他们多少年呢？

可惜的是，就和那些贩卖焦虑的短视频、营销号一样，总是提出问题、夸大问题、制造矛盾、激化矛盾，但从来不会提供解决方法一样：想结婚了，然后呢？

独身一人在无聊的时候确实是无聊的

最近不知道是上班天天盯着电脑看久了，还是下班游戏玩多了，眼睛特别酸痛，于是我难得的又在下班之后出去逛了逛。

正常的话吃了饭我就玩游戏了，先玩几把NBA 2K，再玩几把英雄联盟手游，再玩几把王者荣耀。

其实曾几何时，我从生理上都厌恶王者荣耀的，因为它把很多中国历史人物文化名人，搞成游戏中乱七八糟的角色，让我无法接受。以至于这么多年来，从同学同事、到堂表兄弟等，都没有机会跟我一起玩。

我也没想到我居然突然之间就接受了，即便这曾经让我生理上讨厌的东西。我记得很清楚，2025年7月2日，我新历生日那天，我下载了王者荣耀，建立了账号，开始游玩，持续十几天有空就一直在玩，一百来把、十几级的账号打到最低等级的王者段位，觉得差不多入门了，想着和老同学、老朋友、老同事们一起玩时，才发现他们都不上线了。或许，随着年龄的增长，这种“年轻时的生理厌恶”都敌不过“无聊时的孤单寂寞”。

所以每次当我一个人出去小道散步闲逛消磨时间时，总会特别在意那些跑步锻炼身体的人、散步话家常的两公婆、坐在摊位小车后面玩手机的摆摊老板……感觉他们都有目的地在做什么，而只有我在漫无目的地走着。

其实这条路我之前走过，至少在我今年生日之前，只不过那个时候，这马路边的行人道，没有这么多杂草、灌木。就像人生路，总是在回忆的时候，才觉得曾经如此宽阔，才懊悔当时未曾踏入。可是，时光一直向前流逝，回忆永远迭代更新。

可能现在生活没有达到预期的我们总是有这样的想法，要是能回到过去就好了。实际上只是想带着现在的记忆回到过去，去弥补一些错过或者错误。似乎真像有多元宇宙，回到过去之后会有新的时间线，补足那些遗憾，每一次的回溯，终究会得到一条完美符合心意的时间线。实际上我觉得，即便我们能回到过去，那也是会失去所有记忆，然后完完整整重复之前做过的事情，又一次的错过或者错误，不会有多条时间线，即便你回去再多次，都只会重复同样的事情，都只是同一条时间线。但只有这一条时间线，其实也就够了。

正因为消极，所以才乐观

其实我一直是希望传播积极乐观心态的，从我以往的文章总能看到有这样的痕迹。但就像那些奢侈品广告一样：你买得起不重要，你买不起才重要。

就像我当年创业板3600多点最高峰买入了很多和创业板强关联基金一样，那时总觉得中国经济一定是蒸蒸日上，最后一路跌倒了1500点，一点点割肉，最后全盘清掉，赔了一些钱，然后不敢再入场。所以我也没赶上或者说是错过了今年大半年的牛市，有点难受。与之相对的，为了求稳买入了大量的债券，却债市正熊，又套在手里，更难受了。

可能这都不是什么大事，毕竟只是对我造成了一些经济损失，并不会影响到我的一如既往平凡普通的物质生活；但是焦虑、担忧、烦闷的心态，却非常影响我的精神状态，严重损坏我本就低迷的精神生活。

我一直有个想法，希望尽量在35岁前能多攒一些钱，这样如果35岁之后某天丢了工作，我就徒步去环游中国。并不是他们那种雄心壮志地环游，什么“朝圣“”啊、“远离浮躁净化心灵”啊。就跟平时一样，大街小巷，散步流浪，随便走走看看，不过变成了走到哪里黑，就到哪里歇。等到钱花光了，人老了走不动，客死他乡，也算得偿所愿了。

如果真的能到这个时候，身后没有拖拽、肩上没有负担，该是多么舒服的境况。

发现了吗，其实我就是这么矛盾，一方面安慰自己钱财乃身外物，不必强求；另一方面又觉得钱财乃必需品，多多益善。原因非常简单，因为我缺这东西，所以看得很重；又因为没本事挣到更多，所以才安慰自己它不重要。

这就是别人说的，看清问题根源比无法解决问题更让人窒息，也就是“无知是福”或者”无知者无畏”的感悟了。

每个人都应该有自己的活法，即便大同小异

正如写代码的人，总是会重复造轮子，偶尔还会乐此不疲。世上的人这么多，大部分的人的都是千篇一律的，事实上，大家都在做的事情，说不定才是对的。大家都重复着读书、工作、结婚、生子、工作、退休、等死的生活，正是因为在和平年代这就是一个非常典型且应该让人轻松愉悦、容易接受的平凡人的人生。

同样功能、完全适配你项目的工具包，一个周下载几百万、上次更新1个月前，一个周下载几十、上次更新5年前，只考虑下载使用的话，你会怎么选呢？

就像正因为他是魔丸才敢高喊“我命由我不由天”，就像有人说对钱不感兴趣；也就像也有人觉得“奋斗用多大劲啊？”就像我以为“忠诚的不绝对就是绝对的不忠诚”只是一个战锤40K的梗而已……这个世界本来就因为科技发展而不断更新，止不住的时代洪流，纷纷扰扰的世界，何必太关注别人关心的事情，兜兜转转可能发现，你特别在意的东西别人根本没放在心上，你漫不经心地言语却刺穿了别人的心脏。所有的一切，在心脏停止跳动之前，其实都无关紧要；而在心脏停止跳动之后，更是毫无意义。

所以我平时有空的时候，也会更新一下我 Github 仓库中几个开源的小项目，虽然没什么技术含量，还借助了很多AI辅助编码，但我在写完测试完成之后的那一刻感觉很舒服，就算之后很久都没再更新、测试，还发现了bug，但那完成时的一瞬间很舒服，就成了我持续不断更新的主观能动性之一。

人总有一死，我一直强调不要太在意他人的眼光，为自己而生活。但如果你根本不知道自己想要过什么样的人生，那么从众并不是什么丢人的行为。 人生短暂，不值得斤斤计较，浪费也是它应该存在的过程片段。

坐在厂门口的女子

我今天出去散步的时候，经过了隔壁厂，恰巧看到一位女士蹲在门口马路牙子上，左手拿着装炸土豆片套着塑料袋的小盒子，右手拿着手机看小说。我在外面溜达了个把小时，回去的时候发现她还蹲着那马路牙子上，可能是同一个位置，只不过只有右手拿着手机继续看着小说。

但我猜测她“可能”并没有一直蹲着那里看小说，因为那装炸土豆片的小纸盒没有在她左手上继续拿着，也没有放在她的身旁……

为什么只是“猜测和可能”呢？谁知道呢，或许她站起来走几步丢到垃圾桶后又蹲回去了，或许只是她吃完了空纸盒子放在旁边被风吹走了；或许她没吃完揉吧揉吧纸盒子随手丢到马路对面去了，又或许甚至可能她变身奥特曼打走了怪兽又变回正常人继续在厂门口看小说了……

如果不是因为间隔这么久，看见她还呆在同一个位置，我可能根本就没在意。就像如果不是出来工作了10年依旧还在原地，我也不必过度“揣摩自己”。

可能因为总是太在意，所以才觉得一切都太难了…… 毕竟“得不到的永远在骚动……”

很难了，一个陌生人有两次遇到的机会。

多数情况下都只有一次机会。换成是我，如果我一开始也是蹲在厂门口的马路牙子上，估计没人会注意到。但我要是一开始就跪在厂门口不停在磕头，说不定就有人会注意到了……

结尾

哈哈，Gotcha！要不是我这几天玩游戏多了眼睛有点酸痛，需要休息一下，我才不会在这里长篇大论无病呻吟呢，都这么久没有更新了是吧，那我玩游戏看视频啥的时可是乐在其中、忘乎所以的，佝偻成一团都还在哈哈大笑呢。

所以，赶紧去做那些让你自己开心的事情吧，享受生活，这才是我们活着的原因之一，其他的事情，fxxk off。

什么是联合索引？

首先，要理解最左匹配原则，得先知道什么是联合索引。

• 单列索引：只针对一个表列创建的索引。例如，为 users 表的 name 字段创建一个索引。


• 联合索引：也叫复合索引，是针对多个表列创建的索引。例如，为 users 表的 (last_name, first_name) 两个字段创建一个联合索引。

这个索引的结构可以想象成类似于电话簿或字典。电话簿是先按姓氏排序，在姓氏相同的情况下，再按名字排序。你无法直接跳过姓氏，快速找到一个特定的名字。

什么是最左匹配原则？

最左匹配原则指的是：在使用联合索引进行查询时，MySQL/SQL数据库从索引的最左前列开始，并且不能跳过中间的列，一直向右匹配，直到遇到范围查询（>、<、BETWEEN、LIKE）就会停止匹配。

这个原则决定了你的 SQL 查询语句是否能够使用以及如何高效地使用这个联合索引。

核心要点：

举例说明

假设我们有一个 users 表，并创建了一个联合索引 idx_name_age，包含 (last_name, age) 两个字段。

索引 idx_name_age 在磁盘上大致是这样排序的（先按 last_name 排序，last_name 相同再按 age 排序）：

(Li, 30) (Wang, 20) (Wang, 22) (Zhang, 25) (Zhang, 28)

现在，我们来看不同的查询场景：

✅ 场景一：完全匹配最左列

SELECT * FROM users WHERE last_name = 'Wang';

• 分析：查询条件包含了索引的最左列 last_name。


• 索引使用情况：✅ 可以使用索引。数据库可以快速在索引树中找到所有 last_name = 'Wang' 的记录（(Wang, 20) 和 (Wang, 22)）。

✅ 场景二：匹配所有列

SELECT * FROM users WHERE last_name = 'Wang' AND age = 22;

• 分析：查询条件包含了索引的所有列，并且顺序与索引定义一致。


• 索引使用情况：✅ 可以高效使用索引。数据库先定位到 last_name = 'Wang'，然后在这些结果中快速找到 age = 22 的记录。

✅ 场景三：匹配最左连续列

SELECT * FROM users WHERE last_name = 'Zhang';

• 分析：虽然只用了 last_name，但它是索引的最左列。


• 索引使用情况：✅ 可以使用索引。和场景一类似。

❌ 场景四：跳过最左列

SELECT * FROM users WHERE age = 25;

• 分析：查询条件没有包含索引的最左列 last_name。


• 索引使用情况：❌ 无法使用索引。这就像让你在电话簿里直接找所有叫“伟”的人，你必须翻遍整个电话簿，也就是全表扫描。

⚠️ 场景五：包含最左列，但中间有断档

-- 假设我们有一个三个字段的索引 (col1, col2, col3) -- 查询条件为 WHERE col1 = 'a' AND col3 = 'c';

• 分析：虽然包含了最左列 col1，但跳过了 col2 直接查询 col3。


• 索引使用情况：✅ 部分使用索引。数据库只能使用 col1 来缩小范围，找到所有 col1 = 'a' 的记录。对于 col3 的过滤，它无法利用索引，需要在第一步的结果集中进行逐行筛选。

⚠️ 场景六：最左列是范围查询

SELECT * FROM users WHERE last_name > 'Li' AND age = 25;

• 分析：最左列 last_name 使用了范围查询 >。


• 索引使用情况：✅ 部分使用索引。数据库可以使用索引找到所有 last_name > 'Li' 的记录（即从 Wang 开始往后的所有记录）。但是，对于 age = 25 这个条件，由于 last_name 已经是范围匹配，age 列在索引中是无序的，因此数据库无法再利用索引对 age 进行快速筛选，只能在 last_name > 'Li' 的结果集中逐行检查 age。

总结与最佳实践

最左匹配原则的本质是由索引的数据结构（B+Tree） 决定的。索引按照定义的字段顺序构建，所以必须从最左边开始才能利用其有序性。

如何设计好的联合索引？

CoroutineScope 与 CoroutineContext 的概念

CoroutineContext (协程上下文)

CoroutineContext 是协程上下文，包含了协程运行时所需的所有信息。

比如：

• 管理协程流程（生命周期）的 Job。


• 管理线程的 ContinuationInterceptor，它的实现类 CoroutineDispatcher 决定了协程所运行的线程或线程池。

CoroutineScope (协程作用域)

CoroutineScope 是协程作用域，它通过 coroutineContext 属性持有了当前协程代码块的上下文信息。

比如，我们可以获取 Job 和 ContinuationInterceptor 对象：

fun main() = runBlocking<Unit> {

    val scope = CoroutineScope(EmptyCoroutineContext) // scope 并没有持有已有协程的上下文

    val outerJob = scope.launch {

        val innerJob = coroutineContext[Job]

        val interceptor = coroutineContext[ContinuationInterceptor]

        println("job: $innerJob, interceptor: $interceptor")

    }



    outerJob.join()

}

CoroutineScope 的另一个作用就是提供了 launch 和 async 协程构建器，我们可以通过它来启动一个协程。

这样，新创建的协程能够自动继承 CoroutineScope 的 coroutineContext。比如利用 Job，可以建立起父子关系，从而实现结构化并发。

GlobalScope

GlobalScope 是一个单例的 CoroutineScope 对象，所以我们在任何地方通过它来启动协程。

它的第二个特点是，它的 coroutineContext 属性是 EmptyCoroutineContext，也就是说它没有内置的 Job。

@DelicateCoroutinesApi

public object GlobalScope : CoroutineScope {

    /**

     * Returns [EmptyCoroutineContext].

     */

    override val coroutineContext: CoroutineContext

        get() = EmptyCoroutineContext

}

即使是我们手动创建的 CoroutineScope，其内部也是有 Job 的。

// 手动创建 CoroutineScope

CoroutineScope(EmptyCoroutineContext)



// CoroutineScope.kt

@Suppress("FunctionName")

public fun CoroutineScope(context: CoroutineContext): CoroutineScope =

    ContextScope(if (context[Job] != null) context else context + Job()) // 自动创建Job对象

所以我们在 GlobalScope.coroutineContext 中是获取不到 Job 的：

@OptIn(DelicateCoroutinesApi::class)

fun main() = runBlocking<Unit> {

    val job: Job? = GlobalScope.coroutineContext[Job]

    if (job == null) {

        println("job is null")

    }

    try {

        val jobNotNull: Job = GlobalScope.coroutineContext.job

    } catch (e: IllegalStateException) {

        println("job is null, exception is: $e")

    }

}

运行结果：

job is null

job is null, exception is: java.lang.IllegalStateException: Current context doesn't contain Job in it: EmptyCoroutineContext

那么，这有什么用吗？

其实，GlobalScope 所启动的协程没有父 Job。

这就意味着：

• 当前协程不和其他 Job 的生命周期绑定，比如不会随着某个界面的关闭而自动取消。


• 它是顶级协程，生命周期默认为整个应用的生命周期。


• 它发生异常，并不会影响到其他协程和 GlobalScope。反之，GlobalScope 本身也无法级联取消所有任务，因为它所启动的协程是完全独立的。

总结：GlobalScope 就是用来启动那些不与组件生命周期绑定，而是与整个应用生命周期保持一致的全局任务，比如一个日志上报任务。

关键在使用时，可能会有资源泄露的风险，需要正确管理好协程的生命周期。

Context 的三个实用工具

在挂起函数中获取 CoroutineContext

如果我们要在一个挂起函数中获取 CoroutineContext，我们不得不给将其作为 CoroutineScope 的扩展函数。

suspend fun CoroutineScope.printContinuationInterceptor() {

    delay(1000)

    val interceptor = coroutineContext[ContinuationInterceptor]

    println("interceptor: $interceptor")

}

但我们知道挂起函数的外部一定有协程存在，所以是存在 CoroutineContext 的。为此，Kotlin 协程库提供了一个顶层的 coroutineContext 属性，这个属性的 get() 函数是一个挂起函数，它能在任何挂起函数中访问到当前正在执行的协程的 CoroutineContext。

import kotlin.coroutines.coroutineContext



suspend fun printContinuationInterceptor() {

    delay(1000)

    val interceptor = coroutineContext[ContinuationInterceptor]

    println("interceptor: $interceptor")

}

另外，还有一个 currentCoroutineContext() 函数也能获取到 CoroutineContext，它内部实现也是 coroutineContext 属性。

为什么需要这个函数？

为了解决命名冲突，比如下面这段代码。

private fun mySuspendFun() {

    flow<String> {

        // 顶层属性

        coroutineContext 

    }



    GlobalScope.launch {

        flow<String> {

            // this 的成员属性优先级高于顶层属性

            // 所以是外层 launch 的 CoroutineScope 的成员属性 coroutineContext

            coroutineContext

        }

    }

}

在这种情况下，如果需要明确属性的源头，就需要使用 currentCoroutineContext() 函数，它会调用到那个顶层的属性。

CoroutineName 协程命名

CoroutineName 是一个协程上下文信息，我们可以使用它来给协程设置一个名称。

fun main() = runBlocking<Unit> {

    val scope = CoroutineScope(EmptyCoroutineContext)

    val name = CoroutineName("coroutine-1")

    val job = scope.launch(name) {

        val coroutineName = coroutineContext[CoroutineName]

        println("current coroutine name: $coroutineName")

    }



    job.join()

}

运行结果：

current coroutine name: CoroutineName(coroutine-1)

它主要用于测试和调试，你可以使用它来区分哪些日志是哪个协程打印的。

自定义 CoroutineContext

如果我们要给协程附加一些功能，我们可以考虑自定义 CoroutineContext。

如果是简单的标记，可以优先考虑使用 CoroutineName。

自定义 CoroutineContext 需要实现 CoroutineContext.Element，并且提供 Key。为此，Kotlin 协程库提供了 AbstractCoroutineContextElement 来简化这个过程。我们只需这样，即可创建一个用于协程内部记录日志的 Context：

// 继承 AbstractCoroutineContextElement，并把 Key 传给父构造函数

class CoroutineLogger(val tag: String) : AbstractCoroutineContextElement(CoroutineLogger) {



    // 声明专属的 Key

    companion object Key : CoroutineContext.Key<CoroutineLogger>



    // 添加专属功能

    fun log(message: String) {

        println("[$tag] $message")

    }

}

使用示例：

fun main() = runBlocking<Unit> {

    val scope = CoroutineScope(Dispatchers.Default)

    val job = scope.launch(CoroutineLogger("Test")) {

        val logger = coroutineContext[CoroutineLogger]

        logger?.log("Start")

        delay(5000)

        logger?.log("End")

    }

    job.join()

}

运行结果：

[Test] Start

[Test] End

coroutineScope() 与 withContext()

coroutineScope 串行的异常封装器

coroutineScope 是一个挂起函数，它会挂起当前协程，直到执行完内部的所有代码（包括会等待内部启动的所有子协程执行完毕），最后一行代码的执行结果会作为函数的返回值。

coroutineScope 会创建一个新的 CoroutineScope，在这个作用域中执行 block 代码块。并且这个作用域严格继承了父上下文（coroutineContext），并会在内部创建一个新的 Job，作为父 Job 的子 Job。

coroutineScope 从效果上来看，和 launch().join() 类似。

那么，它的应用场景是什么？

它的应用场景由它的特性决定，有两个核心场景：

withContext 串行的上下文切换器

我们再来看 withContext，其实它和 coroutineScope 几乎一样。

它也是一个串行的挂起函数，也会返回代码块的结果，内部也是启动了一个新的协程。

它和 coroutineScope 的唯一的不同是，withContext 允许我们传递上下文。你也可以这么想，coroutineScope 就是一个不改变任何上下文的 withContext：

withContext(EmptyCoroutineContext) { // 沿用旧的 CoroutineContext



}



withContext(coroutineContext) { // 使用旧的 CoroutineContext



}

而 withContext 的使用场景就很清楚了，我们需要切换上下文的时候会使用它，并且希望代码是串行执行的，之后还能再切回原来的线程继续往下执行。

虽然 withContext 与 coroutineScope 类似，但 coroutineScope 更多用于封装业务异常。

suspend fun getUserProfile() {

    // 当前在 Dispatchers.Main

    val profile = withContext(Dispatchers.IO) {

        // 自动切换到 IO 线程

        Thread.sleep(3000) // 耗时操作

        "the user profile"

    }



    // 自动切回 Dispatchers.Main

    println("the user profile is $profile")

}

CoroutineContext 的加、取操作

加法：合并与替换

两个 CoroutineContext 相加调用的是 plus()。

public operator fun plus(context: CoroutineContext): CoroutineContext =

    if (context === EmptyCoroutineContext) this else // fast path -- avoid lambda creation

        context.fold(this) { acc, element ->

            val removed = acc.minusKey(element.key)

            if (removed === EmptyCoroutineContext) element else {

                // make sure interceptor is always last in the context (and thus is fast to get when present)

                val interceptor = removed[ContinuationInterceptor]

                if (interceptor == null) CombinedContext(removed, element) else {

                    val left = removed.minusKey(ContinuationInterceptor)

                    if (left === EmptyCoroutineContext) CombinedContext(element, interceptor) else

                        CombinedContext(CombinedContext(left, element), interceptor)

                }

            }

        }

其中关键在于 CombinedContext，它是 CoroutineContext 的实现类：

// CoroutineContextImpl.kt

@SinceKotlin("1.3")

internal class CombinedContext(

    private val left: CoroutineContext,

    private val element: Element // Element 也是 `CoroutineContext` 的实现类

) : CoroutineContext, Serializable 

它会将操作符两边的上下文使用 CombinedContext 对象包裹（合并），如果两个上下文具有相同的 Key，加号右侧的会替换左侧的。

比如 Dispatchers.IO + Job() + CoroutineName("my-name") 一共会进行三次合并，得到三个 CombinedContext 对象，不会进行替换。

fun main() = runBlocking<Unit> {

    val handler = CoroutineExceptionHandler { _, throwable ->

        println("Caught $throwable")

    }

    val job =

        launch(Dispatchers.IO + Job() + CoroutineName("my-name") + handler) { 

            println(coroutineContext)

        }

    job.join()

}

运行结果：

[CoroutineName(my-name), com.example.coroutinetest.TestKtKt$main$1$invokeSuspend$$inlined$CoroutineExceptionHandler$1@6667fe3b, StandaloneCoroutine{Active}@26b2b4fd, Dispatchers.IO]

如果在末尾再加上一个 CoroutineName("your_name")，会进行一次替换，运行结果是：[com.example.coroutinetest.TestKtKt$main$1$invokeSuspend$$inlined$CoroutineExceptionHandler$1@6667fe3b, CoroutineName(your_name), StandaloneCoroutine{Active}@26b2b4fd, Dispatchers.IO]

[] 取值

[] 取值其实调用的是 CoroutineContext.get() 函数，它会从上下文（CombinedContext 树）中找到我们需要的信息。

@SinceKotlin("1.3")

public interface CoroutineContext {

    /**

     * Returns the element with the given [key] from this context or `null`.

     */

    public operator fun <E : Element> get(key: Key<E>): E?

        

    // ...

}

我们填入的参数其实是每一个接口的伴生对象 Key，每个伴生对象都实现了 CoroutineContext.Key<T> 接口，并将泛型指定为了当前接口。

以 ContinuationInterceptor 为例：

@SinceKotlin("1.3")

public interface ContinuationInterceptor : CoroutineContext.Element {

    /**

     * The key that defines *the* context interceptor.

     */

    public companion object Key : CoroutineContext.Key<ContinuationInterceptor>

    

    // ...

}

比如我们要获取上下文中的 CoroutineDispatcher，我们可以这样做：

fun main() = runBlocking<Unit> {

    val scope = CoroutineScope(Dispatchers.Default)

    val job = scope.launch {

        val dispatcher = coroutineContext[ContinuationInterceptor] as CoroutineDispatcher // 强转

        println("CoroutineDispatcher is $dispatcher")

    }

    job.join()

}

大多数前端开发者在公司里，很少需要直接操心“部署”这件事——那通常是运维或 DevOps 的工作。

但一旦回到个人项目，情况就完全不一样了。写个小博客、搭个文档站，或者搞个 demo 想给朋友看，部署往往成了最大的拦路虎。

常见的选择无非是 Vercel、Netlify 或 GitHub Pages。它们表面上“一键部署”，但细节其实并不轻松：要注册平台账号、要配置域名，还得接受平台的各种限制。国内的一些云服务商（比如阿里云、腾讯云）管控更严格，操作门槛也更高。更让人担心的是，一旦平台宕机，或者因为地区网络问题导致访问不稳定，你的项目可能随时“消失”在用户面前。虽然这种情况不常见，但始终让人心里不踏实。

很多时候，我们只是想快速上线一个小页面，不想被部署流程拖累，有没有更好的方法？

一个更轻的办法

前段时间我发现了一个开源工具 PinMe，主打的就是“极简部署”。

它的使用体验非常直接：

• 不需要服务器


• 不用注册账号


• 在项目目录敲一条命令，就能把项目打包上传到 IPFS 网络


• 很快，你就能拿到一个可访问的地址

实际用起来的感受就是一个字：爽。

整个过程几乎没有繁琐配置，不需要绑定平台账号，也不用担心流量限制或收费。

这让很多场景变得顺手：

• 临时展示一个 demo，不必折腾服务器


• 写了个静态博客，不想搞 CI/CD 流程


• 做了个活动页或 landing page，随时上线就好

以前这些需求可能要纠结“用 GitHub Pages 还是 Vercel”，现在有了 PinMe，直接一键上链就行。

体验一把

接下来看看它在真实场景下的表现：部署流程有多简化？访问速度如何？和传统方案相比有没有优势？

测试项目

为了覆盖不同体量的场景，这次我选了俩类项目来测试：

• 小型项目：fuwari（开源的个人博客项目），打包体积约 4 MB。


• 中大型项目：Soybean Admin（开源的后台管理系统），打包体积约 15 MB。

部署项目

PinMe 提供了两种方式：命令行 和 可视化界面。

这两种方式我们都来试一下。

命令行部署

先全局安装：

npm install -g pinme

然后一条命令上传：

pinme upload <folder/file-path>

比如上传 Soybean Admin，文件大小 15MB：

输入命令之后，等着就可以了：

只用了两分钟，终端返回的 URL 就能直接访问项目的控制页面。还能绑定自己的域名：

点击网站链接就可以看到已经部署好的项目，访问速度还是挺快的：

同样地，上传个人博客也是一样的流程。

部署完成：

可视化部署

不习惯命令行？PinMe 也提供了网页上传，进度条实时显示：

部署完成后会自动进入管理页面：

经过测试，部署速度和命令行几乎一致。

其他功能

历时记录

部署过的网站都能在主页的 History 查看：

历史部署记录：

也可以用命令行：

pinme list

历史部署记录：

删除网站

如果不再需要某个项目，执行以下命令即可：

pinme rm

PinMe 背后的“硬核支撑”

如果只看表层，PinMe 就像一个极简的托管工具。但要理解它为什么能做到“不依赖平台”，还得看看它背后的底层逻辑。

PinMe 的底层依赖 IPFS，这是一个去中心化的分布式文件系统。

要理解它的意义，得先聊聊“去中心化”这个概念。

传统互联网是中心化的：你访问一个网站时，浏览器会通过 DNS 找到某台服务器，然后从这台服务器获取内容。这条链路依赖强烈，一旦 DNS 被劫持、服务器宕机、服务商下线，网站就无法访问。

去中心化的思路完全不同：

• 数据不是放在单一服务器，而是分布在全球节点中


• 访问不依赖“位置”，而是通过内容哈希来检索


• 只要有节点存储这份内容，就能访问到，不怕单点故障

这意味着：

• 更稳定：即使部分节点宕机，内容依然能从其他节点获取。


• 防篡改：文件哪怕改动一个字节，对应的 CID 也会完全不同，从机制上保障了前端资源的完整性和安全性。


• 更自由：不再受制于中心化平台，文件真正由用户自己掌控。

当然，IPFS 地址（哈希）太长，不适合直接记忆和分享。这时候就需要 ENS（Ethereum Name Service）。它和 DNS 类似，但记录存储在以太坊区块链上，不可能被篡改。比如你可以把 myblog.eth 指向某个 IPFS 哈希，别人只要输入 ENS 域名就能访问，不依赖传统 DNS，自然也不会被劫持。

换句话说：

ENS + IPFS = 内容去中心化 + 域名去中心化

前端个人项目瞬间就有了更高的自由度和安全性。

一点初步感受

PinMe 并不是要取代 Vercel 这类成熟平台，但它带来了一种新的选择：更简单、更自由、更去中心化。

如果你只是想快速上线一个小项目，或者对去中心化部署感兴趣，PinMe 值得一试。

• 官网：pinme.eth.limo/


• Github：github.com/glitternetw…

这是一个完全开源的项目，开发团队也会持续更新。如果你在测试过程中有想法或需求，不妨去 GitHub 提个 Issue —— 这不仅能帮助项目成长，也能让它更贴近前端开发的实际使用场景！

前端开发者应该对 Ant Design 不陌生，特别是 React 开发者，antd 应该是组件库的标配了。

近年来随着 AI 的爆火，凡是想要接入 AI 的都想搞一套自己的 AI 交互界面。专注于 AI 场景组件库的开源项目倒不是很多见，近日 antd 宣布推出 Ant Design X 1.0 🚀 ，这是一个基于 Ant Design 的全新 AGI 组件库，使用 React 构建 AI 驱动的用户交互变得更简单了，它可以无缝集成 AI 聊天组件和 API 服务，简化 AI 界面的开发流程。

该项目已在 Github 开源，拥有 1.6K Star！

看了网友的评论，看来大家还是需要的！当前的 Ant Design X 只支持 React 项目，看来 Vue 开发者要羡慕了...

ant-design-x 特性

• 🌈 源自企业级 AI 产品的最佳实践：基于 RICH 交互范式，提供卓越的 AI 交互体验


• 🧩 灵活多样的原子组件：覆盖绝大部分 AI 对话场景，助力快速构建个性化 AI 交互页面


• ⚡ 开箱即用的模型对接能力：轻松对接符合 OpenAI 标准的模型推理服务


• 🔄 高效管理对话数据流：提供好用的数据流管理功能，让开发更高效


• 📦 丰富的样板间支持：提供多种模板，快速启动 LUI 应用开发


• 🛡 TypeScript 全覆盖：采用 TypeScript 开发，提供完整类型支持，提升开发体验与可靠性


• 🎨 深度主题定制能力：支持细粒度的样式调整，满足各种场景的个性化需求

支持组件

以下圈中的部分为 ant-design-x 支持的组件。可以看到主要都是基于 AI Chat 场景的组件设计。现在你可以基于这些组件自由组装搭建一个自己的 AI 界面。

ant-design-x 也提供了一个完整 AI Chat 的 Demo 演示，可以查看 Demo 的代码并直接使用。

更多组件详细内容可参考 组件文档

使用

以下命令安装 @ant-design/x 依赖。

注意，ant-design-x 是基于 Ant Design，因此还需要安装依赖 antd。

yarn add antd @ant-design/x

import React from 'react';

import {

  // 消息气泡

  Bubble,

  // 发送框

  Sender,

} from '@ant-design/x';



const messages = [

  {

    content: 'Hello, Ant Design X!',

    role: 'user',

  },

];

const App = () => (

  <div>

    <Bubble.List items={messages} />

    <Sender />

  </div>

);



export default App;

Ant Design X 前生 ProChat

不知道有没有小伙伴们使用过 ProChat，这个库后面的维护可能会有些不确定性，其维护者表示 “24 年下半年后就没有更多精力来维护这个项目了，Github 上的 Issue 存留了很多，这边只能尽量把一些恶性 Bug 修复”

如上所示，也回答了其和 Ant Design X 的关系：ProChat 是 x 的前生，新用户请直接使用 x，老用户也请尽快迁移到 x。

感兴趣的朋友们可以去试试哦！