1个后端新手3天踩了7个坑：分页和鉴权到底怎么搞

1471行代码，3个功能，0次崩溃——这是后端新人Day 3的真实战绩。但数字背后藏着更细的东西：分页怎么切才不会漏数据？JWT放Header还是Cookie？这些"小决策"在真实业务里全是雷。

原作者的日更记录像一份带血的踩坑笔记。每天1%的改进口号听着轻松，落地时全是选择题。

分页：从"一把梭"到"切香肠"

最开始的API直接返回全表数据。本地测试时百来条记录跑得飞快，作者没觉得有问题。

直到他意识到生产环境可能存着几万条任务记录。前端一次性渲染会卡死，后端内存也可能爆掉。

分页的本质不是技术炫技，是给前后端都设一道流量闸门。

他改成了按页获取。但这里有个隐形坑：如果排序字段不唯一，翻页时可能出现重复或遗漏。原文没提他用什么排序，估计是默认ID——这在小项目里够用，业务复杂后得加联合索引。

另一个细节是页码从0还是从1开始。Spring Data JPA默认0起算，但前端同事可能习惯1起算。这种"约定冲突"在联调时才会爆炸。

校验：让API学会说"不"

之前的接口来者不拒。缺少标题？可以。描述为空？也行。数据库里攒了一堆脏数据，后期清洗成本比前期校验高十倍。

作者加了请求校验。必填字段缺失时直接打回，错误信息返回给前端。

这里有个产品思维：校验规则该多严格？太松数据烂掉，太严用户体验差。他选择了"硬阻断"模式——必填项缺一不可。这对内部工具型API是合理选择，To C场景可能得给默认值或草稿态。

原文没写用的什么校验框架。Spring Boot生态里Hibernate Validator最常用，注解式开发省不少样板代码。

JWT：把" session 存服务器"扔进历史垃圾桶

Day 3最重的改动是接入Spring Security + JWT。

传统session模式里，用户登录后服务器存一份会话状态，每次请求带着cookie来查库。用户量上千时内存吃紧，多实例部署还得搞共享session，架构瞬间复杂。

JWT的思路很粗暴：服务器不存状态，把用户信息加密成token扔给客户端，每次请求带回来验签就行。

作者实现了这套流程：登录接口发token，后续请求带Authorization头部，服务端验通过放行，验不过踢掉。

但他没提几个关键细节：token有效期设多长？刷新机制怎么做？被盗用了怎么吊销？这些在真实生产环境全是必答题。日更记录停在"能跑通"，但距离"能上线"还有段距离。

另一个观察：他把认证路由和任务路由做了区分。登录注册公开，增删改查要鉴权。这是最基础的RBAC（基于角色的访问控制）雏形，但原文没提角色划分——估计目前只有"登录/未登录"两种状态。

3天积累 vs 真实业务的距离

作者的进度条很清晰：Day 1搭架子，Day 2写CRUD，Day 3加安全和性能。每个功能都是"从能用到够用"的跨越。

但后端开发的残酷在于，功能实现只是20%，剩下80%是边界情况。分页时数据库并发写入怎么办？JWT密钥怎么轮换？高并发下验签性能瓶颈在哪？

这些他没遇到，所以没写。但读者里若有正在接生产系统的，应该能自动补全这份清单。

有个细节值得玩味：他在文末提到"Templates let you quickly answer FAQs"，这句话突兀地混在技术总结里。查了下是某协作工具的模板功能说明，疑似复制粘贴时的残留。日更的压力下，这种"小穿帮"反而让记录更真实。

作者说每天改进1%。按这个节奏，第10天该上缓存，第30天该压测，第100天该考虑分库分表。但大多数自学者的曲线是：前两周陡峭上升，第三周碰到分布式事务或性能调优，然后卡在平台期。

他会走哪条路？取决于Day 4到Day 7能不能保持这个更新频率，以及——更重要的是——有没有一个真实项目把他逼到必须解决某个具体问题的墙角。

你现在回头看自己第一个"能跑通"的后端项目，最庆幸当时做了哪个小决策，最后悔漏了哪块？