web项目开发案例

去年帮朋友改造一个后台管理系统，目开前端用React，发案后端是目开Spring Boot。上线第三天，发案运营在群里甩了张截图：订单列表页加载了整整12秒，目开白屏期间用户点了三次刷新，发案结果重复提交了五笔退款申请。目开问题不在代码逻辑，发案而在数据接口——那个接口一次性返回了全量订单，目开没分页，发案没索引，目开连字段都没裁剪。发案

这就是目开典型的Web项目开发陷阱：功能跑通了，性能却塌了。发案很多人以为前后端联调成功就算完事，目开其实真正的坑从用户第一次点击才开始。

接口设计决定了一半的成败

我见过太多项目把RESTful API当成万能膏药。一个/api/getData走天下，GET请求里塞满业务动作，参数用下划线拼成user_id_and_order_status这种怪物。更离谱的是返回结构，有人喜欢包三层：{ code:200, data:{ list:[...], total:100}, msg:"ok"}，前端每次取值都得写res.data.data.list。何必呢？

我的习惯是：列表接口强制分页，默认每页20条，游标分页优先于页码分页。字段按需返回，用fields=id,name,status这种查询参数控制。错误码别自己发明，HTTP状态码够用了——404就是找不到，401就是没登录，别搞什么code:10001让前端猜谜。

状态管理不是越多越好

有个电商项目，前端用了Redux、MobX、还有两个Context，加上组件内部的useState，同一个购物车数量在四个地方存着。改一个数量要同步四个源，漏一个就出bug。后来重构，只留Redux管全局的登录态和购物车，其余全部下沉到组件局部状态。代码少了三分之一，bug率降了一半。

判断标准很简单：这个状态是否被三个以上不相关的组件消费？是，才放全局。否则就近管理。别为了“架构整洁”把简单事情搞复杂。

数据库查询是性能黑洞

那个12秒的订单接口，我后来用EXPLAIN看了下，全表扫描加N+1查询。订单表50万行，每行还要去查用户表和商品表。改成JOIN加覆盖索引后，降到80毫秒。再让前端做虚拟滚动，首屏只渲染可见的15条，用户感知就是“秒开”。

经验是：任何列表接口上线前，拿生产数据量级的测试库跑一遍。别用几百条测试数据自欺欺人。慢查询日志开着，超过200ms的SQL全部拉出来审。

部署不是终点

很多人把代码推上服务器就完事。我习惯加三层保险：Nginx层做限流和静态缓存，应用层加健康检查和优雅重启，数据库层配只读从库。还有，日志别只打console.log，结构化日志加请求追踪ID，出问题时能顺着一个ID把整条链路串起来。

Web项目开发没有银弹。那些看起来“能用”的系统，往往在用户量涨十倍后变成灾难。提前想一步，比事后救火便宜得多。