web项目应用实训报告

上线第三天，项训报购物车页面崩了。用实不是项训报那种优雅的报错，是用实点进去直接白屏，控制台里一堆红色字体刷得比弹幕还快。项训报我盯着屏幕愣了两秒，用实脑子里只有一个念头——完了，项训报数据库连接池爆了。用实

这是项训报《web项目应用实训》这门课留给我的最深印象。我们小组做的用实是一个二手书交易平台，前端用了Vue，项训报后端是用实Spring Boot加MySQL，部署在阿里云最便宜的项训报那档ECS上。说实话，用实需求评审那会儿大家都挺乐观，项训报觉得功能不复杂，两周怎么也能搞定。真正动手才发现，光是用户登录态保持这件事，就折腾了整整四天。

问题出在JWT token的刷新机制上。前端每次请求都带token，后端校验过期时间，过期了就返回401让前端跳登录页。逻辑听起来没毛病，但实际用起来体验极差——用户填了一半的发布信息，切出去接了个电话，回来token过期了，页面一跳，数据全丢。我们后来改成双token方案，access token短过期，refresh token长过期，前端拦截401后自动用refresh token换新的access token，用户几乎无感知。这个改动让整个登录模块的代码量翻了一倍，但值。

数据库那边也踩了坑。商品表一开始没加索引，因为测试数据就几十条，查询快得很。后来模拟真实场景，往里面塞了五万条记录，搜索接口直接卡死，响应时间从20毫秒飙到3秒多。我打开慢查询日志一看，全表扫描。给title和category_id加了联合索引之后，降到80毫秒左右。这事让我意识到，开发环境和生产环境的差距，有时候不是代码逻辑的问题，是数据量的问题。

部署环节更是一地鸡毛。本地跑得好好的jar包，扔到服务器上启动就报错，说找不到某个配置文件。排查半天发现是打包时resources目录下的application-prod.yml没被包含进去，因为pom.xml里配了exclude。这种细节在IDE里根本不会暴露，只有真正部署才会撞上。后来我们养成了一个习惯——每次打包后解压jar包，确认配置文件都在里面。

接口联调那几天，前端和后端的矛盾集中爆发。前端说字段名对不上，后端说文档里写得很清楚。翻聊天记录才发现，文档更新了但没人通知。最后我们定了个规矩：任何接口变更必须在群里发消息，并且同步更新Swagger。这个流程听起来很基础，但真正执行起来，靠的是组员之间的默契和互相提醒。

项目最终演示那天，功能都跑通了，但我知道代码里还藏着不少临时方案。比如图片上传没做压缩，直接存原图，服务器带宽扛不住几个人同时上传。比如订单超时取消用的是定时任务轮询，而不是延迟队列，精度差了不少。这些在实训阶段可以接受，但放到真实产品里，每一个都是隐患。

这门课教会我的不是某个框架怎么用，而是怎么在有限资源和时间内做取舍。先让核心流程跑通，再考虑优化。先保证数据不丢，再追求响应速度。代码写得漂亮当然好，但能稳定运行的代码才有价值。购物车崩溃那次之后，我养成了上线前压测的习惯，哪怕只是用JMeter跑一百个并发，心里也有底得多。