当前位置：首页 > 文章列表 > 文章 > 前端 > 科创50涨超6%芯片股领涨，聊聊跨境电商平台的技术选型与性能优化

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

2026-08-20 17:41:32 0浏览收藏

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;