每到节假日期间，一二线城市返乡、外出游玩的人们几乎都面临着一个问题：抢火车票！

12306 抢票，极限并发带来的思考

虽然现在大多数情况下都能订到票，但是放票瞬间即无票的场景，相信大家都深有体会。

尤其是春节期间，大家不仅使用 12306，还会考虑“智行”和其他的抢票软件，全国上下几亿人在这段时间都在抢票。

“12306 服务”承受着这个世界上任何秒杀系统都无法超越的 QPS，上百万的并发再正常不过了！

笔者专门研究了一下“12306”的服务端架构，学习到了其系统设计上很多亮点，在这里和大家分享一下并模拟一个例子：如何在 100 万人同时抢 1 万张火车票时，系统提供正常、稳定的服务。

Github代码地址：

https://github.com/GuoZhaoran/spikeSystem

大型高并发系统架构

高并发的系统架构都会采用分布式集群部署，服务上层有着层层负载均衡，并提供各种容灾手段（双火机房、节点容错、服务器灾备等）保证系统的高可用，流量也会根据不同的负载能力和配置策略均衡到不同的服务器上。

下边是一个简单的示意图：

负载均衡简介

上图中描述了用户请求到服务器经历了三层的负载均衡，下边分别简单介绍一下这三种负载均衡。

①OSPF（开放式最短链路优先）是一个内部网关协议（Interior Gateway Protocol，简称 IGP）

OSPF 通过路由器之间通告网络接口的状态来建立链路状态数据库，生成最短路径树，OSPF 会自动计算路由接口上的 Cost 值，但也可以通过手工指定该接口的 Cost 值，手工指定的优先于自动计算的值。

OSPF 计算的 Cost，同样是和接口带宽成反比，带宽越高，Cost 值越小。到达目标相同 Cost 值的路径，可以执行负载均衡，最多 6 条链路同时执行负载均衡。

②LVS （Linux Virtual Server）

它是一种集群（Cluster）技术，采用 IP 负载均衡技术和基于内容请求分发技术。

调度器具有很好的吞吐率，将请求均衡地转移到不同的服务器上执行，且调度器自动屏蔽掉服务器的故障，从而将一组服务器构成一个高性能的、高可用的虚拟服务器。

③Nginx

想必大家都很熟悉了，是一款非常高性能的 HTTP 代理/反向代理服务器，服务开发中也经常使用它来做负载均衡。

Nginx 实现负载均衡的方式主要有三种：

• 轮询


• 加权轮询


• IP Hash 轮询

下面我们就针对 Nginx 的加权轮询做专门的配置和测试。

Nginx 加权轮询的演示

Nginx 实现负载均衡通过 Upstream 模块实现，其中加权轮询的配置是可以给相关的服务加上一个权重值，配置的时候可能根据服务器的性能、负载能力设置相应的负载。

下面是一个加权轮询负载的配置，我将在本地的监听 3001-3004 端口，分别配置 1，2，3，4 的权重：

#配置负载均衡

    upstream load_rule {

       server 127.0.0.1:3001 weight=1;

       server 127.0.0.1:3002 weight=2;

       server 127.0.0.1:3003 weight=3;

       server 127.0.0.1:3004 weight=4;

    }

    ...

    server {

    listen       80;

    server_name  load_balance.com http://www.load_balance.com;

    location / {

       proxy_pass http://load_rule;

    }

}

我在本地 /etc/hosts 目录下配置了 http://www.load_balance.com 的虚拟域名地址。

接下来使用 Go 语言开启四个 HTTP 端口监听服务，下面是监听在 3001 端口的 Go 程序，其他几个只需要修改端口即可：

package main



import (

    "net/http"

    "os"

    "strings"

)



func main() {

    http.HandleFunc("/buy/ticket", handleReq)

    http.ListenAndServe(":3001", nil)

}



//处理请求函数,根据请求将响应结果信息写入日志

func handleReq(w http.ResponseWriter, r *http.Request) {

    failedMsg :=  "handle in port:"

    writeLog(failedMsg, "./stat.log")

}



//写入日志

func writeLog(msg string, logPath string) {

    fd, _ := os.OpenFile(logPath, os.O_RDWR|os.O_CREATE|os.O_APPEND, 0644)

    defer fd.Close()

    content := strings.Join([]string{msg, "\r\n"}, "3001")

    buf := []byte(content)

    fd.Write(buf)

}

我将请求的端口日志信息写到了 ./stat.log 文件当中，然后使用 AB 压测工具做压测：

ab -n 1000 -c 100 http://www.load_balance.com/buy/ticket

统计日志中的结果，3001-3004 端口分别得到了 100、200、300、400 的请求量。

这和我在 Nginx 中配置的权重占比很好的吻合在了一起，并且负载后的流量非常的均匀、随机。

具体的实现大家可以参考 Nginx 的 Upsteam 模块实现源码，这里推荐一篇文章《Nginx 中 Upstream 机制的负载均衡》：

https://www.kancloud.cn/digest/understandingnginx/202607

秒杀抢购系统选型

回到我们最初提到的问题中来：火车票秒杀系统如何在高并发情况下提供正常、稳定的服务呢？

从上面的介绍我们知道用户秒杀流量通过层层的负载均衡，均匀到了不同的服务器上，即使如此，集群中的单机所承受的 QPS 也是非常高的。如何将单机性能优化到极致呢？

要解决这个问题，我们就要想明白一件事： 通常订票系统要处理生成订单、减扣库存、用户支付这三个基本的阶段。

我们系统要做的事情是要保证火车票订单不超卖、不少卖，每张售卖的车票都必须支付才有效，还要保证系统承受极高的并发。

这三个阶段的先后顺序该怎么分配才更加合理呢？我们来分析一下：

下单减库存

当用户并发请求到达服务端时，首先创建订单，然后扣除库存，等待用户支付。

这种顺序是我们一般人首先会想到的解决方案，这种情况下也能保证订单不会超卖，因为创建订单之后就会减库存，这是一个原子操作。

但是这样也会产生一些问题：

• 在极限并发情况下，任何一个内存操作的细节都至关影响性能，尤其像创建订单这种逻辑，一般都需要存储到磁盘数据库的，对数据库的压力是可想而知的。


• 如果用户存在恶意下单的情况，只下单不支付这样库存就会变少，会少卖很多订单，虽然服务端可以限制 IP 和用户的购买订单数量，这也不算是一个好方法。

支付减库存

如果等待用户支付了订单在减库存，第一感觉就是不会少卖。但是这是并发架构的大忌，因为在极限并发情况下，用户可能会创建很多订单。

当库存减为零的时候很多用户发现抢到的订单支付不了了，这也就是所谓的“超卖”。也不能避免并发操作数据库磁盘 IO。

预扣库存

从上边两种方案的考虑，我们可以得出结论：只要创建订单，就要频繁操作数据库 IO。

那么有没有一种不需要直接操作数据库 IO 的方案呢，这就是预扣库存。先扣除了库存，保证不超卖，然后异步生成用户订单，这样响应给用户的速度就会快很多；那么怎么保证不少卖呢？用户拿到了订单，不支付怎么办？

我们都知道现在订单都有有效期，比如说用户五分钟内不支付，订单就失效了，订单一旦失效，就会加入新的库存，这也是现在很多网上零售企业保证商品不少卖采用的方案。

订单的生成是异步的，一般都会放到 MQ、Kafka 这样的即时消费队列中处理，订单量比较少的情况下，生成订单非常快，用户几乎不用排队。

扣库存的艺术

从上面的分析可知，显然预扣库存的方案最合理。我们进一步分析扣库存的细节，这里还有很大的优化空间，库存存在哪里？怎样保证高并发下，正确的扣库存，还能快速的响应用户请求？

在单机低并发情况下，我们实现扣库存通常是这样的：

为了保证扣库存和生成订单的原子性，需要采用事务处理，然后取库存判断、减库存，最后提交事务，整个流程有很多 IO，对数据库的操作又是阻塞的。

这种方式根本不适合高并发的秒杀系统。接下来我们对单机扣库存的方案做优化：本地扣库存。

我们把一定的库存量分配到本地机器，直接在内存中减库存，然后按照之前的逻辑异步创建订单。

改进过之后的单机系统是这样的：

这样就避免了对数据库频繁的 IO 操作，只在内存中做运算，极大的提高了单机抗并发的能力。

但是百万的用户请求量单机是无论如何也抗不住的，虽然 Nginx 处理网络请求使用 Epoll 模型，c10k 的问题在业界早已得到了解决。

但是 Linux 系统下，一切资源皆文件，网络请求也是这样，大量的文件描述符会使操作系统瞬间失去响应。

上面我们提到了 Nginx 的加权均衡策略，我们不妨假设将 100W 的用户请求量平均均衡到 100 台服务器上，这样单机所承受的并发量就小了很多。

然后我们每台机器本地库存 100 张火车票，100 台服务器上的总库存还是 1 万，这样保证了库存订单不超卖，下面是我们描述的集群架构：

问题接踵而至，在高并发情况下，现在我们还无法保证系统的高可用，假如这 100 台服务器上有两三台机器因为扛不住并发的流量或者其他的原因宕机了。那么这些服务器上的订单就卖不出去了，这就造成了订单的少卖。

要解决这个问题，我们需要对总订单量做统一的管理，这就是接下来的容错方案。服务器不仅要在本地减库存，另外要远程统一减库存。

有了远程统一减库存的操作，我们就可以根据机器负载情况，为每台机器分配一些多余的“Buffer 库存”用来防止机器中有机器宕机的情况。

我们结合下面架构图具体分析一下：

我们采用 Redis 存储统一库存，因为 Redis 的性能非常高，号称单机 QPS 能抗 10W 的并发。

在本地减库存以后，如果本地有订单，我们再去请求 Redis 远程减库存，本地减库存和远程减库存都成功了，才返回给用户抢票成功的提示，这样也能有效的保证订单不会超卖。

当机器中有机器宕机时，因为每个机器上有预留的 Buffer 余票，所以宕机机器上的余票依然能够在其他机器上得到弥补，保证了不少卖。

Buffer 余票设置多少合适呢，理论上 Buffer 设置的越多，系统容忍宕机的机器数量就越多，但是 Buffer 设置的太大也会对 Redis 造成一定的影响。

虽然 Redis 内存数据库抗并发能力非常高，请求依然会走一次网络 IO，其实抢票过程中对 Redis 的请求次数是本地库存和 Buffer 库存的总量。

因为当本地库存不足时，系统直接返回用户“已售罄”的信息提示，就不会再走统一扣库存的逻辑。

这在一定程度上也避免了巨大的网络请求量把 Redis 压跨，所以 Buffer 值设置多少，需要架构师对系统的负载能力做认真的考量。

代码演示

Go 语言原生为并发设计，我采用 Go 语言给大家演示一下单机抢票的具体流程。

初始化工作

Go 包中的 Init 函数先于 Main 函数执行，在这个阶段主要做一些准备性工作。

我们系统需要做的准备工作有：初始化本地库存、初始化远程 Redis 存储统一库存的 Hash 键值、初始化 Redis 连接池。

另外还需要初始化一个大小为 1 的 Int 类型 Chan，目的是实现分布式锁的功能。

也可以直接使用读写锁或者使用 Redis 等其他的方式避免资源竞争，但使用 Channel 更加高效，这就是 Go 语言的哲学：不要通过共享内存来通信，而要通过通信来共享内存。

Redis 库使用的是 Redigo，下面是代码实现：

...

//localSpike包结构体定义

package localSpike



type LocalSpike struct {

    LocalInStock     int64

    LocalSalesVolume int64

}

...

//remoteSpike对hash结构的定义和redis连接池

package remoteSpike

//远程订单存储健值

type RemoteSpikeKeys struct {

    SpikeOrderHashKey string    //redis中秒杀订单hash结构key

    TotalInventoryKey string    //hash结构中总订单库存key

    QuantityOfOrderKey string   //hash结构中已有订单数量key

}



//初始化redis连接池

func NewPool() *redis.Pool {

    return &redis.Pool{

        MaxIdle:   10000,

        MaxActive: 12000, // max number of connections

        Dial: func() (redis.Conn, error) {

            c, err := redis.Dial("tcp", ":6379")

            if err != nil {

                panic(err.Error())

            }

            return c, err

        },

    }

}

...

func init() {

    localSpike = localSpike2.LocalSpike{

        LocalInStock:     150,

        LocalSalesVolume: 0,

    }

    remoteSpike = remoteSpike2.RemoteSpikeKeys{

        SpikeOrderHashKey:  "ticket_hash_key",

        TotalInventoryKey:  "ticket_total_nums",

        QuantityOfOrderKey: "ticket_sold_nums",

    }

    redisPool = remoteSpike2.NewPool()

    done = make(chanint, 1)

    done <- 1

}

本地扣库存和统一扣库存

本地扣库存逻辑非常简单，用户请求过来，添加销量，然后对比销量是否大于本地库存，返回 Bool 值：

package localSpike

//本地扣库存,返回bool值

func (spike *LocalSpike) LocalDeductionStock() bool{

    spike.LocalSalesVolume = spike.LocalSalesVolume + 1

    return spike.LocalSalesVolume < spike.LocalInStock

}

注意这里对共享数据 LocalSalesVolume 的操作是要使用锁来实现的，但是因为本地扣库存和统一扣库存是一个原子性操作，所以在最上层使用 Channel 来实现，这块后边会讲。

统一扣库存操作 Redis，因为 Redis 是单线程的，而我们要实现从中取数据，写数据并计算一些列步骤，我们要配合 Lua 脚本打包命令，保证操作的原子性：

package remoteSpike

......

const LuaScript = `

        local ticket_key = KEYS[1]

        local ticket_total_key = ARGV[1]

        local ticket_sold_key = ARGV[2]

        local ticket_total_nums = tonumber(redis.call('HGET', ticket_key, ticket_total_key))

        local ticket_sold_nums = tonumber(redis.call('HGET', ticket_key, ticket_sold_key))

        -- 查看是否还有余票,增加订单数量,返回结果值

       if(ticket_total_nums >= ticket_sold_nums) then

            return redis.call('HINCRBY', ticket_key, ticket_sold_key, 1)

        end

        return0

`

//远端统一扣库存

func (RemoteSpikeKeys *RemoteSpikeKeys) RemoteDeductionStock(conn redis.Conn) bool {

    lua := redis.NewScript(1, LuaScript)

    result, err := redis.Int(lua.Do(conn, RemoteSpikeKeys.SpikeOrderHashKey, RemoteSpikeKeys.TotalInventoryKey, RemoteSpikeKeys.QuantityOfOrderKey))

    if err != nil {

        returnfalse

    }

    return result != 0

}

我们使用 Hash 结构存储总库存和总销量的信息，用户请求过来时，判断总销量是否大于库存，然后返回相关的 Bool 值。

在启动服务之前，我们需要初始化 Redis 的初始库存信息：

hmset ticket_hash_key "ticket_total_nums" 10000 "ticket_sold_nums" 0

响应用户信息

我们开启一个 HTTP 服务，监听在一个端口上：

package main

...

func main() {

    http.HandleFunc("/buy/ticket", handleReq)

    http.ListenAndServe(":3005", nil)

}

上面我们做完了所有的初始化工作，接下来 handleReq 的逻辑非常清晰，判断是否抢票成功，返回给用户信息就可以了。

package main

//处理请求函数,根据请求将响应结果信息写入日志

func handleReq(w http.ResponseWriter, r *http.Request) {

    redisConn := redisPool.Get()

    LogMsg := ""

    <-done

    //全局读写锁

    if localSpike.LocalDeductionStock() && remoteSpike.RemoteDeductionStock(redisConn) {

        util.RespJson(w, 1,  "抢票成功", nil)

        LogMsg = LogMsg + "result:1,localSales:" + strconv.FormatInt(localSpike.LocalSalesVolume, 10)

    } else {

        util.RespJson(w, -1, "已售罄", nil)

        LogMsg = LogMsg + "result:0,localSales:" + strconv.FormatInt(localSpike.LocalSalesVolume, 10)

    }

    done <- 1



    //将抢票状态写入到log中

    writeLog(LogMsg, "./stat.log")

}



func writeLog(msg string, logPath string) {

    fd, _ := os.OpenFile(logPath, os.O_RDWR|os.O_CREATE|os.O_APPEND, 0644)

    defer fd.Close()

    content := strings.Join([]string{msg, "\r\n"}, "")

    buf := []byte(content)

    fd.Write(buf)

}

前边提到我们扣库存时要考虑竞态条件，我们这里是使用 Channel 避免并发的读写，保证了请求的高效顺序执行。我们将接口的返回信息写入到了 ./stat.log 文件方便做压测统计。

单机服务压测

开启服务，我们使用 AB 压测工具进行测试：

ab -n 10000 -c 100 http://127.0.0.1:3005/buy/ticket

下面是我本地低配 Mac 的压测信息：

This is ApacheBench, Version 2.3 <$revision: 1826891="">

Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/

Licensed to The Apache Software Foundation, http://www.apache.org/



Benchmarking 127.0.0.1 (be patient)

Completed 1000 requests

Completed 2000 requests

Completed 3000 requests

Completed 4000 requests

Completed 5000 requests

Completed 6000 requests

Completed 7000 requests

Completed 8000 requests

Completed 9000 requests

Completed 10000 requests

Finished 10000 requests





Server Software:

Server Hostname:        127.0.0.1

Server Port:            3005



Document Path:          /buy/ticket

Document Length:        29 bytes



Concurrency Level:      100

Time taken for tests:   2.339 seconds

Complete requests:      10000

Failed requests:        0

Total transferred:      1370000 bytes

HTML transferred:       290000 bytes

Requests per second:    4275.96 [#/sec] (mean)

Time per request:       23.387 [ms] (mean)

Time per request:       0.234 [ms] (mean, across all concurrent requests)

Transfer rate:          572.08 [Kbytes/sec] received



Connection Times (ms)

              min  mean[+/-sd] median   max

Connect:        0    8  14.7      6     223

Processing:     2   15  17.6     11     232

Waiting:        1   11  13.5      8     225

Total:          7   23  22.8     18     239



Percentage of the requests served within a certain time (ms)

  50%     18

  66%     24

  75%     26

  80%     28

  90%     33

  95%     39

  98%     45

  99%     54

 100%    239 (longest request)

根据指标显示，我单机每秒就能处理 4000+ 的请求，正常服务器都是多核配置，处理 1W+ 的请求根本没有问题。

而且查看日志发现整个服务过程中，请求都很正常，流量均匀，Redis 也很正常：

//stat.log

...

result:1,localSales:145

result:1,localSales:146

result:1,localSales:147

result:1,localSales:148

result:1,localSales:149

result:1,localSales:150

result:0,localSales:151

result:0,localSales:152

result:0,localSales:153

result:0,localSales:154

result:0,localSales:156

...

总结回顾

总体来说，秒杀系统是非常复杂的。我们这里只是简单介绍模拟了一下单机如何优化到高性能，集群如何避免单点故障，保证订单不超卖、不少卖的一些策略

完整的订单系统还有订单进度的查看，每台服务器上都有一个任务，定时的从总库存同步余票和库存信息展示给用户，还有用户在订单有效期内不支付，释放订单，补充到库存等等。

我们实现了高并发抢票的核心逻辑，可以说系统设计的非常的巧妙，巧妙的避开了对 DB 数据库 IO 的操作。

对 Redis 网络 IO 的高并发请求，几乎所有的计算都是在内存中完成的，而且有效的保证了不超卖、不少卖，还能够容忍部分机器的宕机。

我觉得其中有两点特别值得学习总结：

①负载均衡，分而治之

通过负载均衡，将不同的流量划分到不同的机器上，每台机器处理好自己的请求，将自己的性能发挥到极致。

这样系统的整体也就能承受极高的并发了，就像工作的一个团队，每个人都将自己的价值发挥到了极致，团队成长自然是很大的。

②合理的使用并发和异步

自 Epoll 网络架构模型解决了 c10k 问题以来，异步越来越被服务端开发人员所接受，能够用异步来做的工作，就用异步来做，在功能拆解上能达到意想不到的效果。

这点在 Nginx、Node.JS、Redis 上都能体现，他们处理网络请求使用的 Epoll 模型，用实践告诉了我们单线程依然可以发挥强大的威力。

服务器已经进入了多核时代，Go 语言这种天生为并发而生的语言，完美的发挥了服务器多核优势，很多可以并发处理的任务都可以使用并发来解决，比如 Go 处理 HTTP 请求时每个请求都会在一个 Goroutine 中执行。

总之，怎样合理的压榨 CPU，让其发挥出应有的价值，是我们一直需要探索学习的方向。

Hi，我是石小石~

静态属性获取的缺陷

前段时间在做项目国际化时，遇到一个比较隐蔽的问题：

我们在定义枚举常量时，直接调用了 i18n 的翻译方法：

export const OverdueStatus: any = {

  ABOUT_TO_OVERDUE: {

    value: 'ABOUT_TO_OVERDUE',

    name: i18n.global.t('common.about_to_overdue'),

    color: '#ad0000',

    bgColor: '#ffe1e1'

  },

}

结果发现翻译始终不生效。排查后才发现原因很简单 —— OverdueStatus 对象的初始化早于 i18n 实例的生成，因此取到的翻译结果是空的。

虽然最后我通过封装自定义 Vue 插件的方式彻底解决了问题，但排查过程中其实还有一个可选思路。

当时我想到的最直接办法是：让 name 在被访问时再去执行 i18n.global.t，而不是在对象定义时就执行。比如把 OverdueStatus 定义为函数：

export const OverdueStatus = () => ({

  ABOUT_TO_OVERDUE: {

    value: 'ABOUT_TO_OVERDUE',

    name: i18n.global.t('common.about_to_overdue'),

    color: '#ad0000',

    bgColor: '#ffe1e1'

  },

})

这样在调用时：

OverdueStatus().ABOUT_TO_OVERDUE.name

就能确保翻译逻辑在 i18n 实例创建完成之后再执行，从而避免初始化顺序的问题。不过，这种方式也有明显的缺点：所有类似的枚举都要改成函数，调用时也得多加一层执行，整体代码会变得不够简洁。

如何优雅地实现“动态获取属性”？

上面提到的“把枚举改成函数返回”虽然能解决问题，但在实际业务中显得有些笨拙。有没有更优雅的方式，让属性本身就支持 动态计算 呢？

其实，JavaScript 本身就为我们提供了解决方案 —— getter。

举个例子，我们可以把枚举对象改写成这样：

export const OverdueStatus: any = {

  ABOUT_TO_OVERDUE: {

    value: 'ABOUT_TO_OVERDUE',

    get name() {

      return i18n.global.t('common.about_to_overdue')

    },

    color: '#ad0000',

    bgColor: '#ffe1e1'

  },

}

这样一来，在访问 name 属性时，才会真正执行 i18n.global.t，确保翻译逻辑在 i18n 实例创建完成后才生效，完美解决问题。

访问器属性的原理

在 JavaScript 规范里，get 定义的属性叫 访问器属性，区别于普通的 数据属性 (Data Property) 。简单来说getter 其实就是对象属性的一种特殊定义方式。

当我们写：

const obj = {

  get foo() {

    return "bar"

  }

}

等价于用 Object.defineProperty：

const obj = {}

Object.defineProperty(obj, "foo", {

  get: function() {

    return "bar"

  }

})

所以访问 obj.foo 时，其实是触发了这个 get 函数，而不是读取一个固定的值。

类比Vue的computed

在 Vue 里，我们经常写 computed 计算属性，其实就是 getter 的思想。

import { computed, ref } from "vue"



const firstName = ref("Tom")

const lastName = ref("Hanks")



const fullName = computed(() => `${firstName.value} ${lastName.value}`)

computed 内部其实就是包装了一个 getter 函数。

注意点

• getter 不能跟属性值同时存在：

const obj = {

  get name() { return "石小石" },

  name: "石小石Orz" //  会报错

}

• getter 是只读的，如果你想支持赋值，需要配合 setter：

const obj = {

  _age: 18,

  get age() { return this._age },

  set age(val) { this._age = val }

}



obj.age = 20

console.log(obj.age) // 20

其他实用场景

延迟计算

有些值计算比较复杂，但只有在真正使用时才去算，可以提升性能

const user = {

  firstName: "石",

  lastName: "小石",

  get fullName() {

    // 类比一个计算，实现开发中，一个很复杂的计算才使用此方法

    console.log("计算了一次 fullName")

    return `${this.firstName} ${this.lastName}`

  }

}



console.log(user.fullName) // "石小石"

这种写法让 API 看起来更自然，不需要调用函数 user.getFullName()，而是 user.fullName。

数据封装与保护

有些属性可能并不是一个固定字段，而是基于内部状态计算出来的：

const cart = {

  items: [100, 200, 300],

  get total() {

    return this.items.reduce((sum, price) => sum + price, 0)

  }

}



console.log(cart.total) // 600

这样 cart.total 永远是最新的，不用担心手动维护，你也不用写一个函数专门去更新这个值。

前言

“分库分表这种架构模式会逐步的被淘汰！” 不知道在哪儿看到的观点

如果我们现在在搭建新的业务架构，如果说你们未来的业务数据量会达到千万 或者上亿的级别 还在一股脑的使用分库分表的架构，那么你们的技术负责人真的就应该提前退休了🙈

如果对未来的业务非常有信心，单表的数据量能达到千万上亿的级别，请使用NewSQL 数据库，那么NewSQL 这么牛，分布库分表还有意义吗？

今天虽然写的是一篇博客，但是更多的是抱着和大家讨论的心态来的，所以大家目前有深度参与分库分表，或者NewSQL 的都可以在评论区讨论！

什么是NewSQL

NewSQL 是21世纪10年代初出现的一个术语，用来描述一类新型的关系型数据库管理系统（RDBMS）。它们的共同目标是：在保持传统关系型数据库（如Oracle、MySQL）的ACID事务和SQL模型优势的同时，获得与NoSQL系统类似的、弹性的水平扩展能力

NewSQL 的核心理念就是 将“分库分表”的复杂性从应用层下沉到数据库内核层，对上层应用呈现为一个单一的数据库入口，解决现在 分库分表的问题；

分库分表的问题

分库分表之后，会带来非常多的问题；比如需要跨库联查、跨库更新数据如何保证事务一致性等问题，下面就来详细看看分库分表都有那些问题

选择TiDB还是采用mysql 分库分表的设计

数据量非常大，需要满足OLTP (Online Transactional Processing)、OLAP (Online Analytical Processing)、HTAP 且预算充足（分布式数据库的成本也是非常高的这一点非常的重要），并且是新业务新架构落地 优先推荐使用TiDB。
当然实际上选择肯定是需要多方面考虑的，大家有什么观点都可以在评论区讨论。

可以看看一个资深开发，深度参与TiDB项目，他对TiDB的一些看法：

1 什么是TiDB？

TiDB是PingCAP公司研发的开源分布式关系型数据库，采用存储计算分离架构，支持混合事务分析处理（HTAP） 。它与MySQL 5.7协议兼容，并支持MySQL生态，这意味着使用MySQL的应用程序可以几乎无需修改代码就能迁移到TiDB。

🚀目标是为用户提供一站式 OLTP (Online Transactional Processing)、OLAP (Online Analytical Processing)、HTAP 解决方案。TiDB 适合高可用、强一致要求较高、数据规模较大等各种应用场景。

官方文档：docs.pingcap.com/zh/tidb/dev…

TiDB五大核心特性

TiDB之所以在分布式数据库领域脱颖而出，得益于其五大核心特性：

• 一键水平扩容或缩容：得益于存储计算分离的架构设计，可按需对计算、存储分别进行在线扩容或缩容，整个过程对应用透明。


• 金融级高可用：数据采用多副本存储，通过Multi-Raft协议同步事务日志，只有多数派写入成功事务才能提交，确保数据强一致性。


• 实时HTAP：提供行存储引擎TiKV和列存储引擎TiFlash，两者之间的数据保持强一致，解决了HTAP资源隔离问题。


• 云原生分布式数据库：通过TiDB Operator可在公有云、私有云、混合云中实现部署工具化、自动化。


• 兼容MySQL 5.7协议和生态：从MySQL迁移到TiDB无需或只需少量代码修改，极大降低了迁移成本。

2 TiDB与MySQL的核心差异

虽然TiDB兼容MySQL协议，但它们在架构设计和适用场景上存在根本差异。以下是它们的详细对比：

2.1 架构差异

表1：TiDB与MySQL架构对比

2.2 性能表现对比

性能方面，TiDB与MySQL各有优势，主要取决于数据量和查询类型：

• 小数据量简单查询：在数据量百万级以下的情况下，MySQL的写入性能和点查点写通常优于TiDB。因为TiDB的分布式架构在少量数据时无法充分发挥优势，却要承担分布式事务的开销。


• 大数据量复杂查询：当数据量达到千万级以上，TiDB的性能优势开始显现。一张千万级别表关联查询，MySQL可能需要20秒，而TiDB+TiKV只需约5.57秒，使用TiFlash甚至可缩短到0.5秒。


• 高并发场景：MySQL性能随着并发增加会达到瓶颈然后下降，而TiDB性能基本随并发增加呈线性提升，节点资源不足时还可通过动态扩容提升性能。

2.3 扩展性与高可用对比

MySQL的主要扩展方式是一主多从架构，主节点无法横向扩展（除非接受分库分表），从节点扩容需要应用支持读写分离。而TiDB的存储和计算节点都可以独立扩容，支持最大512节点，集群容量可达PB级别。

高可用方面，MySQL使用增强半同步和MGR方案，但复制效率较低，主节点故障会影响业务处理[]。TiDB则通过Raft协议将数据打散分布，单机故障对集群影响小，能保证RTO（恢复时间目标）不超过30秒且RPO（恢复点目标）为0，真正实现金融级高可用。

2.4 SQL功能及兼容性

虽然TiDB高度兼容MySQL 5.7协议和生态，但仍有一些重要差异需要注意：

不支持的功能包括：

• 存储过程与函数


• 触发器


• 事件


• 自定义函数


• 全文索引（计划中）


• 空间类型函数和索引

有差异的功能包括：

• 自增ID的行为（TiDB推荐使用AUTO_RANDOM避免热点问题）


• 查询计划的解释结果


• 在线DDL能力（TiDB更强，不锁表支持DML并行操作）

3 如何选择：TiDB还是MySQL？

选择数据库时，应基于实际业务需求和技术要求做出决策。以下是具体的选型建议：

3.1 选择TiDB的场景

TiDB在以下场景中表现卓越：

3.2 选择MySQL的场景

MySQL在以下情况下仍是更合适的选择：

3.3 决策参考框架

为了更直观地帮助决策，可以参考以下决策表：

4 迁移注意事项

如果决定从MySQL迁移到TiDB，需要注意以下关键点：

5 总结

TiDB和MySQL是适用于不同场景的数据库解决方案，没有绝对的优劣之分。MySQL是优秀的单机数据库，适用于数据量小、架构简单的场景；数据量大了之后需要做分库分表。而TiDB作为分布式数据库，专注于解决大数据量、高并发、高可用性需求下的数据库瓶颈问题，但是成本也是非常的高

本人没有使用过NewSQL ，还望各位大佬批评指正

众所周知，新生代的ui框架(如：kotlin，swift，flutter，鸿蒙）都已经抛弃了XML这类的结构化数据标记语言改为使用声明式UI

只有web端还没有支持此类ui语法，此次我开发的ovsjs为前端也带来了此类声明式UI语法的支持，语法如下

项目地址

github.com/alamhubb/ov…

语法插件地址：

marketplace.visualstudio.com/items?itemN…

新语法如下：

我认为更强的地方是我的新设计除了为前端带来了声明式UI，还支持了 #{ } 不渲染代码块的设计，支持在 声明式UI中编写代码，这样UI和逻辑之间的距离更近，维护更方便，抽象组件也更容易

对比kotlin，swift，flutter，鸿蒙语法如下：

kotlin的语法

import kotlinx.browser.*

import kotlinx.html.*

import kotlinx.html.dom.*



fun main() {

    document.body!!.append.div {

        h1 {

            +"Welcome to Kotlin/JS!"

        }

        p {

            +"Fancy joining this year's "

            a("https://kotlinconf.com/") {

                +"KotlinConf"

            }

            +"?"

        }

    }

}

swiftUI的语法

import SwiftUI



struct ContentView: View {

    var body: some View {

        VStack(spacing: 16) {

            Text("Hello SwiftUI")

                .font(.largeTitle)

                .fontWeight(.bold)



            Text("Welcome to SwiftUI world")



            Button("Click Me") {

                print("Button clicked")

            }

        }

        .padding()

    }

}

flutter的语法

class MyApp extends StatelessWidget {

  const MyApp({super.key});



  @override

  Widget build(BuildContext context) {

    return MaterialApp(

      home: Scaffold(

        body: Center(

          child: Column(

            mainAxisSize: MainAxisSize.min,

            children: [

              const Text(

                "Hello Flutter",

                style: TextStyle(fontSize: 28, fontWeight: FontWeight.bold),

              ),

              const SizedBox(height: 12),

              const Text("Welcome to Flutter world"),

              const SizedBox(height: 16),

              ElevatedButton(

                onPressed: () {

                  print("Button clicked");

                },

                child: const Text("Click Me"),

              )

            ],

          ),

        ),

      ),

    );

  }

}

鸿蒙 arkts

@Entry

@Component

struct Index {

  @State message: string = 'Hello ArkUI'



  build() {

    Column() {

      Text(this.message)

        .fontSize(28)

        .fontWeight(FontWeight.Bold)



      Text('Welcome to HarmonyOS')

        .margin({ top: 12 })



      Button('Click Me')

        .margin({ top: 16 })

        .onClick(() => {

          console.log('Button clicked')

        })

    }

    .padding(20)

  }

}

原理实现

简述一下实现原理，就是通过parser支持了新语法，然后将新语法转义为 iife包裹的vue的h函数

为什么要iife包裹

因为要支持不渲染代码块

ovs图中的代码对应的编译后的代码是这样的

import {defineOvsComponent} from "/@fs/D:/project/qkyproject/test-volar/ovs/ovs-runtime/src/index.ts";

import {$OvsHtmlTag} from "/@fs/D:/project/qkyproject/test-volar/ovs/ovs-runtime/src/index.ts";

import {ref} from "/node_modules/.vite/deps/vue.js?v=76ca4127";

export default defineOvsComponent(props => {

  const msg = "You did it!";

  let count = ref(0);

  const timer = setInterval(() => {

    count.value = count.value + 1;

  },1000);

  return $OvsHtmlTag.div({class:'greetings',onClick(){

    count.value = 0;

  }},[

    $OvsHtmlTag.h1({class:'green'},[msg]),

    count,

    $OvsHtmlTag.h3({},[

      "You've successfully created a project with ",

      $OvsHtmlTag.a({href:'https://vite.dev/',target:'_blank',rel:'noopener'},['Vite']),

      ' + ',

      $OvsHtmlTag.a({href:'https://vuejs.org/',target:'_blank',rel:'noopener'},['Vue 3']),

      ' + ',

      $OvsHtmlTag.a({href:'https://github.com/alamhubb/ovsjs',target:'_blank',rel:'noopener'},['OVS']),

      '.'

    ])

  ]);

});

parser是我自己写的，抄了 chevortain 的设计，写了个subhuti，支持定义peg语法

github.com/alamhubb/ov…

slimeparser，支持es2025语法的parser，基于subhuti，声明es2025语法就行

github.com/alamhubb/ov…

然后就是ovs继承slimeparser，添加了ovs的语法支持，并且在ast生成的时候将代码转为vue的渲染函数，运行时就是运行的vue的渲染函数的代码，所以完美支持vue的生态

感兴趣的可以试试，入门教程

github.com/alamhubb/ov…

由于本人能力有先，文中存在错误不足之处，请大家指正，有对新语法感兴趣的欢迎留言和我交流

你有没有经历过这样的场景？点击“上传头像”，选了一张照片，页面却毫无反应——没有提示，没有图像，只有一个静默的按钮。你开始怀疑：是没选上？网速慢？还是系统出错了？于是你犹豫要不要再点一次，甚至直接关掉页面。

而如果在你选择文件的瞬间，一张清晰的缩略图立刻出现在眼前，哪怕后端还在处理，你也会安心地等待下去。

不是用户没耐心，而是他们需要一点“确定性”来支撑等待的理由。

图片预览，正是那个微小却关键的信号：你的操作已被接收，一切正在按预期进行。

得到程序正在运行的信号之后用户才会有等待的欲望。

今天，我们就来亲手实现一个图片预览功能。
先思考：要让一张用户选中的本地图片显示在网页上，我们到底需要做些什么？

第一步：我们要显示图片，那肯定得有个 <img> 标签吧？

没错。想在页面上看到图片，最直接的方式就是用 <img :src="xxx" />。但问题来了：用户刚从电脑里选了一张照片，这张照片还在他本地硬盘上，还没传到服务器，也没有公开 URL。那 src 该填什么？

这时候你可能会想：“能不能把这张本地文件直接塞进 src？”

答案是：不能直接塞 File 对象，但——我们可以把它“变成”一个 URL。

第二步：用户选了图，我们怎么拿到它？

通常我们会用 <input type="file" accept="image/*"> 让用户选择图片。在 Vue 中，为了能“拿到”这个 input 元素本身（而不仅仅是它的值），我们会用到 ref。

<input 

  type="file" 

  ref="uploadImage" 

  accept="image/*"

  @change="updateImageData"

/>

这里，ref="uploadImage" 就像给这个 input 贴了个标签。之后在 script 里，我们就能通过 uploadImage.value 拿到它的真实 DOM 引用。

于是，在 updateImageData 函数里，我们可以这样取到用户选中的文件：

const input = uploadImage.value;

const file = input.files[0]; // 用户选的第一张图

注意：不是 input.file，而是 input.files —— 这是一个常见的笔误，也是很多初学者卡住的地方。

第三步：有了 File 对象，怎么变成 <img> 能识别的 src？

现在我们手里有一个 File 对象，但它不能直接赋给 img.src。我们需要把它转成一种浏览器能直接渲染的格式。

这时候，FileReader 就登场了。

const reader = new FileReader();

reader.readAsDataURL(file);

readAsDataURL 会把文件内容读取为一个 Data URL，格式类似：

data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAA...

这串字符串可以直接作为 <img> 的 src！是不是很巧妙？

那什么时候能拿到这个结果呢？FileReader 是异步的，所以我们监听它的 onloadend 事件：

reader.onloadend = (e) => {

  imgPreview.value = e.target.result; // 这就是 Data URL

}

而我们的模板中早已准备好了一个 <img>：

<img :src="imgPreview" alt="" v-if="imgPreview" />

当 imgPreview 有值时，图片就自动显示出来了！

完整逻辑串起来

把这些碎片拼在一起，整个流程就清晰了：

这整个过程完全在前端完成，不需要上传到服务器，也不依赖任何第三方库——只用了浏览器原生 API 和 Vue 的响应式系统。

最后：完整实例

在vue中实现图片预览的完整代码及效果

1. 引言：设计系统的“寒武纪大爆发”与 Arco 的陨落

在 2019 年至 2021 年间，中国前端开发领域经历了一场前所未有的“设计系统”爆发期。伴随着企业级 SaaS 市场的崛起和中后台业务的复杂度攀升，各大互联网巨头纷纷推出了自研的 UI 组件库。这不仅是技术实力的展示，更是企业工程化标准的话语权争夺。在这一背景下，字节跳动推出了 Arco Design，这是一套旨在挑战 Ant Design 霸主地位的“双栈”（React & Vue）企业级设计系统。

Arco Design 在发布之初，凭借其现代化的视觉语言、对 TypeScript 的原生支持以及极具创新性的“Design Lab”设计令牌（Design Token）管理系统，迅速吸引了大量开发者的关注。它被定位为不仅仅是一个组件库，而是一套涵盖设计、开发、工具链的完整解决方案。然而，就在其社区声量达到顶峰后的短短两年内，这一曾被视为“下一代标准”的项目却陷入了令人费解的沉寂。

截至 2025 年末，GitHub 上的 Issue 堆积如山，关键的基础设施服务（如 IconBox 图标平台）频繁宕机，官方团队的维护活动几乎归零。对于数以万计采用了 Arco Design 的企业和独立开发者而言，这无疑是一场技术选型的灾难。

本文将深入剖析 Arco Design 从辉煌到停摆的全过程。我们将剥开代码的表层，深入字节跳动的组织架构变革、内部团队的博弈（赛马机制）、以及中国互联网大厂特有的“KPI 开源”文化，为您还原整件事情的全貌。

2. 溯源：Arco Design 的诞生背景与技术野心

要理解 Arco Design 为何走向衰败，首先必须理解它诞生时的宏大野心及其背后的组织推手。Arco 并不仅仅是一个简单的 UI 库，它是字节跳动为了解决特定业务线极其复杂的后台需求而孵化的产物。

2.1 “务实的浪漫主义”：差异化的产品定位

Arco Design 在推出时，鲜明地提出了“务实的浪漫主义”这一设计哲学。这一口号的提出，实际上是为了在市场上与阿里巴巴的 Ant Design 进行差异化竞争。

• Ant Design 的困境：作为行业标准，Ant Design 以“确定性”著称，其风格克制、理性，甚至略显单调。虽然极其适合金融和后台管理系统，但在需要更强品牌表达力和 C 端体验感的场景下显得力不从心。


• Arco 的切入点：字节跳动的产品基因（如抖音、TikTok）强调视觉冲击力和用户体验的流畅性。Arco 试图在中后台系统中注入这种基因，主张在解决业务问题（务实）的同时，允许设计师发挥更多的想象力（浪漫）。

这种定位在技术层面体现为对 主题定制（Theming） 的极致追求。Arco Design 并没有像传统库那样仅仅提供几个 Less 变量，而是构建了一个庞大的“Design Lab”平台，允许用户在网页端通过可视化界面细粒度地调整成千上万个 Design Token，并一键生成代码。这种“设计即代码”的早期尝试，是 Arco 最核心的竞争力之一。

2.2 组织架构：GIP UED 与架构前端的联姻

Arco Design 的官方介绍中明确指出，该系统是由 字节跳动 GIP UED 团队 和 架构前端团队（Infrastructure FrontEnd Team） 联合推出的。这一血统注定了它的命运与“GIP”这个业务单元的兴衰紧密绑定。

2.2.1 解密 GIP：通用信息平台 (General Information Platform)

GIP 全称为 General Information Platform（通用信息平台）。这是字节跳动早期的核心业务支柱，主要包含以下以“图文与中长视频”为核心的信息分发产品：

• 今日头条：字节跳动的起家之作，智能推荐资讯平台。


• 西瓜视频：中长视频平台。


• 番茄小说：免费网文阅读平台。

2.2.2 业务对技术的反哺与制约

GIP 的业务特点是高信息密度。今日头条的内容审核后台、广告投放系统（早期巨量引擎）、创作者管理平台（头条号后台）都需要处理海量的文本数据和复杂的表格操作。因此，Arco Design 从诞生起就带有浓重的“B 端中后台”基因，强调紧凑、理性和高效率，这正是为了服务于 GIP 庞大的内部系统需求。

在 2019-2020 年，GIP 仍是公司的绝对核心与营收主力。Arco Design 的推出，实际上是字节跳动“长子”（头条系）试图确立公司内部技术标准的一次有力尝试。

2.3 黄金时代的技术堆栈

在 2021 年左右，Arco Design 的技术选型是极具前瞻性的，这也是它能迅速获得 5.5k Star 的原因之一：

• 全链路 TypeScript：所有组件均采用 TypeScript 编写，提供了优秀的类型推导体验，解决了当时 Ant Design v4 在某些复杂场景下类型定义不友好的痛点。


• 双框架并进：@arco-design/web-react 和 @arco-design/web-vue 保持了高度统一的 API 设计和视觉风格。这对于那些技术栈不统一的大型公司极具吸引力，意味着设计规范可以跨框架复用。


• 生态闭环：除了组件库，Arco 还发布了 arco-cli（脚手架）、Arco Pro（中后台模板）、IconBox（图标管理平台）以及 Material Market（物料市场）。这表明团队不仅是在做一个库，而是在构建一个类似 Salesforce Lightning 或 SAP Fiori 的企业级生态。

然而，正是这种庞大的生态铺设，为日后的维护埋下了巨大的隐患。当背后的组织架构发生震荡时，维持如此庞大的产品矩阵所需的资源将变得不可持续。

3. 停摆的证据：基于数据与现象的法医式分析

尽管字节跳动从未发布过一份正式的“Arco Design 停止维护声明”，但通过对代码仓库、社区反馈以及基础设施状态的深入分析，我们可以断定该项目已进入实质性的“脑死亡”状态。

3.1 代码仓库的“心跳停止”

对 GitHub 仓库 arco-design/arco-design (React) 和 arco-design/arco-design-vue (Vue) 的提交记录分析显示，活跃度在 2023 年底至 2024 年初出现了断崖式下跌。

3.1.1 提交频率分析

虽然 React 版本的最新 Release 版本号为 2.66.8（截至文章撰写时），但这更多是惯性维护。

• 核心贡献者的离场：早期的高频贡献者（如 sHow8e、jadelike-wine 等）在 2024 年后的活跃度显著降低。许多提交变成了依赖项升级（Dependabot）或极其微小的文档修复，缺乏实质性的功能迭代。


• Vue 版本的停滞：Vue 版本的状态更为糟糕。最近的提交多集中在构建工具迁移（如迁移到 pnpm）或很久以前的 Bug 修复。核心组件的 Feature Request 长期无人响应。

3.1.2 积重难返的 Issue 列表

Issue 面板是衡量开源项目生命力的体温计。目前，Arco Design 仓库中积累了超过 330 个 Open Issue。

• 严重的 Bug 无人修复：例如 Issue #3091 “tree-select 组件在虚拟列表状态下搜索无法选中最后一个” 和 Issue #3089 “table 组件的 default-expand-all-rows 属性设置不生效”。这些都是影响生产环境使用的核心组件 Bug，却长期处于 Open 状态。


• 社区的绝望呐喊：Issue #3090 直接以 “又一个没人维护的 UI 库” 为题，表达了社区用户的愤怒与失望。更有用户在 Discussion 中直言 “这个是不是 KPI 项目啊，现在维护更新好像都越来越少了”。这种负面情绪的蔓延，通常是一个项目走向终结的社会学信号。

3.2 基础设施的崩塌：IconBox 事件

如果说代码更新变慢还可以解释为“功能稳定”，那么基础设施的故障则是项目被放弃的直接证据。

• IconBox 无法发布：Issue #3092 指出 “IconBox 无法发布包了”。IconBox 是 Arco 生态中用于管理和分发自定义图标的 SaaS 服务。这类服务需要后端服务器、数据库以及运维支持。


• 含义解读：当一个大厂开源项目的配套 SaaS 服务出现故障且无人修复时，这不仅仅是开发人员没时间的问题，而是意味着服务器的预算可能已经被切断，或者负责运维该服务的团队（GIP 相关的基建团队）已经被解散。这是项目“断供”的最强物理证据。

3.3 文档站点的维护降级

Arco Design 的文档站点虽然目前仍可访问，但其内容更新已经明显滞后。例如，关于 React 18/19 的并发特性支持、最新的 SSR 实践指南等现代前端话题，在文档中鲜有提及。与竞争对手 Ant Design 紧跟 React 官方版本发布的节奏相比，Arco 的文档显得停留在 2022 年的时光胶囊中。

4. 深层归因：组织架构变革下的牺牲品

Arco Design 的陨落，本质上不是技术失败，而是组织架构变革的牺牲品。要理解这一点，我们需要将视线从 GitHub 移向字节跳动的办公大楼，审视这家巨头在过去三年中发生的剧烈动荡。

4.1 战略重心的转移：从“头条”到“抖音”

2021 年底至 2024 年，字节跳动进行了多次大规模的组织架构调整。其中最关键的变化是战略重心从图文资讯（今日头条）全面转向短视频与直播（抖音/TikTok）以及后来的 AI 大模型。

• GIP 的边缘化：随着移动互联网进入存量时代，今日头条和西瓜视频的用户增长见顶，战略地位从“增长引擎”退化为“现金牛”甚至“存量维持”业务。


• 资源的抽离：GIP UED 和相关前端团队面临缩编或重组。维护 Arco Design 这样一套庞大的开源系统需要持续的人力投入。当母体部门本身都在进行“去肥增瘦”时，一个无法直接带来商业增量的开源 KPI 项目，自然成为了裁员的首选目标。

4.2 内部赛马机制：Arco Design vs. Semi Design

字节跳动素以“APP 工厂”和“内部赛马”文化著称。这种文化不仅存在于 C 端产品中，也渗透到了技术基建领域。Arco Design 的停摆，很大程度上是因为它在与内部竞争对手 Semi Design 的博弈中败下阵来。

4.2.1 Semi Design 的崛起

Semi Design 是由 抖音前端团队 与 MED 产品设计团队 联合推出的设计系统。

• 出身显赫：与 GIP 不同，Semi Design 背靠的是字节跳动的绝对核心——抖音。抖音前端团队拥有极其充裕的资源和稳固的业务地位。


• 技术路线之争：Semi Design 在架构上更为先进，采用了 Foundation/Adapter 模式，实现了逻辑与渲染分离，能以更低的成本适配不同框架。同时，Semi 深度集成了 D2C（Design-to-Code）工具链，更符合公司对 AI 和人效的追求。

4.2.2 为什么 Arco 输了？

在资源整合期，公司高层显然不需要维护两套功能高度重叠的企业级 UI 库。

• 业务绑定：Semi Design 宣称服务了内部 10 万+ 用户和近千个平台产品，深度嵌入在抖音的内容生产与运营流中。


• 结局：随着 GIP 业务权重的下降和团队的调整，Arco Design 失去了维护的资源，而 Semi Design 成为了事实上的内部标准。

4.3 中国大厂的“KPI 开源”陷阱

Arco Design 的命运也折射出中国互联网大厂普遍存在的“KPI 开源”现象。

• 晋升阶梯：在阿里的 P7/P8 或字节的 2-2/3-1 晋升答辩中，主导一个“行业领先”的开源项目是极具说服力的业绩。因此，很多工程师或团队 Leader 会发起此类项目，投入巨大资源进行推广（刷 Star、做精美官网）。


• 晋升后的遗弃：一旦发起人成功晋升、转岗或离职，该项目的“剩余价值”就被榨干了。接手的新人往往不愿意维护“前人的功劳簿”，更愿意另起炉灶做一个新的项目来证明自己。


• Arco 的轨迹：Arco 的高调发布（2021年）恰逢互联网泡沫顶峰。随着 2022-2024 年行业进入寒冬，晋升通道收窄，维护开源项目的 ROI（投入产出比）变得极低，导致项目被遗弃。

5. 社区自救的幻象：为何没有强有力的 Fork？

面对官方的停摆，用户自然会问：既然代码是开源的（MIT 协议），为什么没有人 Fork 出来继续维护？调查显示，虽然存在一些零星的 Fork，但并未形成气候。

5.1 Fork 的现状调查

通过对 GitHub 和 Gitee 的检索，我们发现了一些 Fork 版本，但并未找到具备生产力的社区继任者。

• vrx-arco：这是一个名为 vrx-arco/arco-design-pro 的仓库，声称是 "aro-design-vue 的部分功能扩展"。然而，这更像是一个补丁集，而不是一个完整的 Fork。它主要解决特定开发者的个人需求，缺乏长期维护的路线图。


• imoty_studio/arco-design-designer：这是一个基于 Arco 的表单设计器，并非组件库本身的 Fork。


• 被动 Fork：GitHub 显示 Arco Design 有 713 个 Fork。经抽样检查，绝大多数是开发者为了阅读源码或修复单一 Bug 而进行的“快照式 Fork”，并没有持续的代码提交。

5.2 为什么难以 Fork？

维护一个像 Arco Design 这样的大型组件库，其门槛远超普通开发者的想象。

因此，社区更倾向于迁移，而不是接盘。

6. 用户生存指南：现状评估与迁移策略

对于目前仍在使用 Arco Design 的团队，局势十分严峻。随着 React 19 的临近和 Vue 3 生态的演进，Arco 将面临越来越多的兼容性问题。

6.1 风险评估表

6.2 迁移路径推荐

方案 A：迁移至 Semi Design（推荐指数：⭐⭐⭐⭐）

如果你是因为喜欢字节系的设计风格而选择 Arco，那么 Semi Design 是最自然的替代者。

• 优势：同为字节出品，设计语言的命名规范和逻辑有相似之处。Semi 目前维护活跃，背靠抖音，拥有强大的 D2C 工具链。


• 劣势：API 并非 100% 兼容，仍需重构大量代码。且 Semi 主要是 React 优先，Vue 生态支持相对较弱（主要靠社区适配）。

方案 B：迁移至 Ant Design v5/v6（推荐指数：⭐⭐⭐⭐⭐）

如果你追求极致的稳定和长期的维护保障，Ant Design 是不二之选。

• 优势：行业标准，庞大的社区，Ant Gr0up 背书。v5 版本引入了 CSS-in-JS，在定制能力上已经大幅追赶 Arco 的 Design Lab。


• 劣势：设计风格偏保守，需要设计师重新调整 UI 规范。

方案 C：本地魔改（推荐指数：⭐）

如果项目庞大无法迁移，唯一的出路是将 @arco-design/web-react 源码下载到本地 packages 目录，作为私有组件库维护。

• 策略：放弃官方更新，仅修复阻塞性 Bug。这需要团队内有资深的前端架构师能够理解 Arco 的源码。

7. 结语与启示

Arco Design 的故事是现代软件工程史上的一个典型悲剧。它证明了在企业级开源领域，康威定律（Conway's Law） 依然是铁律——软件的架构和命运取决于开发它的组织架构。

当 GIP 部门意气风发时，Arco 是那颗最耀眼的星，承载着“务实浪漫主义”的理想；当组织收缩、业务调整时，它便成了由于缺乏商业造血能力而被迅速遗弃的资产。对于技术决策者而言，Arco Design 的教训是惨痛的：在进行技术选型时，不能仅看 README 上的 Star 数或官网的精美程度，更要审视项目背后的组织生命力和维护动机。

目前来看，Arco Design 并没有复活的迹象，社区也没有出现强有力的接棒者。这套组件库正在数字化浪潮的沙滩上，慢慢风化成一座无人问津的丰碑。

你有没有在写前端的时候，突然迷糊了：

• 为啥这张图片能直接 src="https://xxx.jpg" 就能展示？


• 为啥有时候图片是乱七八糟的一串 Base64？


• 有的还整出来个 Blob，看不懂但好像很高级？


• 有时还来个 ArrayBuffer，这又是哪位大哥？


• 最离谱的是：我本地图片路径写进去，怎么就不生效？

这些，其实都和“图像在前端的存在形式”有关。今天咱们就像唠家常一样，一口气整明白这几个常见的前端图像形式，用最接地气的方式讲明白，配上实例、场景分析，帮你彻底建立系统认知！

一、网络 URL：最熟悉的那张脸

<img src="https://example.com/image.jpg" />

这就是我们最常见的方式：网络地址。

📦 本质上是啥？

一个 HTTP(S) 请求，浏览器去服务器上拉图片回来。

👍 优点：

• 用起来最简单，能连网就能显示


• 浏览器会缓存，提高加载效率


• 图片不占你的 HTML 或 JS 文件大小

👎 缺点：

• 依赖网络，断网就 GG


• 跨域可能出问题（特别是 canvas 想处理图片时）


• 没法离线用

🧩 常见场景：

• 图床、CDN 图片


• 用户头像、商品封面等动态内容

二、本地 URL（相对路径）：常被坑的老兄

<img src="./images/logo.png" />

听起来像本地文件，实际上也是被打包进项目的资源文件路径。

⚙️ 本质上是啥？

开发时是相对路径，生产环境通常会被 Webpack、Vite 等构建工具“处理成”一个真实可访问的路径，比如 dist/assets/logo.abcd1234.png。

👀 你可能踩过的坑：

• 路径写错，或者构建工具没配置资源处理，图片加载失败


• 静态服务器没开，直接打开 HTML 无法访问文件（浏览器出于安全考虑禁止 file 协议访问）

💡 使用建议：

• 放到 public 目录，或者使用 import 静态资源方式处理


• 建议使用构建工具配置 alias 简化路径

三、Base64：字节转码“图片串”

<img src="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAA..." />

这是把图片数据编码成 Base64 的字符串，直接塞进 HTML 或 JS 文件里。

🔬 本质上是啥？

Base64 是一种将二进制数据编码成 ASCII 字符串的方式。

✅ 优点：

• 免请求！嵌入式图片，一起打包进页面


• 没有跨域问题


• 非常适合小图标、loading 动画、SVG

❌ 缺点：

• 体积暴涨，大概比原图多 33%


• 可读性差，不利于维护


• 页面初始加载变慢

🧩 常见场景：

• CSS background-image


• 富文本编辑器中的粘贴图像


• 邮件嵌入图像

四、Blob：文件对象，前端造图必备

const blob = new Blob([arrayBuffer], { type: 'image/png' });

const url = URL.createObjectURL(blob);

img.src = url;

这是处理文件流时常见的一种格式。

🔍 本质上是啥？

Blob 是浏览器提供的一种二进制大对象，可以把它看作 JS 里的“文件”。

💪 优点：

• 可由 JS 动态生成，支持下载、预览、上传


• 可控制 MIME 类型，灵活性强


• 可以通过 URL.createObjectURL() 生成临时地址

📉 缺点：

• 是内存对象，页面刷新就没了


• 不能跨页面共享（临时的）

🧩 常见场景：

• 前端截图（canvas.toBlob()）


• 文件上传预览


• 后台生成图片后前端下载

五、ArrayBuffer / Uint8Array：最低层的图像数据表示

fetch('image.jpg')

  .then(res => res.arrayBuffer())

  .then(buffer => {

    // 可以转为 blob 或 base64 再显示

  });

这是最底层的图像数据，直接以字节数组的形式存在。

🧠 本质上是啥？

ArrayBuffer 是一段原始的内存区域，常用于处理二进制数据，Uint8Array 是对它的视图（读取用）。

🧰 常见用途：

• 图像处理（比如 AI 模型的图片输入）


• 自定义图片加载器（如通过 WASM 解码）


• 二进制传输协议

🔄 转换方式：

• 转为 Blob：new Blob([buffer])


• 转为 Base64：btoa(String.fromCharCode(...new Uint8Array(buffer)))

🔄 图像形式转换总结表格

🧠 最后的总结：选哪种图像形式？

• ✅ 展示外部图 → 用 URL


• ✅ 项目图标/静态资源 → 本地路径


• ✅ 上传/预览/截图 → Blob


• ✅ 处理图像数据 → ArrayBuffer


• ✅ 小图或嵌入内容 → Base64

掌握这些图像“存在形式”，不仅能帮你写出更高效、稳定的代码，更能在项目中灵活切换，游刃有余！

如果你觉得这篇有点帮助，别忘了点个赞或者收藏一下～

0. 先抛结论，再吵不迟

结论：

• 极致性能/SSG/Edge → fetch 已足够；


• 企业级、需要全局拦截、上传进度 → Axios 仍值得；


• 二者可共存：核心链路与首页用 fetch，管理后台用 Axios。

1. 3 kB 到底贵不贵？

2026 年 1 月，HTTP Archive 最新采样（Chrome 桌面版）显示：

• 中位 JS 体积 580 kB，3 kB 似乎“九牛一毛”；


• 但放到首屏预算 100 kB 的站点（TikTok 推荐值），3 kB ≈ 3 % 预算，再加 120 ms 阻塞，LCP 直接从 1.5 s 飙到 1.62 s，SEO 评级掉一档。

“ bundle 每 +1 kB，4G 下 FCP +8 ms”——Lighthouse 2025 白皮书。

2. 把代码拍桌上：差异只剩这几行

下面 4 个高频场景，全部给出“可直接复制跑”的片段，差异一目了然。

2.1 自动 JSON + 错误码

// Axios：零样板

const {data} = await axios.post('/api/login', {user, pwd});



// fetch：两行样板

const res = await fetch('/api/login', {

  method:'POST',

  headers:{'Content-Type':'application/json'},

  body:JSON.stringify({user, pwd})

});

if (!res.ok) throw new Error(res.status);

const data = await res.json();

争议：

• Axios 党：少写两行，全年少写 3000 行。


• fetch 党：gzip 后 3 kB 换两行？ESLint 模板一把就补全。

2.2 超时 + 取消

// Axios：内置

const source = axios.CancelToken.source();

setTimeout(() => source.cancel('timeout'), 5000);

await axios.get('/api/big', {cancelToken: source.token});



// fetch：原生 AbortController

const ctl = new AbortController();

setTimeout(() => ctl.abort(), 5000);

await fetch('/api/big', {signal: ctl.signal});

2025 之后 Edge/Node 22 已全支持，AbortSignal.timeout(5000) 一行搞定：

await fetch('/api/big', {signal: AbortSignal.timeout(5000)});

结论：语法差距已抹平。

2.3 上传进度条

// Axios：progress 事件

await axios.post('/upload', form, {

  onUploadProgress: e => setProgress(e.loaded / e.total)

});



// fetch：借助 `xhr` 或 `ReadableStream`

// 2026 仍无原生简易方案，需要封装 `xhr` 才能拿到 `progress`。

结论：大文件上传场景 Axios 仍吊打 fetch。

2.4 拦截器（token、日志）

// Axios：全局拦截

axios.interceptors.request.use(cfg => {

  cfg.headers.Authorization = `Bearer ${getToken()}`;

  return cfg;

});



// fetch：三行封装

export const $get = (url, opts = {}) => fetch(url, {

  ...opts,

  headers: {...opts.headers, Authorization: `Bearer ${getToken()}`}

});

经验：拦截器一旦>2 个，Axios 顺序地狱频发；fetch 手动链式更直观。

3. 实测！同一个项目，两套 bundle

测试场景

• React 18 + Vite 5，仅替换 HTTP 层；


• 构建目标：es2020 + gzip + brotli；


• 网络：模拟 4G（RTT 150 ms）;


• 采样 10 次取中位。

数据来自 rebrowser 2025 基准 ；阻塞时间差异与 51CTO 独立测试吻合 。

4. 什么时候一定要 Axios？

5. 共存方案：把 3 kB 花在刀刃上

// core/http.js

export const isSSR = typeof window === 'undefined';

export const HTTP = isSSR || navigator.connection?.effectiveType === '4g'

  ? { get: (u,o) => fetch(u,{...o, signal: AbortSignal.timeout(5000)}) }

  : await import('axios');   // 动态 import，只在非 4G 或管理后台加载

结果：

• 首屏 0 kB；


• 管理后台仍享受 Axios 拦截器；


• 整体 bundle 下降 7 %，LCP −120 ms。

6. 一句话收尸

2026 年的浏览器，fetch 已把“缺的课”补完：取消、超时、Node 原生、TypeScript 完美。

3 kB 的 Axios 不再是“默认”，而是“按需”。

上传进度、深链拦截、老浏览器——用 Axios；

其余场景，让首页飞一把，把 120 ms 还给用户。

在写前端的时候，我们实现的比较多的一些基础交互，比如折叠面板、弹窗、输入提示、进度条或颜色选择等等，会不得不引入 JavaScript。

但其实，HTML 自己也内置了不少功能强大的原生标签，它们开箱即用、语义清晰，还能大幅减少 JS 的代码量。

下面介绍 5 个冷门但实用的 HTML 标签。

1. <details> 和 <summary> - 可折叠内容

替代： 手风琴效果、折叠面板、FAQ部分

<details>

  <summary>点击查看详情</summary>

  <p>隐藏的内容，无需JS实现展开/收起</p>

</details>

实现效果：

使用场景

• FAQ 折叠面板


• 设置项分组展开


• 移动端“查看更多”区域

注意事项

• 默认是关闭状态；添加 open 属性可默认展开：<details open>


• 可通过 CSS 的 details[open] 选择器定制展开样式


• 支持键盘操作（Enter/Space 触发），无障碍友好

2. <dialog> - 原生对话框

替代：div模拟模态框 + 背景遮罩 + 关闭逻辑

<dialog id="modal">

  <p>这是原生弹窗</p>

  <button onclick="document.getElementById('modal').close()">关闭</button>

</dialog>

<button onclick="document.getElementById('modal').showModal()">打开弹窗</button>

实现效果：

使用场景

• 确认提示框


• 登录/注册弹窗


• 临时信息展示

注意事项

• .showModal() 会自动创建半透明遮罩（可通过 ::backdrop 自定义）


• .show() 是非模态显示（不锁定背景）


• 聚焦自动管理：打开时聚焦第一个可聚焦元素，关闭后焦点返回触发按钮


• 兼容性：Chrome/Firefox/Edge 支持良好；Safari 15.4+ 支持；IE 不支持

3. <datalist> - 输入建议列表

替代：监听input事件 + 动态生成下拉列表

<input list="browsers" placeholder="选择或输入浏览器">

<datalist id="browsers">

  <option value="Chrome">

  <option value="Firefox">

  <option value="Safari">

</datalist>

实现效果：

使用场景

• 搜索建议（非强制选项）


• 表单字段预填（如城市、产品名）


• 快速输入辅助

注意事项

• 用户仍可输入不在列表中的值（与 <select> 不同）


• 浏览器会自动根据输入过滤匹配项


• 移动端会调出带建议的软键盘（部分浏览器支持）

4. <meter> & <progress> - 进度指示器

替代：div模拟进度条 + JS更新宽度

<!-- 已知范围内的标量值（如磁盘使用率） -->

<meter min="0" max="100" value="70">70%</meter>



<!-- 任务完成进度（如文件上传） -->

<progress value="50" max="100">50%</progress>

实现效果：

使用场景

• 搜索建议（非强制选项）


• 表单字段预填（如城市、产品名）


• 快速输入辅助

注意事项

• 用户仍可输入不在列表中的值（与 <select> 不同）


• 浏览器会自动根据输入过滤匹配项


• 移动端会调出带建议的软键盘（部分浏览器支持）

5. <input type="color"> - 颜色选择器

替代：自定义颜色选择器UI + 色值转换逻辑

<input type="color" value="#ff0000">

实现效果：

使用场景

• 主题配色设置


• 图表颜色配置


• 设计工具中的拾色功能

注意事项

• 返回值始终为 小写 7 位十六进制（如 #ff5733）


• 移动端会调出系统级颜色选择器


• 无法自定义 UI，但可通过 ::-webkit-color-swatch 微调样式（有限）

总结

• <details> / <summary>：实现折叠内容


• <dialog>：原生弹窗，自带遮罩和焦点管理


• <datalist>：输入建议选择


• <meter> / <progress>：进度展示无需手动计算宽度


• <input type="color">：系统级颜色选择器开箱即用

这些原生 HTML 标签虽然不太起眼，但用好它们，不仅能省去大量 JavaScript 逻辑，还能让页面更语义化、更友好。

本文首发于公众号：程序员大华，专注分享前后端开发的实战笔记。关注我，少走弯路，一起进步！

前言

最近两年左右的时间，我一口气肝了8个实现项目。

包含了各种业界常见的技术，比如：SpringBoot、SpringCloud、SpringCloud Alibaba、Mybatis、JPA、Redis、MongoDB、ElasticSearch、MySQL、PostgreSQL、Minio、Caffine、RocketMQ、Prometheus、Grafana、ELK、skywalking、Sentinel、Nacos、Redisson、shardingsphere、HikariCP、guava、WebFlux、nacos、Sentinel、WebSocket、Gateway、Nginx、Docker、Spring AI、Spring AI Alibaba等等，非常值得一看。

今天给大家介绍一下这些项目，感兴趣的小伙伴，可以一起交流学习一下，干货满满。

1 100万QPS短链系统

使用技术：JDK21、SpringBoot3.5.3、JPA、Redis、布隆过滤器、Sentinel、Nacos、Redisson、shardingsphere、HikariCP、guava、Prometheus等。

目前设计了32个数据库，每个数据库包含了256张表。

每天可支持2.6亿以上的数据写入。

100万QPS短链系统的系统架构图如下：

技术亮点：

该项目的亮点是：

基于时间片的布隆过滤器流程图如下：

短链系统平滑扩容方案如下：

通过这个项目，可以学到很多高并发、流量评估、分库分表、多级缓存、多级布隆过滤器、限流、熔断、多线程、监控、报警、数据扩容、集群、广播消息、单元测试编写等多方面的知识。

目前这个项目包含两端代码：

想进大厂的小伙伴们，一定不要错过这个项目，里面有很多加分项。

点击这里获取项目源代码和教程：www.susan.net.cn/project

2 SaaS点餐系统

使用技术：JDK21、SpringBoot3.4.3、SpringCloud、SpringCloud Alibaba、Gateway、Mybatis、PostgesSQL、Redis、RocketMQ、ElasticSearch、Knife4j、Prometheus、Grafana、Minio、数据隔离等。

SaaS点餐系统是一套：DDD开发模式+多租户+PostgesSQL 的复杂微服务系统。

包含了9个微服务。

系统整体架构如下：

数据隔离方案如下：

DDD开发模式的代码示例：

通过这个项目可以掌握DDD开发模型、多租户数据隔离的方案实现、PostgresSQL数据库的使用，还有微服务之间的数据交换，网关服务的统一处理，以及复杂系统的职责领域的划分。

运行效果：

3 商城微服务系统

susan_mall_cloud是微服务项目。

使用了目前业界比较新的技术：JDK17、Spring6、SpringBoot3.3.5、SpringCloud2024、SpringCloud Alibaba2023.0.1.0。

微服务后端包含了：

• susan-mall-common （公共文件）


• susan-mall-gateway （网关服务）


• susan-mall-basic (基础服务)


• susan-mall-auth （权限服务，包含用户和权限相关的）


• susan-mall-product （商品服务）


• susan-mall-order （订单服务）


• susan-mall-pay （支付服务）


• susan-mall-member （会员服务）


• susan-mall-marketing （营销服务）


• susan-mall-admin（后台管理系统API）


• susan-mall-mobile（移动端API）

这个版本在商城已有技术基础之上，又增加了：SpringCloud Gateway、WebFlux、Seata、Skywaking、OpenFeign、Loadbalancer、Sentinel、Nacos、Canal、xxl-job、Prometheus、K8S等。

项目架构图：

目前包含了多端代码：

下面是商城小程序真实的截图：

看起来是不是非常专业？

商城微服务项目很复杂，包含了目前业界微服务分布式系统中使用最主流的技术，强烈推荐一下。

无论在工作中，还是面试中，都可以作为加分项。

特别是SpringCloud Gateway中WebFlux的使用，微服务之间的异常处理，以及微服务之间的通信，都很值得一看。

4 商城系统

商城系统目前包含了：SpringBoot后端 + Vue管理后台 + uniapp小程序 ，三个端的完整代码。

商城项目中包含了：基于Docker部署教程、域名解析教程、按环境隔离、网络爬虫、推荐算法、支付宝支付、分库分表、分片算法优化、手写动态定时任务、手写通用分页组件、JWT登录验证、数据脱敏、动态workId、hanlp敏感词校验，手写分布式ID生成器、分布式限流、手写Mybatis插件、两级缓存提升性能、MQ消息通信、ES商品搜索、OSS服务对接、失败自动重试机制、接口幂等性处理、百万数据excel导出、WebSocket消息推送、用户异地登录检测、freemarker模版邮件发送、代码生成工具、重复请求自动拦截、自定义金额校验注解等等一系列功能。

使用的技术：

商城系统的系统架构图如下：

包含了：

• 应用层：小程序、移动端H5、管理后台


• 网关层：Nginx反向代理和负载均衡


• 服务层：API服务、Job服务 & mq消费者服务


• 数据存储层：susan_mall库MySQL主从、susan_mall_order库MySQL分库分表、MongoDB保存商品详情、Minio存储文件


• 中间件层：Redis集群、RocketMQ、ElasticSearch、Nacos（注册中间 & 配置中心）

商城系统的技术架构图如下：

使用的都是目前业界非常主流和常用的技术，这些技术大部分公司目前都在使用。

商城系统可以帮你真正增加很多企业级项目经验。

功能亮点：

商城项目无论是毕业设计，还是面试，还是实际工作中，都非常值得一看。

商城项目使用了目前非常主流的技术，手写了很多底层的代码，设计模式、自定义了很多拦截器、过滤器、转换器、监听器等，很多代码可以搬到实际的工作中。

目前星球中包含了商城项目从0~1的完整开发教程，小白也可以直接上手。

星球中有些小伙伴，通过这个项目拿到了非常不错的offer。

点击这里获取项目源代码和教程：www.susan.net.cn/project

5. 秒杀系统

苏三的秒杀系统是专门为高并发而生的。

目前使用的技术有：SpringBoot、Redis、Redission、lua、RocketMQ、ElasticSearch、JWT、freemarker、themelaf、html、vue、element-ui等。

功能包括：商品预热、商品秒杀、分布式锁、MQ异步下单、限流、失败重试、预扣库存、数据一致性处理等。

涉及到了高并发的多种技术，特别是对页面静态化，倒计时、秒杀按钮控制、分布式锁、预扣库存、MQ处理、数据一致性等，会有比较大的收获。

秒杀系统的系统架构图：

可以帮你增加高并发的工作经验，也可以写到你的简历中。

秒杀系统在面试或者工作中，会经常遇到，非常有参考价值。

6 刷题吧小程序

IT刷题吧是我用AI花了几天时间，设计和开发了一款小程序。

效果图如下：

为了帮助大家能够快速的掌握使用AI开发项目的技巧，提升开发效率，能够先人一步，变成全栈开发工程师。

无论是自己接私活，还是开发公司的项目，都能够用更少的时间，写出更多，更有价值的代码。

苏三在知识星球中给小伙伴们，通过IT刷题吧项目，专门开设了一个AI开发课程。

你看完之后，会发现打开了一扇通向新世界的大门。（有很多惊喜）

这个课程会包含如下内容：

• 如何用AI设计产品原型的？


• 如何用AI生成小程序端和后端的代码结构的？


• 如何用AI生成后端的表结构？


• 如何用AI生成小程序和后端代码？


• 如何生成一套完整的可运行的代码？


• 如何基于图片生成想要的代码？


• 如何搞定小程序页面中的图片问题？


• 如何让小程序端和后端代码调通？


• 生成的代码不理想怎么办？


• 如果在开发过程中遇到了一些问题，用AI如何解决问题？


• 如何生成测试数据？


• 如何制定代码开发规范？


• AI开发工具的使用方法


• AI开发工具卡顿怎么办？


• 如何运行项目？


• 如何上线部署项目？
  等等。。。

星球中会交付如下内容：

目前已经全部开发完。

使用AI开发这个项目，从0~1的开发和部署教程。
问题答疑。
通过这个项目，你可以学到使用AI开发项目的具体方法。

如果你掌握了这些方法，开发其他的小程序绰绰有余。

这个项目有极大的价值。

授人予鱼，不如授人以渔。

光是学会这个项目，就有极大的价值。

7. 苏三的demo项目

这个项目包含了一些工作中常用的技术点，有很多非常有参考价值的示例。

涵盖：Spring、Mybatis、多线程、事务、常用工具、设计模式、http请求、lamda、io、excel、泛型、注解等多个方面。

本项目的宗旨是分享实际工作中，非常实用的代码技巧，能够让你写出更优雅高效的代码。

此外，后面会收录一下面试中，尤其是笔试中经常会被问题到的代码片段和算法。

8. 代码生成器项目

这是一个基于Spring Boot的智能代码生成器，能够根据数据库表结构自动生成完整的Java Web项目代码，极大提升开发效率，让开发者专注于业务逻辑而非重复的CRUD代码编写。

我们用这个代码生成器，可以通过数据库表，一键直接生成controller、service、mapper、entity、菜单sql、vue页面等。

使用的技术：SpringBoot、MyBatis、Apache Velocity、Swagger2、Lombok、Druid、Maven等。

我们在日常开发中，把数据库表设计好了之后，然后通过该工具，能够快速生成一个可以直接运行的CRUD代码。

毫不夸张的说，如果在项目中使用它，可以让你的开发效率快速提升，我们真的可以少写30%的代码。

在实际工作中，非常有价值。

点击这里获取项目源代码和教程：www.susan.net.cn/project

在前端开发中，“生成唯一 ID” 是高频需求 —— 从列表项标识、表单临时存储，到数据缓存键值，都需要一个 “绝对不重复” 的标识符。但看似简单的需求下，藏着很多容易踩坑的实现方式，稍有不慎就会引发数据冲突、逻辑异常等问题。

今天我们就来拆解常见误区，带你掌握真正可靠的唯一 ID 生成方案。

一、为什么 “唯一 ID” 比想象中难？

唯一 ID 的核心要求是 “全局不重复”，但前端环境的特殊性（无状态、多标签页、高并发操作），让很多看似合理的方案在实际场景中失效。

下面两种常见实现，其实都是 “伪唯一” 陷阱。

❌ 误区 1：时间戳 + 随机数（Date.now() + Math.random()）

很多开发者会直觉性地将 “时间唯一性” 和 “随机唯一性” 结合，写出这样的代码：

// 错误示例：看似合理的“伪唯一”方案

function generateNaiveId() {

  // 时间戳转36进制（缩短长度）+ 随机数截取

  return Date.now().toString(36) + Math.random().toString(36).substr(2);

}

// 示例输出：l6n7f4v2am50k9m7o4

这种方案的缺陷在高并发场景下会暴露无遗：

• 时间戳精度不足：Date.now() 的精度是毫秒级（1ms），如果同一毫秒内调用多次（比如循环生成、高频接口回调），ID 的 “时间部分” 会完全重复；


• 伪随机性风险：Math.random() 生成的是 “非加密级随机数”，其算法可预测，在短时间内可能生成重复的序列，进一步增加冲突概率。

结论：仅适用于低频次、非核心场景（如临时展示用 ID），绝对不能用于生产环境的核心数据标识。

❌ 误区 2：全局自增计数器

另一种思路是维护一个全局变量自增，看似能保证 “有序唯一”：

// 错误示例：自增计数器方案

let counter = 0;

function generateIncrementId() {

  return `id-${counter++}`;

}

// 示例输出：id-0、id-1、id-2...

但在浏览器环境中，这个方案的缺陷更致命：

• 无状态丢失：页面刷新、路由跳转后，counter 会重置为 0，之前的 ID 序列会重复；


• 多标签页冲突：用户打开多个相同页面时，每个页面的 counter 都是独立的，会生成完全相同的 ID（比如两个页面同时生成 id-0）。

结论：浏览器环境中几乎毫无实用价值，仅能用于单次会话、单页面的临时标识。

二、王者方案：一行代码实现绝对唯一 —— crypto.randomUUID()

既然简单方案不可靠，我们需要借助浏览器原生提供的 “加密级” 能力。crypto.randomUUID() 就是 W3C 标准推荐的官方解决方案，彻底解决 “唯一 ID” 难题。

1. 用法：一行代码搞定

crypto 是浏览器内置的全局对象（无需引入任何库），专门提供加密相关能力，randomUUID() 方法可直接生成符合 RFC 4122 v4 规范 的 UUID（通用唯一标识符）：

// 正确示例：生成绝对唯一ID

const uniqueId = crypto.randomUUID();

// 示例输出：3a6c4b2a-4c26-4d0f-a4b7-3b1a2b3c4d5e

2. 为什么它是 “绝对唯一” 的？

crypto.randomUUID() 的可靠性源于三个核心优势：

• 极低碰撞概率：v4 UUID 由 122 位随机数构成，组合数量高达 2^122（约 5.3×10^36），相当于 “在地球所有沙滩的沙粒中，选中某一颗特定沙粒” 的概率，实际场景中碰撞概率趋近于 0；


• 加密级随机性：基于 “密码学安全伪随机数生成器（CSPRNG）”，随机性远优于 Math.random()，无法被预测或破解，避免恶意伪造重复 ID；


• 跨环境兼容：生成的 UUID 是全球通用标准格式（8-4-4-4-12 位字符），前端、后端（Node.js、Java 等）、数据库（MySQL、MongoDB）都能直接识别，无需格式转换。

3. 兼容性：覆盖所有现代环境

crypto.randomUUID() 的支持范围已经非常广泛，完全满足绝大多数新项目需求：

• 浏览器：Chrome 92+、Firefox 90+、Safari 15.4+（2022 年及以后发布的版本）；


• 服务器：Node.js 14.17+（LTS 版本均支持）；


• 框架：Vue 3、React 18、Svelte 等现代框架无任何兼容性问题。

三、兼容性兜底方案（针对旧环境）

如果需要兼容旧浏览器（如 IE11）或低版本 Node.js，可以使用第三方库 uuid（轻量、无依赖），其底层逻辑与 crypto.randomUUID() 一致：

安装依赖：

npm install uuid

# 或 yarn add uuid

使用方式：

// 旧环境兜底方案

import { v4 as uuidv4 } from 'uuid';

const uniqueId = uuidv4();

// 示例输出：同标准UUID格式

四、总结：唯一 ID 生成的 “最佳实践”

对于 2023 年后的新项目，直接使用 crypto.randomUUID() 即可 —— 一行代码、零依赖、绝对可靠，彻底告别 “ID 重复” 的烦恼！

前言

话不多说，先演示一下吧。大概功能描述就是，告诉AI“添加日历，今天下午五点到六点，我要去万达吃饭”，然后AI自动将日程同步到日历。

准备工作

开发这个日程助理需要用到MCP、Mac（mac的日历能力）、Windsurf（运行mcp）。技术栈是Typescript。

思路

基于MCP我们可以做很多。关于这个日程助理，其实也是很简单一个尝试，其实就是再验证一下我对MCP的使用。因为Siri的原因，让我刚好有了这个想法，尝试一下自己搞个日程助理。关于MCP可以看我前面的分享
# 前端的AI路其之一： MCP与Function Calling# 前端的AI路其之二：初试MCP Server 。

我的思路如下： 让大模型理解一下我的意图，然后执行相关操作。这也是我对MCP的理解（执行相关操作）。因此要做日程助理，那就很简单了。首先搞一个脚本，能够自动调用mac并添加日历，然后再包装成MCP，最后引入大模型就ok了。顺着这个思路，接下来就讲讲如何实现吧

实现

第一步：在mac上添加日历

这里我们需要先明确一个概念。mac上给日历添加日程，其实是就是给对应的日历类型添加日程。举个例子

左边红框其实就是日历类型，比如我要添加一个开发日程，其实就是先选择"开发"日历，然后在该日历下添加日程。因此如果我们想通过脚本形式创建日程，其实就是先看日历类型存在不存在，如果存在，就在该类型下添加一个日程。

因此这里第一步，我们先获取mac上有没有对应的日历，没有的话就创建一个。

1.1 查找日历

参考文档 mac查找日历

假定我们的日历类型叫做 日程助手。 这里我使用了applescript的语法，因为JavaScript的方式我这运行有问题。

import { execSync } from 'child_process';



function checkCalendarExists(calendarName) {



    const   Script = `tell application "Calendar"

	set theCalendarName to "${calendarName}"

	set theCalendar to first calendar where its name = theCalendarName

end tell`;





  // 执行并解析结果

  try {

    const result = execSync(`osascript  -e '${Script}'`, { 

      encoding: 'utf-8',

      stdio: ['pipe', 'pipe', 'ignore'] // 忽略错误输出

    });



    console.log(result);

    return true;

  } catch (error) {

    console.error('检测失败:', error.message);

    return false;

  }

}



// 使用示例

const calendarName = '日程助手';

const exists = checkCalendarExists(calendarName);

console.log(`日历 "${calendarName}" 存在:`, exists ? '✅ 是' : '❌ 否');

附赠检验结果

现在我们知道了怎么判断日历存不存在，那么接下来就是，在日历不存在的时候创建日历

1.2 日历创建

参考文档 mac 创建日历

import { execSync } from 'child_process';





// 创建日历

function  createCalendar(calendarName) {

    const script = `tell application "Calendar"

        make new calendar with properties {name:"${calendarName}"}

    end tell`;



    try {



        execSync(`osascript -e '${script}'`, { 

            encoding: 'utf-8',

            stdio: ['pipe', 'pipe', 'ignore'] // 忽略错误输出

        });



        return true;

    } catch (e) {

        console.log('create fail', e)

        return false;

    }

}



// 检查日历是否存在

function checkCalendarExists(calendarName) {

    ....

}



// 使用示例

const calendarName = '日程助手';

const exists = checkCalendarExists(calendarName);

console.log(`日历 "${calendarName}" 存在:`, exists ? '✅ 是' : '❌ 否');



if (!exists) {

  const res =    createCalendar(calendarName);



  console.log(res ? '✅ 创建成功' : '❌ 创建失败')

}

运行结果

接下来就是第三步了，在日历“日程助手”下创建日程

1.3 创建日程

import { execSync } from 'child_process';



// 创建日程

function createCalendarEvent(calendarName, config) {



    const script = `var app = Application.currentApplication()

    app.includeStandardAdditions = true

    var Calendar = Application("Calendar")

     

    var eventStart = new Date(${config.startTime})

    var eventEnd = new Date(${config.endTime})

     

    var projectCalendars = Calendar.calendars.whose({name: "${calendarName}"})

    var projectCalendar = projectCalendars[0]

    var event = Calendar.Event({summary: "${config.title}", startDate: eventStart, endDate: eventEnd, description: "${config.description}"})

    projectCalendar.events.push(event)

    event`



    try {

        console.log('开始创建日程');

        execSync(`  osascript -l JavaScript -e '${script}'`, { 

            encoding: 'utf-8',

            stdio: ['pipe', 'pipe', 'ignore'] // 忽略错误输出

        });

        console.log('✅ 日程添加成功');

    } catch (error) {

        console.error('❌ 执行失败:', error);

    }



}



// 创建日历

function  createCalendar(calendarName) {

   ....

}



// 检查日历是否存在

function checkCalendarExists(calendarName) {



 ...

}

这里我们完善一下代码

import { execSync } from 'child_process';



function handleCreateEvent(config) {

    const calendarName = '日程助手';

    const exists = checkCalendarExists(calendarName);

    // console.log(`日历 "${calendarName}" 存在:`, exists ? '✅ 是' : '❌ 否');



    if (!exists) {

        const createRes =  createCalendar(calendarName);



        console.log(createRes ? '✅ 创建日历成功' : '❌ 创建日历失败')



        if (createRes) {

            createCalendarEvent(calendarName, config)

        }

    }  else {

        createCalendarEvent(calendarName, config)

    }

}



// 创建日程

function createCalendarEvent(calendarName, config) {



    const script = `var app = Application.currentApplication()

    app.includeStandardAdditions = true

    var Calendar = Application("Calendar")

     

    var eventStart = new Date(${config.startTime})

    var eventEnd = new Date(${config.endTime})

     

    var projectCalendars = Calendar.calendars.whose({name: "${calendarName}"})

    var projectCalendar = projectCalendars[0]

    var event = Calendar.Event({summary: "${config.title}", startDate: eventStart, endDate: eventEnd, description: "${config.description}"})

    projectCalendar.events.push(event)

    event`



    try {

        console.log('开始创建日程');

        execSync(`  osascript -l JavaScript -e '${script}'`, { 

            encoding: 'utf-8',

            stdio: ['pipe', 'pipe', 'ignore'] // 忽略错误输出

        });

        console.log('✅ 日程添加成功');

    } catch (error) {

        console.error('❌ 执行失败:', error);

    }



}



// 创建日历

function  createCalendar(calendarName) {

    const script = `tell application "Calendar"

        make new calendar with properties {name:"${calendarName}"}

    end tell`;



    try {



        execSync(`osascript -e '${script}'`, { 

            encoding: 'utf-8',

            stdio: ['pipe', 'pipe', 'ignore'] // 忽略错误输出

        });



        return true;

    } catch (e) {

        console.log('create fail', e)

        return false;

    }

}



// 检查日历是否存在

function checkCalendarExists(calendarName) {



    const   Script = `tell application "Calendar"

	set theCalendarName to "${calendarName}"

	set theCalendar to first calendar where its name = theCalendarName

end tell`;





  // 执行并解析结果

  try {

    const result = execSync(`osascript  -e '${Script}'`, { 

      encoding: 'utf-8',

      stdio: ['pipe', 'pipe', 'ignore'] // 忽略错误输出

    });



    return true;

  } catch (error) {

    return false;

  }

}





// 运行示例



const eventConfig = {

    title: '团队周会',

    startTime: 1744183538021,

    endTime: 1744442738000,

    description: '每周项目进度同步',

};



handleCreateEvent(eventConfig)

运行结果

这就是一个完善的，可以直接在终端运行的创建日程的脚本的。接下来我们要做的就是，让大模型理解这个脚本，并学会使用这个脚本

第二步： 定义MCP

基于第一步，我们已经完成了这个日程助理的基本功能，接下来就是借助MCP的能力，教会大模型知道有这个函数，以及怎么调用这个函数

// 引入 mcp

import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js";

import { StdioServerTransport } from "@modelcontextprotocol/sdk/server/stdio.js";

import { z } from "zod";



// 声明MCP服务

const server = new McpServer({

    name: "mcp_calendar",

    version: "1.0.0"

  });



...

// 添加日历函数 也就是告诉大模型 有这个东西以及怎么用

server.tool("add_mac_calendar", '给mac日历添加日程, 接受四个参数  startTime, endTime是起止时间（格式为YYYY-MM-DD HH:MM:SS） title是日历标题  description是日历描述', { startTime: z.string(), endTime: z.string(), title: z.string(), description: z.string() },

async ({ startTime, endTime, title, description }) => {

    const res =  handleCreateEvent({

        title: title,

        description: description,

        startTime: new Date(startTime).getTime(),

        endTime: new Date(endTime).getTime()

      });

      return {

        content: [{ type: "text", text: res ? '添加成功' : '添加失败' }]

      }

})





// 初始化服务

const transport = new StdioServerTransport();

await server.connect(transport);

这里附上完整的ts代码

import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js";

import { StdioServerTransport } from "@modelcontextprotocol/sdk/server/stdio.js";

import { execSync } from 'child_process';

import { z } from "zod";





export interface EventConfig {

    // 日程标题

  title: string;

  // 日程开始时间 毫秒时间戳

  startTime: number;

  // 日程结束时间 毫秒时间戳

  endTime: number;

//   日程描述

  description: string;

}



const server = new McpServer({

    name: "mcp_calendar",

    version: "1.0.0"

  });



function handleCreateEvent(config: EventConfig) {

    const calendarName = '日程助手';

    const exists = checkCalendarExists(calendarName);

    // console.log(`日历 "${calendarName}" 存在:`, exists ? '✅ 是' : '❌ 否');



    let res = false;



    if (!exists) {

        const createRes =  createCalendar(calendarName);



        console.log(createRes ? '✅ 创建日历成功' : '❌ 创建日历失败')



        if (createRes) {

           res = createCalendarEvent(calendarName, config)

        }

    }  else {

        res = createCalendarEvent(calendarName, config)

    }



    return res

}



// 创建日程

function createCalendarEvent(calendarName: string, config: EventConfig) {



    const script = `var app = Application.currentApplication()

    app.includeStandardAdditions = true

    var Calendar = Application("Calendar")

     

    var eventStart = new Date(${config.startTime})

    var eventEnd = new Date(${config.endTime})

     

    var projectCalendars = Calendar.calendars.whose({name: "${calendarName}"})

    var projectCalendar = projectCalendars[0]

    var event = Calendar.Event({summary: "${config.title}", startDate: eventStart, endDate: eventEnd, description: "${config.description}"})

    projectCalendar.events.push(event)

    event`



    try {

        console.log('开始创建日程');

        execSync(`  osascript -l JavaScript -e '${script}'`, { 

            encoding: 'utf-8',

            stdio: ['pipe', 'pipe', 'ignore'] // 忽略错误输出

        });

        console.log('✅ 日程添加成功');



        return true

    } catch (error) {

        console.error('❌ 执行失败:', error);

        return false

    }



}



// 创建日历

function  createCalendar(calendarName: string) {

    const script = `tell application "Calendar"

        make new calendar with properties {name:"${calendarName}"}

    end tell`;



    try {



        execSync(`osascript -e '${script}'`, { 

            encoding: 'utf-8',

            stdio: ['pipe', 'pipe', 'ignore'] // 忽略错误输出

        });



        return true;

    } catch (e) {

        console.log('create fail', e)

        return false;

    }

}



// 检查日历是否存在

function checkCalendarExists(calendarName: string) {



    const   Script = `tell application "Calendar"

	set theCalendarName to "${calendarName}"

	set theCalendar to first calendar where its name = theCalendarName

end tell`;





  // 执行并解析结果

  try {

    const result = execSync(`osascript  -e '${Script}'`, { 

      encoding: 'utf-8',

      stdio: ['pipe', 'pipe', 'ignore'] // 忽略错误输出

    });



    return true;

  } catch (error) {

    return false;

  }

}





server.tool("add_mac_calendar", '给mac日历添加日程, 接受四个参数  startTime, endTime是起止时间（格式为YYYY-MM-DD HH:MM:SS） title是日历标题  description是日历描述', { startTime: z.string(), endTime: z.string(), title: z.string(), description: z.string() },

async ({ startTime, endTime, title, description }) => {

    const res =  handleCreateEvent({

        title: title,

        description: description,

        startTime: new Date(startTime).getTime(),

        endTime: new Date(endTime).getTime()

      });

      return {

        content: [{ type: "text", text: res ? '添加成功' : '添加失败' }]

      }

})



const transport = new StdioServerTransport();

await server.connect(transport);

第三步： 导入Windsurf

在前文已经讲过如何引入到Windsurf，可以参考前文# 前端的AI路其之二：初试MCP Server ，这里就不过多赘述了。 其实在build之后，完全可以引入其他支持MCP的软件基本都是可以的。

接下来就是愉快的调用时间啦。

总结

这里其实是对前文# 前端的AI路其之二：初试MCP Server 的再次深入。算是大概讲明白了Tool方式怎么用，MCP当然不止这一种用法，后面也会继续输出自己的学习感悟，也欢迎各位大佬的分享和指正。

祝好。

这是一个平平无奇的音乐App Vooh，你可以在里面搜索歌曲，添加播放列表，播放音乐。

你可以滑动返回上一级页面，就像任何一个普通的App那样。

你可以流畅地展开音乐播放面板，看着歌词随着播放时间滚动。

当然，你也可以在电脑端，或者iPad上使用这个App。

而它与App的唯一不同，在于安装它不需要下载庞大的安装文件，只需要一个链接。音乐播放器Vooh的本体，只是一个网页。

作为一个诞生了好几年的老技术，PWA（Progressive Web Application）自诞生以来一直都不温不火，Google对它的愿景是最终所有的网页都能做到和App一致的体验，但直到现在，它都像是一道可有可无的饭后甜点。对于网页来说，即用即走似乎是它与生俱来的诅咒，用户既没有将Web安装到桌面的必要，也没有这个耐心，毕竟对于网络延迟增加1秒都可能导致访问量降低80%的地狱难度模式的网页用户生态而言，让一个浏览器用户点击一个陌生的“Install as application”的按钮简直是天方夜谭。尽管它就在那里，但乐于尝试的人似乎总是寥寥无几。既然PWA和纯网页能做的事情相差无几，那为什么还要浪费桌面空间增加一个以后可能再也不会使用的图标呢？

我一直认为，PWA应该朝着更像App的方向努力，才能体现出它的价值。然而，目前的许多PWA，看起来只是把普通的网页做成了全屏，与在浏览器中的体验别无二致，做不出差异化，用户自然没有动力去安装PWA，PWA那些听起来十分美好的特性便成了空中楼阁，无源之水，这个名字也越来越将从人们的视野中慢慢淡去。

如何才能让PWA更像APP，这是一个问题。毕竟浏览器的交互逻辑和原生App相比，有着很大的区别，用户早已习惯了移动浏览器中的前进后退，页面加载时的白屏，以及几乎不存在的手势交互，似乎在说，没关系，这就是网页，它做到这个份上已经足够了。然而，若要把这份体验带到模仿原生App的PWA中去，那势必将迎来用户预期低落的反噬，连这样那样的交互体验都没有，还能叫App？

为了了解目前的PWA究竟能做到何种地步，我开发了Vooh，一个竭尽可能模仿原生App实现的PWA音乐播放器。它尽力实现了一个原生App应该具备的一切交互细节，包括页面间自然的动画过渡，跟手的手势交互，为触屏优化的样式细节等等，我尽可能将它的每个细节都尽可能地做到与App别无二致，就是为了探索Web能力的极限。而在这之后，我也打算将Vooh的实现原理整理出来，并且准备逐步将之前的做过的项目“App化”，来一窥Google期待的未来，究竟是什么样子。

无处不在的过渡动画

尽管Vue，React以及原生CSS都提供了方便的方式实现过渡动画，但是对于大多数网页来说，一个Loading动画可能就是整个页面里动画最多的地方了。这对于网页来说的确无关紧要，毕竟用户们早已习惯了浏览器里生硬的切换效果，没有成体系的交互反馈，以及突然消失出现的页面区域。尽管在许多成熟组件库慢慢开始注重交互动画的优化之后，这样的情况在慢慢改善，但是依然难以改变用户的刻板印象。因此，为用户的预期提供动画反馈是伪装成原生App的一个关键步骤，否则，缺少反馈的使用体验会一下子将用户安装和使用PWA的欲望拉得很低。

除去老生常谈的按钮悬浮、按下时的动画，页面间的过渡动画也是不可缺少的一环。如果你仔细观察iOS的Tab页面，就能发现在切换Tab的时候，也会有细微的不易察觉的缩放淡出渐变，正是这种细致入微的动画组成了iOS App丝滑体验中重要的一部分。

表单组件的动画效果也很重要，Vooh尽可能地使用了iOS风格的表单组件，例如Button，Switch等，以贴合用户的日常视觉体验。

手势交互

手势是网页与App的重要差异点，一般来说，很少会有网页支持用户的滑动返回，长按呼出菜单等复杂的手势操作，而这正是让你的PWA丝般顺滑的关键。

需要注意的是，由于大部分移动浏览器和JS本身单线程的限制，手势交互依赖监听器的执行速度，而很难跑满设备屏幕的帧率上限，尤其是iOS设备上，开启低电量模式的情况下，监听器的帧率可能只有不到30 FPS，肉眼可见的卡顿。目前为止，也没有看到任何浏览器厂商有关于优化手势交互的提案，手势交互就像一道横亘在网页与App之间的鸿沟，没有丝毫跨越的可能，只能尽可能地模仿。

离线访问

没有哪个用户能接受打开App时整个页面全部消失无法操作，APP的最大优点就是离线可用，好在Service Worker的推出让这一点不再是问题，通过Service Worker对网页资源进行缓存，可以实现在低网速甚至离线环境下，也能继续使用PWA，就像真正的App那样。

然而不幸的是，在iOS设备上，Service Worker离线缓存不再可用，开启飞行模式或者关闭网络连接后将无法访问任何网页，包括已经安装在桌面上的PWA，

偶遇现代IE厂商，拼尽全力无法战胜。

细节之外的细节

而Vooh在这些基础能力之外，还增加了许多其他的细节设计，让整个App在模仿原生App时更进一步。

1，存储占用管理

在移动设备上，PWA与App的存储占用是分隔开的，而且往往要经过十分复杂的步骤才能看到PWA的实际空间占用，因此对于音乐播放器这种高度依赖本地资源的应用来说，一个显而易见的存储占用管理系统能有效缓解用户的存储焦虑。

2，接入系统播放器

隆重介绍Media Session API，它能让JS直接接入系统播放器控件，即使在后台也可以允许用户通过系统自带的播放器控制媒体的播放，例如下一曲、播放暂停等，在iOS设备上，还能直接适配灵动岛，这下谁还能分辨谁是原生App。

3，深色模式

在Apple等手机厂商的推动下，大部分的App都已经适配深色模式，而网页对于深色模式的适配比起App要更为简单，毕竟CSS实在是太灵活了，Vooh当然也做了适配，在不同的模式下都能完美贴合系统的主体模式。

为了提升Vooh与其他原生播放器的（根本不存在的）竞争力，我也煞费苦心地加入了许多的细节，来让用户有真正使用它的动力，例如根据歌曲封面动态取色，自动识别的滚动歌词等，希望能让它在用户的手机桌面上多待一段时间。

未竟之事

不过，即使是做到了这个地步，PWA的能力始终是有极限的。有些App轻易能做到的事，对于PWA而言犹如天堑一般遥不可及，包括但不限于：

1，后台活动

在移动设备上，网页也好，PWA也好，基本上没有任何后台活动能力，甚至上面提到的Media Session API，在iOS上顶多也只最多能支持后台播放1～2首歌曲，然后就会被强行停止，更不用说后台导航，推送通知这种活在梦里的API了，这方面浏览器天生就是残废，未来也看不到有任何改进的可能，因此在开发PWA时，一定要远离这些方向。在js都能跑虚拟机，剪视频的当下，Web开发者们推送一条通知的希冀却只能在另一个平行时空实现了。

2，跳转到PWA

据说Andriod Chrome支持使用PWA来打开特定的链接，不过在iOS上就别想了。

3，触感反馈

同样，Web也只能使用早已被淘汰的Vibrate，细腻的振动反馈和Taptic Engine对网页来说也是天方夜谭。

4，调用原生功能

还有无数浩如烟海的功能是PWA完全无法实现的，例如系统级的音量调节，亮度调节等，我能理解这是浏览器对恶意网站的限制，但这也确实极大限制了Web的发展，比如奠定了Web安全基础的跨域限制，如今成为了许多大型Web应用的掣肘。我由衷地希望某天浏览器能制定一个更宽松的PWA标准，例如安装到桌面后能提供更多的权限，提供一个无跨域限制的fetch代替品等等，然而即使对Web上心如Google，也没有考虑过这个方向的可能性。JS正在和越来越宽松的宿主环境（Tuari，Electron）一步步蚕食着原生GUI开发的领地，而它的发源地，浏览器却只能被所谓的安全性限制，成为一个只负责播放动画的花瓶。

总结

正如所说，一切能由javascript实现的终将会用javascript实现。如今，越来越多的平台小程序，快应用，乃至于H5套壳的App越来越多，随着浏览器性能的进一步提升，Web能做到的事越来越多，但是Web的交互性却并没有随着javascript的繁荣而被重视起来，受限于javascript的单线程特性，要完全模拟App的使用体验还是有一定的差距，一个劲地往原生体验上靠，有时也并不一定是最好的选择，Vooh的出现只是给了开发者们一个可能的方向，Web的轻量，优秀的可触达性与PWA有机结合，才是Web的发展方向。同时也希望各家浏览器厂商们能加快适配新的Web特性，能够让程序们在写代码时少掉一些头发，便是最大的善事了

如果对Vooh的实现方式有兴趣的话，欢迎关注我的专栏或者博客，后续的代码也会一并开源，涉及到音乐版权相关，目前的Vooh只开放了2首免费无版权音乐的使用，代码也不会涉及版权相关的领域。

作者：陈盛靖

一、背景

业务群里面经常反馈，视频播放卡顿，视频播放总是停留在某一时刻就播放不了了。后面经过排查，发现这是因为弱网导致的。然而，用户数量众多，隔三差五总有人在群里反馈，有时问题一时半会好不了，用户就会怀疑不是网络，而是我们的系统问题。因此，我们希望能在弱网的时候展示提示，这样用户体验会更友好，同时也能减少一定的客诉。

二、现状分析

我们使用的播放器是chimee(http://www.chimee.org/index.html)。遗憾的是，chimee并没有视频播放卡顿自动展示loading的功能，不过我们可以通过其插件能力，来编写一个自定义video-loading的插件。

三、方案设计

使用NetworkInformation

常见的方法就是我们通过设定一个标准，然后检测用户设备的网络速度，在到达一定阈值时展示弱网提示。这里需要确定一个重要的点：什么情况下才算弱网？

我们的应用是h5，这里我们可以使用window对象中的NetworkInformation(developer.mozilla.org/zh-CN/docs/…)，我们可以通过浏览器的debug工具，打印window.naviagtor.connection，这个对象内部就存储着网络信息：

其中各个属性含义如下表所示：

其中，我们可以通过effectiveType判断当前网络的大体情况，并且可以拿到一个预估的网络带宽(downlink)。我们可以通过监听onchange事件，在网络变差的时候，展示对应的弱网提示。

这个方案的优点是：

• 浏览器环境原生支持


• 实现相对简单

但缺点却十分明显：

• 网络状态变化非实时

effectiveType的变化可能是分钟级别的，对于短暂的网络波动，状态没办法做更精细的把控

• 存在兼容性问题

对于不同一些主流浏览器不支持，例如Firefox、Safari等

• 不同设备间存在差异

不同的设备和浏览器，由于其差异，在不同的网络情况下，视频的播放情况是不一样的，如果我们固定一个标准，可能会导致在不同设备下，同一个网络速度，有人明明正常播放视频，但是却提示网络异常，这样用户会感到疑惑。

那有没有更好的方法呢？

监听Video元素事件

chimee底层也是在html video上进行的二次封装，我们可以在插件的生命周期中，拿到对应的video元素节点。而在video标签中，存在这样两个事件：waiting和canplay。

其事件描述如下图所示：

当视频播放卡顿时，会触发waiting事件；而当视频播放恢复正常时，会触发canplay事件。只要监听这两个事件，我们就可以实现对应的功能了。

四、功能拓展

我们知道，现在大多数网站的视频在提示弱网的时候，都会展示当前设备的网络速度是多少。因此我们也希望在展示对应的信息。那么怎么实现网络速度的检测呢？

一个简单的方法是，我们可以通过获取一张固定大小的图片资源(不一定是图片，也可以是别的类型的资源），并统计请求该资源的请求速度，从而计算当前网络的带宽是多少。当然，图片大小要尽可能小一点，一是为了节省用户流量，二是为了避免在网络不好的情况下，图片请求太慢导致一直计算不出来。

具体代码如下：

funtion calculateSpeed() {

  // 图片大小772Byte

  const fileSize = 772;

  // 拼接时间戳，避免缓存

  const imgUrl = `https://xxx.png?timestamp=${new Date().getTime()}`;



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

    let start = 0;

    let end = 1000;

    let img = document.createElement('img');

    start = new Date().getTime();

    img.onload = function (e) {

        end = new Date().getTime();

        // 计算出来的单位为 B/s

        const speed = fileSize / (end > start ? end - start : 1000) * 1000;

        resolve(speed);

    }

    img.src = imgUrl;

  }).catch(err => { throw err });

}

function translateUnit(speed) {

  if(speed === 0) return '0.00 B/s';

  if(speed > 1024 * 1024) return `${(speed / 1024 / 1024).toFixed(2)} MB/s`;

  if(speed > 1024) return `${(speed / 1024).toFixed(2)} KB/s`;

  else return `${speed.toFixed(2)} B/s`;

}

我们可以通过setInterval来轮询调用该函数，从而实时展示当前网络情况。系统流程图如下：

五、总结

我们可以通过Chrome浏览器开发者工具中的Network中的网络配置来模拟弱网情况

具体效果如下：

成功实现视频弱网提示，完结撒花🎉🎉🎉🎉🎉🎉。

我正在开发 DocFlow，它是一个完整的 AI 全栈协同文档平台。该项目融合了多个技术栈，包括基于 Tiptap 的富文本编辑器、NestJs 后端服务、AI 集成功能和实时协作。在开发过程中，我积累了丰富的实战经验，涵盖了 Tiptap 的深度定制、性能优化和协作功能的实现等核心难点。

如果你对 AI 全栈开发、Tiptap 富文本编辑器定制或 DocFlow 项目的完整技术方案感兴趣，欢迎加我微信 yunmz777 进行私聊咨询，获取详细的技术分享和最佳实践。

在前端开发中，撤销和重做功能是提升用户体验的重要特性。无论是文本编辑器、图形设计工具，还是可视化搭建平台，都需要提供历史操作的回退和前进能力。这个功能看似简单，但实现起来需要考虑性能、内存占用、用户体验等多个方面。

在构建富文本编辑器时，Tiptap 和 ProseMirror 是两个常见的技术选择。两者都强大且灵活，但它们在设计理念、易用性、扩展性等方面存在差异。对于开发者来说，选择合适的工具对于项目的成功至关重要。本文将深入探讨两者的异同，并通过实际代码示例帮助你理解它们的差异，从而根据具体需求做出决策。

ProseMirror 的优势与挑战

ProseMirror 是一个 JavaScript 库，用于构建复杂的富文本编辑器。它的设计非常底层，提供了一个高效且灵活的文档模型，开发者可以完全控制编辑器的行为和界面。ProseMirror 本身并不提供任何 UI 或组件，而是一个核心库，开发者需要自行实现具体的编辑器功能。

作为一个底层框架，ProseMirror 允许开发者完全控制编辑器的各个方面，包括文档结构、输入行为、UI 样式等。它提供了丰富的 API，可以处理复杂的编辑需求，如数学公式、代码块、图片、链接等。开发者可以为几乎任何功能编写插件，并且可以在已有插件的基础上进行二次开发。基于虚拟 DOM 的设计，使其在大文档和复杂结构下能够提供较高的性能。

然而，由于其底层设计，ProseMirror 的 API 复杂，学习曲线陡峭。开发者需要深入理解其文档模型、事务管理、节点和视图的关系。由于不提供任何 UI 组件，开发者需要从零开始构建编辑器的界面和交互，配置和初始化过程也较为复杂，需要手动处理许多底层逻辑。

ProseMirror 基础使用示例

首先需要安装必要的包：

npm install prosemirror-state prosemirror-view prosemirror-model prosemirror-schema-basic prosemirror-schema-list prosemirror-commands

创建一个基本的 ProseMirror 编辑器需要配置 schema、state 和 view：

import { EditorState } from "prosemirror-state";

import { EditorView } from "prosemirror-view";

import { Schema, DOMParser } from "prosemirror-model";

import { schema } from "prosemirror-schema-basic";

import { addListNodes } from "prosemirror-schema-list";

import { exampleSetup } from "prosemirror-example-setup";



// 扩展基础 schema，添加列表支持

const mySchema = new Schema({

  nodes: addListNodes(schema.spec.nodes, "paragraph block*", "block"),

  marks: schema.spec.marks,

});



// 创建编辑器状态

const state = EditorState.create({

  schema: mySchema,

  plugins: exampleSetup({ schema: mySchema }),

});



// 创建编辑器视图

const view = new EditorView(document.querySelector("#editor"), {

  state,

});

如果需要添加自定义命令，比如一个格式化工具条，需要手动实现：

import { toggleMark } from "prosemirror-commands";

import { schema } from "prosemirror-schema-basic";



// 创建加粗命令

const toggleBold = toggleMark(schema.marks.strong);



// 手动创建工具栏按钮

function createToolbar(view) {

  const toolbar = document.createElement("div");

  toolbar.className = "toolbar";



  const boldBtn = document.createElement("button");

  boldBtn.textContent = "Bold";

  boldBtn.onclick = () => {

    toggleBold(view.state, view.dispatch);

    view.focus();

  };



  toolbar.appendChild(boldBtn);

  return toolbar;

}

ProseMirror 自定义插件示例

创建一个自定义插件需要理解 ProseMirror 的插件系统：

import { Plugin } from "prosemirror-state";



// 创建一个字符计数插件

function characterCountPlugin() {

  return new Plugin({

    view(editorView) {

      const counter = document.createElement("div");

      counter.className = "char-counter";



      const updateCounter = () => {

        const text = editorView.state.doc.textContent;

        counter.textContent = `字符数: ${text.length}`;

      };



      updateCounter();



      return {

        update(view) {

          updateCounter();

        },

        destroy() {

          counter.remove();

        },

      };

    },

  });

}



// 使用插件

const state = EditorState.create({

  schema: mySchema,

  plugins: [characterCountPlugin(), ...exampleSetup({ schema: mySchema })],

});

Tiptap 的便捷开发

Tiptap 是基于 ProseMirror 构建的富文本编辑器框架，它简化了 ProseMirror 的复杂性，提供了现成的 UI 组件和更易于使用的 API。Tiptap 旨在让开发者能够快速实现丰富的富文本编辑器，同时保持较高的灵活性和扩展性。

Tiptap 提供了简洁的 API，开发者不需要深入学习 ProseMirror 的底层概念即可实现基本的富文本编辑功能。它通过封装 ProseMirror 的复杂性，使得开发过程更加直观和简便。开箱即用的 UI 组件，如文本格式化、列表、图片插入等，极大地方便了开发者的使用，减少了开发时间。清晰的文档和活跃的开源社区，也为开发者提供了良好的支持和资源。虽然 Tiptap 进行了封装，但它仍然保留了 ProseMirror 的插件系统，开发者可以根据需要定制功能，并且可以轻松地集成其他插件。此外，Tiptap 可以与 Yjs 或其他 CRDT 库结合，支持实时协作编辑功能，这是 ProseMirror 本身不具备的特性。

不过，由于 Tiptap 封装了 ProseMirror 的很多底层功能，灵活性相对较低。对于一些需要极高自定义的需求，Tiptap 可能不如 ProseMirror 灵活。虽然在大多数情况下性能良好，但在处理超大文档或复杂操作时，性能可能不如直接使用 ProseMirror。

Tiptap 基础使用示例

Tiptap 的安装和使用相对简单：

npm install @tiptap/react @tiptap/starter-kit @tiptap/pm

在 React 中使用 Tiptap：

import { useEditor, EditorContent } from "@tiptap/react";

import StarterKit from "@tiptap/starter-kit";



function TiptapEditor() {

  const editor = useEditor({

    extensions: [StarterKit],

    content: "<p>Hello World!</p>",

  });



  if (!editor) {

    return null;

  }



  return (

    <div>

      <div className="toolbar">

        <button

          onClick={() => editor.chain().focus().toggleBold().run()}

          disabled={!editor.can().chain().focus().toggleBold().run()}

          className={editor.isActive("bold") ? "is-active" : ""}

        >

          Bold

        </button>

        <button

          onClick={() => editor.chain().focus().toggleItalic().run()}

          disabled={!editor.can().chain().focus().toggleItalic().run()}

          className={editor.isActive("italic") ? "is-active" : ""}

        >

          Italic

        </button>

        <button

          onClick={() => editor.chain().focus().toggleBulletList().run()}

          className={editor.isActive("bulletList") ? "is-active" : ""}

        >

          Bullet List

        </button>

      </div>

      <EditorContent editor={editor} />

    </div>

  );

}

Tiptap 的 Vue 版本同样简洁：

<template>

  <div>

    <div class="toolbar">

      <button

        @click="editor.chain().focus().toggleBold().run()"

        :disabled="!editor.can().chain().focus().toggleBold().run()"

        :class="{ 'is-active': editor.isActive('bold') }"

      >

        Bold

      </button>

      <button

        @click="editor.chain().focus().toggleItalic().run()"

        :class="{ 'is-active': editor.isActive('italic') }"

      >

        Italic

      </button>

    </div>

    <editor-content :editor="editor" />

  </div>

</template>



<script>

import { useEditor, EditorContent } from "@tiptap/vue-3";

import StarterKit from "@tiptap/starter-kit";



export default {

  components: {

    EditorContent,

  },

  setup() {

    const editor = useEditor({

      extensions: [StarterKit],

      content: "<p>Hello World!</p>",

    });



    return { editor };

  },

};

</script>

Tiptap 扩展功能示例

Tiptap 支持多种扩展，添加图片功能非常简单：

import Image from "@tiptap/extension-image";

import { useEditor, EditorContent } from "@tiptap/react";

import StarterKit from "@tiptap/starter-kit";



function EditorWithImage() {

  const editor = useEditor({

    extensions: [

      StarterKit,

      Image.configure({

        inline: true,

        allowBase64: true,

      }),

    ],

  });



  const addImage = () => {

    const url = window.prompt("图片URL");

    if (url) {

      editor.chain().focus().setImage({ src: url }).run();

    }

  };



  return (

    <div>

      <button onClick={addImage}>添加图片</button>

      <EditorContent editor={editor} />

    </div>

  );

}

创建自定义扩展也很直观：

import { Extension } from "@tiptap/core";

import { Plugin } from "prosemirror-state";



const CharacterCount = Extension.create({

  name: "characterCount",



  addProseMirrorPlugins() {

    return [

      new Plugin({

        view(editorView) {

          const counter = document.createElement("div");

          counter.className = "char-counter";



          const updateCounter = () => {

            const text = editorView.state.doc.textContent;

            counter.textContent = `字符数: ${text.length}`;

          };



          updateCounter();



          return {

            update(view) {

              updateCounter();

            },

            destroy() {

              counter.remove();

            },

          };

        },

      }),

    ];

  },

});



// 使用自定义扩展

const editor = useEditor({

  extensions: [StarterKit, CharacterCount],

});

Tiptap 实时协作示例

Tiptap 与 Yjs 集成实现实时协作非常简单：

npm install yjs y-prosemirror @tiptap/extension-collaboration @tiptap/extension-collaboration-cursor

import { useEditor, EditorContent } from "@tiptap/react";

import StarterKit from "@tiptap/starter-kit";

import Collaboration from "@tiptap/extension-collaboration";

import CollaborationCursor from "@tiptap/extension-collaboration-cursor";

import * as Y from "yjs";

import { WebrtcProvider } from "y-webrtc";



// 创建 Yjs 文档和提供者

const ydoc = new Y.Doc();

const provider = new WebrtcProvider("room-name", ydoc);



function CollaborativeEditor() {

  const editor = useEditor({

    extensions: [

      StarterKit,

      Collaboration.configure({

        document: ydoc,

      }),

      CollaborationCursor.configure({

        provider,

      }),

    ],

  });



  return <EditorContent editor={editor} />;

}

从代码看差异

让我们通过实现一个带工具栏的编辑器来对比两者的代码复杂度：

在 ProseMirror 中，需要手动管理所有状态和命令：

import { EditorState, Plugin } from "prosemirror-state";

import { EditorView } from "prosemirror-view";

import { schema } from "prosemirror-schema-basic";

import { toggleMark } from "prosemirror-commands";



const state = EditorState.create({ schema });



const toolbarPlugin = new Plugin({

  view(editorView) {

    const toolbar = document.createElement("div");

    toolbar.className = "toolbar";



    const boldBtn = document.createElement("button");

    boldBtn.textContent = "B";

    boldBtn.onclick = (e) => {

      e.preventDefault();

      const { state, dispatch } = editorView;

      const command = toggleMark(schema.marks.strong);

      if (command(state, dispatch)) {

        editorView.focus();

      }

    };



    toolbar.appendChild(boldBtn);

    document.body.insertBefore(toolbar, editorView.dom);



    return {

      destroy() {

        toolbar.remove();

      },

    };

  },

});



const view = new EditorView(document.querySelector("#editor"), {

  state: EditorState.create({

    schema,

    plugins: [toolbarPlugin],

  }),

});

而在 Tiptap 中，相同的功能实现更加简洁：

const editor = useEditor({

  extensions: [StarterKit],

});



return (

  <div>

    <button

      onClick={() => editor.chain().focus().toggleBold().run()}

      className={editor.isActive("bold") ? "is-active" : ""}

    >

      B

    </button>

    <EditorContent editor={editor} />

  </div>

);

如何做出选择

选择 Tiptap 还是 ProseMirror，关键在于项目需求和开发团队的技术能力。

如果你的目标是快速构建一个功能丰富、用户友好的富文本编辑器，且不希望花费过多时间在底层细节上，Tiptap 是一个理想的选择。它提供了简洁的 API 和现成的 UI 组件，可以快速启动和开发。如果你的编辑器需要一些定制功能，但不需要完全控制每个底层细节，Tiptap 提供了足够的灵活性，同时保持了开发的简便性。如果需要实现多人实时协作，Tiptap 内建的对 Yjs 等库的支持可以简化实现过程。

如果你需要完全控制编辑器的行为、界面和性能，ProseMirror 提供了更高的自由度。它适合那些有特定需求的项目，比如自定义文档结构、输入行为或非常复杂的编辑操作。在处理非常大的文档或需要极高性能的场景下，ProseMirror 能提供更好的优化和性能。如果你的项目需要完全自定义插件，或者你想对编辑器进行深度定制，ProseMirror 提供了更高的灵活性。

性能考虑

对于大文档处理，ProseMirror 提供了更细粒度的控制：

// ProseMirror 中可以精确控制更新

const state = EditorState.create({

  schema,

  plugins: [

    // 可以精确控制哪些插件启用

    // 可以自定义更新逻辑

    new Plugin({

      state: {

        init() {

          return {};

        },

        apply(tr, value) {

          // 自定义状态更新逻辑

          return value;

        },

      },

    }),

  ],

});

而 Tiptap 虽然性能良好，但在极端场景下可能不如直接使用 ProseMirror 优化：

// Tiptap 的性能优化选项

const editor = useEditor({

  extensions: [StarterKit],

  editorProps: {

    attributes: {

      class:

        "prose prose-sm sm:prose lg:prose-lg xl:prose-2xl mx-auto focus:outline-none",

    },

    // 可以传递 ProseMirror 的原生配置

  },

  // 但仍然受到封装层的限制

});

生态系统和社区支持

Tiptap 拥有丰富的扩展生态系统：

# Tiptap 官方扩展

npm install @tiptap/extension-image

npm install @tiptap/extension-link

npm install @tiptap/extension-table

npm install @tiptap/extension-code-block-lowlight

npm install @tiptap/extension-placeholder

npm install @tiptap/extension-character-count

npm install @tiptap/extension-typography

而 ProseMirror 的插件需要通过 prosemirror-* 包系列来获取，或者自己实现。官方提供了基础插件，但高级功能需要社区插件或自行开发。

实际项目场景建议

对于博客平台、内容管理系统、笔记应用等常见场景，Tiptap 通常是最佳选择。它的快速开发和丰富的功能足以满足大多数需求。代码示例展示了如何在几分钟内搭建一个功能完整的编辑器。

对于需要特殊文档结构（如学术论文编辑器、代码编辑器、专业排版工具）或对性能有极致要求的场景，ProseMirror 提供了必要的底层控制能力。但需要投入更多时间学习其 API 和概念。

如果你的团队时间有限，或者希望快速迭代，Tiptap 是明智的选择。如果团队有富文本编辑器开发经验，或者有充足时间进行深度定制，ProseMirror 可以带来更高的灵活性和性能。

总结

Tiptap 是一个基于 ProseMirror 的富文本编辑器框架，适合需要快速开发、易用且功能丰富的场景。它封装了 ProseMirror 的复杂性，让开发者能够专注于业务逻辑，而无需关心底层实现细节。通过本文的代码示例可以看出，Tiptap 的 API 设计更加直观，学习曲线平缓，适合大多数项目需求。

ProseMirror 则是一个底层框架，适合那些需要完全控制文档结构、编辑行为和性能优化的高级开发者。它更灵活，但学习曲线较陡峭，适合复杂或定制化需求较强的项目。从代码示例中可以看到，使用 ProseMirror 需要处理更多的底层细节，但同时也获得了更高的控制权。

如果你的项目需要快速构建编辑器并具备一定的自定义能力，Tiptap 是一个更为理想的选择。而如果你的项目需要完全的定制化和高性能处理，ProseMirror 将更符合你的需求。最终的选择应基于你的开发需求、项目规模以及团队的技术能力。建议通过实际代码尝试两者，根据你的具体场景做出最适合的选择。

前言

这篇文章跟大家一起聊聊打印优质日志的10条军规，希望对你会有所帮助。

第1条：格式统一

反例（管理看到会扣钱）：

log.info("start process");

log.error("error happen"); 

无时间戳，无上下文。

正解代码：

<!-- logback.xml核心配置 -->

<pattern>

    %d{yy-MM-dd HH:mm:ss.SSS} 

    |%X{traceId:-NO_ID} 

    |%thread 

    |%-5level 

    |%logger{36} 

    |%msg%n

</pattern>

在logback.xml中统一配置了日志的时间格式、tradeId，线程、等级、日志详情都信息。

日志的格式统一了，更方便点位问题。

第2条：异常必带堆栈

反例（同事看了想打人）：

try {

    processOrder();

} catch (Exception e) {

    log.error("处理失败"); 

}