归档查询整形要服务页面而不是服务表结构

归档页看起来只是一个简单时间轴，但真把接口写出来就会发现，它和普通列表完全不是一回事。页面需要的是按年、按月、按数量聚合后的结构，而数据库天然存的是一篇篇文章明细。

我不太喜欢把原始查询结果直接丢给前端再二次整理，因为这样很容易把数据库结构细节泄露到页面逻辑里。更好的方式，是服务层明确产出归档页真正需要的数据：年份、月份、数量、代表文章，或者必要的跳转链接。

用 Sequelize 做这件事时，关键不是“能不能查出来”，而是结果是否适合消费：

• 页面是否还需要额外自己分组。
• 同一份归档数据是否能复用到 sitemap、侧边栏和时间轴。
• 后续改表时，页面层是否还能保持稳定。

归档查询一旦整形成清晰结构，页面和数据层之间的边界就会顺很多。这个收益通常比单次查询快一点更重要。

为什么这类问题总会在线上阶段突然变贵

围绕「归档查询整形要服务页面而不是服务表结构」这类判断，最容易被低估的地方，是大家前期总把它当成 ORM 写法偏好，而不是数据契约和查询边界。数据量小、调用方少的时候，字段命名、关联深度、分页方式、迁移顺序都像只是风格问题；一旦接口被更多页面复用，筛选、排序、统计和审计需求一起叠上来，之前没收住的边界就会同时在性能、排障和协作成本上爆出来。

落地时我会先卡住的检查项

• 先把输入 DTO、模型字段和最终 SQL 这三层对应关系看清，避免“接口语义已经变了，ORM 代码却还在偷偷兜底”。
• 把统计、明细、写操作和回滚路径拆开看，别让一个方便的查询顺手背上太多职责。
• 一旦这篇文章讨论的点已经影响到索引、事务或迁移顺序，就说明它不是微调，而是该补正式约束了。