早上刚醒手机震个不停——‘我的货到哪了’。以前大刘每天要花两小时回这类消息。同样一个代购系统有人用 Laravel 做有人用 Go 写有人直接买 SaaS。到底怎么选聊聊我从自研到最终选型的完整决策过程。需求分析图片优化从 5MB 到 200KB 的方案WebP 格式体积比 JPEG 小 30-50% 多尺寸缩略图列表 200px、详情 800px CDN 分发 懒加载Intersection Observer。优化后首屏图片加载从 4.5 秒降到 1.2 秒。方案对比顺便提一下先看看有哪些选项。市面上大概有三种方案自己从头开发、用开源系统二开、直接用现成的 SaaS 系统比如 代购系统。每种方案的适用场景和隐性成本差别很大。系统架构整体架构上采用前后端分离。PHP 自研框架提供 RESTful APIVue.js 构建前端界面通过 HMAC 签名进行身份认证。文件缓存做热数据缓存MySQL 做持久化存储。方案局限当然这个方案也有局限。单机部署决定了扩展性有限如果未来租户数翻倍可能需要做服务拆分。另外文件缓存在高并发场景下不如 Redis 稳定这也是后续要改进的。技术选型没有银弹但有原则——先理清业务约束再评估团队能力选一个最匹配的。不要为了技术而技术。写这篇文章是因为之前踩坑的时候全网搜不到完整的资料希望能帮到遇到同样问题的人。完整 GitHub感兴趣可以去看。如果你在类似场景下用了不同的方案或者对某个细节有更好的思路欢迎在评论区聊聊——做技术的都知道没有银弹多交流才能少踩坑。1688 API 限流的处理限流策略是每 AppKey 每秒 20 次调用。解决方案是消息队列RabbitMQ 令牌桶算法控制消费速率。踩过一个坑消息积压 3000 条导致 RabbitMQ 内存溢出——因为 1688 临时维护 2 小时所有请求失败后不断重试。加了消息 TTL5 分钟 死信队列 最大重试 3 次后解决。还有一点文件缓存 vs Redis 的选择代购系统最初用文件缓存PHP 的 S() 和 F() 函数因为单机部署、数据量不大。后来随着租户增加500商家文件缓存 inode 消耗过大超过 100 万个缓存文件迁移到了 Redis。迁移策略是双写同时写文件缓存和 Redis观察一周确认 Redis 无异常后才下线文件缓存。多年电商后端开发目前在维护 taocarts 代购系统1688 代购 / 跨境支付 / 多仓库协同。技术问题欢迎交流。