给接单系统做技术选型时，我们为什么押注这套组合

写代码的和开网店的，关注的点经常对不上。卖家看功能，开发看架构。我们做 Taocarts（一个反向海淘代购与转运的接单系统）时，最纠结的不是功能清单，而是技术栈怎么选——毕竟接单系统一挂，客服群里全是催单消息，这个压力比一般管理软件大得多。

先把结论放在前面：前端 React，后端 Laravel 和 Express 并存，各管一摊。这个组合不新，但稳，而且团队招人容易。下面拆开讲为什么。

前端选 React，图的是生态和复用。 接单系统里有大量列表、表格、状态流转的界面，React 的组件化思路天然适合这种"一个页面十几个状态块"的场景。更现实的原因是招聘：React 开发者存量最大，项目交接时新人上手快。做技术选型别只看框架 benchmark，要看两年后你的团队能不能找到人维护。

后端选 Laravel，看中它把业务写"规矩"的能力。 代购业务里有一堆不能出错的东西：订单状态机、库存扣减、退款流程、多币种计价。Laravel 的 Eloquent 模型和迁移机制，逼着你把数据结构想清楚再动手。数据库结构稳定了，后面加功能才不会天天改表。一个例子：从支持淘宝、1688 货源扩展到唯品会、vvic、网商园五个平台的商品同步时，靠的就是当初把"商品"和"货源"拆成了独立模型，每个平台只写一个适配器。

Express 留着干轻活。 采购链路里有很多高并发的小任务：轮询物流轨迹、接收平台回调、给海外客户推订单进度。这些用 Node 写贴合，事件驱动天然省资源，和前端的 JS 技术栈还能共享工具库。重的业务逻辑进 Laravel，轻的实时任务进 Express，各干各的，互不拖累。

这套组合跑下来最大的体会是：技术选型没有最优解，只有"和业务匹配"这一条标准。 有同行劝我们上微服务，说实话流量根本到不了那个量级，两个单体服务加消息队列，稳定性反而更好。也有人推荐全栈 TypeScript，统一是统一了，但 Laravel 那些现成的队列、任务调度、权限组件，重写一遍纯属浪费生命。

给同样在搭自己系统的开发者三条建议：一是先把数据模型设计扎实，框架只是外壳；二是别追新，选团队招得到人的技术栈；三是给自己留监控和告警，接单系统的故障要在一分钟内被你先知道，而不是客户告诉你的。

Taocarts 目前日均处理订单从几十单涨到几百单，架构没动过大刀，靠的就是当初选得保守。稳，有时候是最快的路。

（文中技术细节来自我们自己的开发实践，供参考。）