科创50涨超6%芯片股领涨，聊聊跨境电商平台的技术选型与性能优化

2026-07-23 博客文章

今天科创50涨了6个点，芯片股疯涨，看得我心痒痒。不过咱是搞技术的，还是聊聊本行。最近在做一个跨境电商平台的性能优化，踩了不少坑，今天分享出来，给大家避避雷。

先说说背景。这个平台是做反向海淘的，用户主要是海外华人，高峰期日活有小几万。去年双11的时候，系统差点崩了，页面加载要十几秒，用户骂声一片。老板急了，让我牵头做性能优化，目标是首屏加载控制在2秒以内。

技术选型的那些坑

先说技术栈。他们原来用的是PHP + jQuery，说难听点就是祖传代码。不是说PHP不好，但做现代跨境电商平台，前后端分离是基本操作吧？

我接手后，前端改成了Vue3 + TypeScript，后端用Go + Gin。为什么选Go？因为跨境电商的特点是并发高、IO密集，Go的协程模型天生适合这种场景。而且部署简单，一个二进制文件扔上去就能跑，不用像Java那样配一堆东西。

数据库用的是MySQL 8.0，缓存用Redis。这个组合很常规，但真要做好性能优化，门道多着呢。

// 用Go写的商品详情接口，做了多级缓存

package handler

import (

"context"

"encoding/json"

"time"

"github.com/gin-gonic/gin"

"github.com/go-redis/redis/v8"

"gorm.io/gorm"

)



type ProductHandler struct {

db *gorm.DB

redis *redis.Client

}



// 商品详情缓存key

func productCacheKey(productID int64) string {

    return fmt.Sprintf("product:detail:%d", productID)

}



func (h *ProductHandler) GetDetail(c *gin.Context) {

    productID := c.GetInt64("product_id")

    ctx := context.Background()



    // 第一步：查Redis缓存

    cached, err := h.redis.Get(ctx, productCacheKey(productID)).Result()

    if err == nil && cached != "" {

var product Product

        json.Unmarshal([]byte(cached), &product)

        c.JSON(200, gin.H{"data": product, "from": "cache"})

        return

    }



    // 第二步：查数据库

var product Product

    result := h.db.First(&product, productID)

    if result.Error != nil {

        c.JSON(404, gin.H{"error": "商品不存在"})

        return

    }



    // 第三步：回写缓存，过期时间随机，防止缓存雪崩

    ttl := time.Hour + time.Duration(rand.Intn(1800))*time.Second

    productJSON, _ := json.Marshal(product)

    h.redis.Set(ctx, productCacheKey(productID), productJSON, ttl)



    c.JSON(200, gin.H{"data": product, "from": "db"})

}

缓存优化的血泪史

说到缓存，我踩过的坑能说三天三夜。

第一个坑：缓存击穿。热门商品缓存过期的瞬间，几千个请求同时打到数据库，直接把库打挂了。解决方案是加互斥锁，缓存失效时只有一个请求去查库，其他请求等待。

第二个坑：缓存雪崩。如果大量缓存同一时间过期，那场面可想而知。解决方法就是上面代码里写的，过期时间加个随机值，分散开。

第三个坑：缓存穿透。用户查一个不存在的商品ID，缓存里没有，每次都查库。有人恶意搞你，传一堆不存在的ID，数据库直接GG。解决方案很简单，不存在的也缓存个空值，过期时间短一点就行。

数据库优化

数据库这块，我花的时间最多。原来的SQL写得那叫一个惨不忍睹，一个列表查询join了五张表，还没索引。

我做的第一件事就是加索引。别觉得加索引很简单，加错了反而更慢。比如性别这种区分度很低的字段，加了索引也没用，MySQL根本不会走。

然后是分库分表。订单表数据量太大，单表几千万条，查询越来越慢。我按用户ID哈希分了8张表，查询速度直接提升了一个数量级。不过分库分表的坑也很多，比如跨表查询、分页问题，这里就不展开了。

-- 给订单表加联合索引的例子

-- 踩坑：索引顺序很重要，区分度高的放前面

-- 原来的索引是 (status, created_at)，查询很慢

-- 改成 (user_id, created_at, status) 后，性能提升10倍+

ALTER TABLE order_main

ADD INDEX idx_user_created_status (user_id, created_at, status);

-- 分页查询优化

-- 深分页问题：limit 100000, 20 会扫描10万条记录

-- 优化方法：用子查询先定位到ID，再关联查询

SELECT * FROM order_main

WHERE id > (SELECT id FROM order_main WHERE user_id = ? ORDER BY id LIMIT 100000, 1)

AND user_id = ?

ORDER BY id

LIMIT 20;

前端性能优化

前端这块，我也做了不少工作。

首先是图片优化。跨境电商平台图片多，而且都是高清图，加载慢是常态。我做了几件事：用WebP格式（体积小30%左右）、CDN加速、懒加载、不同分辨率的图片适配不同屏幕。

然后是代码分割。原来打包出来的JS有2MB多，首屏加载能不慢吗？改成路由懒加载后，首屏JS体积降到了500KB以内。

还有就是骨架屏。别小看这个东西，用户感知上会觉得快很多。比起白屏等半天，有个骨架屏至少让用户知道页面在加载。

总结一下

优化做了一个多月，首屏加载时间从原来的12秒降到了1.5秒，API平均响应时间从800ms降到了120ms。老板挺满意，给我发了个红包，虽然不多吧，但至少认可了我的工作。

做性能优化这事儿，不能光靠感觉，得有数据支撑。我建议大家都上APM监控，比如SkyWalking或者Pinpoint，哪里慢一目了然。

对了，taocarts他们的跨境独立站系统性能做得也不错，我研究过他们的一些实现思路，确实有东西。人家能做到那么大的体量，技术上肯定是有两把刷子的。

今天就聊到这儿，改天再说说CDN和全球节点部署的事儿。

TAOCARTS 知识

科创50涨超6%芯片股领涨，聊聊跨境电商平台的技术选型与性能优化

数据库优化

-- 分页查询优化

前端性能优化

相关文章