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

https://segmentfault.com/a/

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

先把背景交代清楚。这个平台做的是反向海淘，核心用户群体是海外华人，业务高峰期的日活能到小几万。去年双11那阵子，系统一度快扛不住了，页面加载动辄十几秒，用户反馈非常激烈。压力一下子就上来了，随后由我来牵头推进性能优化，目标也定得很明确：把首屏加载时间压到2秒以内。

技术选型的那些坑

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

接手这个项目之后，前端调整为Vue3 + TypeScript，后端则采用Go + Gin。至于为什么选Go，原因其实很直接：跨境电商这类业务普遍是高并发、IO密集型场景，Go的协程模型天然就适配这类需求。再加上它部署起来足够省事，一个二进制文件放上去就能直接运行，不必像Ja va那样还要额外配置一大堆环境。

数据库用的是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和全球节点部署的事儿。