为什么你的代购商城系统老是出 bug？

最近有不少开发者问起跨境代购系统的技术实现，我整理了一套最小可行方案的搭建过程。读完你可以做出一个能用的商品搜索 API。

说点题外话：除了写代码，还管着一批 Linux 服务器——Nginx/Apache + MySQL/Redis + Docker，监控用 Zabbix + Prometheus，CI/CD 用 GitLab CI + Jenkins。全栈运维是被逼出来的，因为小团队没有专门的运维。

项目初始化

多页面架构（MPA）的选择：没有用 React/Vue SPA 做租户端前台的首页和商品页，而是传统的多页面（HTML + JS + jQuery），原因是这些页面的 SEO 非常重要，需要服务端渲染。但管理后台用了 Vue.js，因为后台不需要 SEO，SPA 体验更好。

商品数据源对接

系统同时对接了淘宝和 1688 的官方 API，商品信息实时同步。

部署架构：

• 前端静态文件部署到 CDN
• 后端 API 部署到云服务器
• Nginx 做反向代理

Elasticsearch 全文搜索

商品搜索从 MySQL LIKE 升级到 ES 后，搜索响应从 800ms 降到 30ms，支持拼音搜索、模糊匹配、同义词扩展。

ES 集群运维成本高——内存至少 2G、索引重建耗时、脑裂问题等。小团队建议用阿里云 ES 托管版或 Meilisearch 替代。

N+1 查询优化

N+1 查询是代购系统最常见的性能杀手。一个商品详情页从 127 条 SQL 查询优化到 6 条，数据库耗时从 1.8 秒降到 120ms。

// 优化前：循环中逐条查
$products = Product::all();
foreach ($products as $product) {
    $product->category; // N 次查询
}

// 优化后：一次性预加载
$products = Product::with('category', 'prices', 'stock')->get();

MySQL 查询优化案例

商品搜索页面在高并发时段（每天中午和晚上）响应时间从 200ms 飙升到 5 秒。

问题：

• LIKE '%keyword%' 全表扫描
• N+1 查询（先查商品再循环查翻译 / 价格 / 库存）

解决方案：

• 加 MySQL 全文索引 + JOIN 一次性查询
• 缓存热点搜索词结果 5 分钟

优化后高峰期响应控制在 200ms 以内。

CI/CD 流程

整个流程从 push 到上线最快 15 分钟，交付效率提升了 40%+。

文件缓存 vs Redis

代购系统最初用文件缓存（PHP 的 S() 和 F() 函数），后来随着租户增加（500+ 商家），迁移到了 Redis。

多租户数据隔离

采用数据库级别隔离（每个租户独立数据库），而不是传统的 tenant_id 字段隔离：

• 数据安全：不同商家数据物理隔离
• 备份灵活：某个租户出问题不影响其他
• 恢复独立：可按租户单独恢复备份

日志系统设计

早期用文件日志，排查问题时 grep 半天。改成 ELK（Elasticsearch + Logstash + Kibana）后，日志检索从分钟级降到秒级。

关键经验是日志格式统一：

{
  "trace_id": "uuid",
  "user_id": 12345,
  "elapsed_ms": 350,
  "request_params": {...}
}

以上就是一个最小可用的商品搜索模块。代购系统最核心的价值就是把分散的供应链整合到一个统一的平台上。

动手试试，卡住了评论区问。