成为全栈·Next.js 网站前台篇·内容门户首页焦点、最新、文章流与侧栏如何组织首页不是把所有功能都摆一遍。它要在有限的首屏里回答三个问题这是什么站现在有什么值得读读者接下来可以去哪里。前言我第一次审视旧前台时它已经有文章、分类、热门和标签。单独看每个模块似乎都没有大问题把它们放在一起首页却像一张功能清单。焦点、排行、分类、最新文章都在争抢同一层注意力读者不知道应该先看哪里。这次我们没有把首页做成巨大的产品宣传页也没有盲目追求“信息越少越高级”。它仍然是一个传统内容门户只是重新安排了阅读顺序焦点内容负责建立印象最新发布负责提供时效文章流负责持续发现侧栏负责辅助导航。先定义首页的主任务内容站首页可以有很多指标点击率、滚动深度、登录转化、专栏订阅。但如果把它们都当为第一优先级首页就会被按钮和卡片淹没。本项目给首页定了一条更克制的主链路识别站点 → 看到焦点 → 了解最新 → 浏览文章流 ↘ 通过分类、热门、标签继续导航因此页面从上到下是焦点区与最新文章、系列横幅、文章流与侧栏最后是可达的 Footer。登录入口和会员中心留在页头不在首屏再造一个巨大召唤区。焦点位不应该编造内容焦点区支持在config/home.ts里显式配置文章 id。但新站刚运行时这份列表很可能是空的。一个很容易的做法是在前端写几篇假文章让轮播看起来丰满。页面好看了用户点进去却没有真实内容这是设计稿思维侵入产品的典型例子。当前实现先尝试加载配置的焦点文章无效 id 单独降级若没有可用配置就从最新文章中优先选有封面的真实内容。连文章都没有时它才回到站点介绍const focus picks.length ? picks.slice(0, 5) : [...page.list.filter((a) a.coverImage), ...page.list.filter((a) !a.coverImage)].slice(0, 3)这里的取舍是焦点编辑能力还没有做成后端配置项所以它只是一份可版本化的前端配置。文章不会因为被写进配置就成为假数据但运营人员也无法不发版就调整它。如果日后焦点更换变得频繁应该在契约中增加正式的运营位而不是让前端配置无限膨胀。焦点轮播为什么不自动播放轮播在首页上很常见自动切换也看似更“有动感”。但对文章标题和摘要来说自动切换会打断阅读键盘、读屏和减少动效用户也需要更多处理。所以Focus只保留手动上一篇、下一篇和指示点按钮有完整aria-label当前项用aria-pressed表示另用示例文本通知“第几张共几张”。这个选择牺牲了一点动画表演换来用户对阅读节奏的控制。“最新”和“热门”要说真话首页右侧的最新区按-publishedAt排序突出日期与标题。侧栏热门则按-viewCount排序并明确写“累计阅读”。“近 7 天热门”看起来更有时效感但当前 API 只提供累计阅读量没有阅读事件时间序列。如果前端自己改一个标题就是用文案伪造后端没有的能力。因此我们宁可让标题稍微朴素也不发明一个时间窗口。侧栏各模块也分别失败热门请求失败时显示“暂时无法加载”标签为空就不渲染标签块某个编辑精选 id 失效只忽略该项。辅助内容的失败不应拖垮首页主文章流。持续加载要给 Footer 留一条路文章流首批 10 篇由服务端输出浏览器的Feed从这份初始数据继续加载。IntersectionObserver让读者滚到底部前自动获取下一批。如果一直自动加载Footer 会不断被推走关于网站、分类索引和版权信息变得很难到达。当前实现最多自动加载后两批之后保留明确的“加载更多文章”按钮。读者也可以随时进入正常分页的全部文章页。if(!sentinel.current||!hasNextPage||isFetchingNextPage||query.isError||count3)return这是一个很小的限制却体现了一个产品判断滚动连续性不能以牺牲页面结构和用户控制为代价。首页绝不能只验“有数据”首页聚合应该并发但不能让辅助区绑架主内容export default async function HomePage() { const [page, categories, configuredFocus] await Promise.all([ listArticles({ page: 1, pageSize: 10, sort: -publishedAt }), getCategoryTree(), getConfiguredFocus().catch(() []), ]) const focus selectFocus(configuredFocus, page.list) return ( HomeLead focus{focus} latest{page.list.slice(0, 5)} / SeriesBanner / div classNamehome-grid Feed initial{page} categories{categories} / Sidebar / /div / ) }首页主列表失败时页面没有可靠内容应进入错误边界焦点配置失败则可以从真实最新文章降级。catch(() [])只出现在允许缺席的辅助数据上不能成为所有请求的统一模板。侧栏内部也采用独立失败策略const [popular, tags, picks] await Promise.all([ listArticles({ pageSize: 5, sort: -viewCount }).catch(() null), listTags().catch(() []), loadEditorPicks().catch(() []), ]) return ( aside {popular ? Popular items{popular.list} / : ModuleFailure title热门文章 /} {tags.length 0 TagCloud tags{tags} /} {picks.length 0 EditorPicks items{picks} /} /aside )焦点区的控制状态应足够小use client const [index, setIndex] useState(0) const current articles[index] const previous () setIndex((value) (value - 1 articles.length) % articles.length) const next () setIndex((value) (value 1) % articles.length)轮播没有计时器也就不需要处理鼠标悬停、页面隐藏和减少动态效果等一串自动播放状态。用户点一次状态才变化一次。每个区块都要有可核对的职责区块回答的问题数据来源失败时怎么做焦点本站最值得先读什么配置文章缺失时回退真实最新文章显示站点介绍最新刚刚发布了什么-publishedAt与主列表一起进入错误边界文章流还有什么可以继续发现服务端首屏 客户端续页保留已加载内容并重试热门累计阅读较多的内容是什么-viewCount局部失败提示标签可以从哪些主题横向探索标签及文章数空时隐藏模块可复现的首页验收矩阵constcases[有焦点配置 / 配置为空 / 配置含失效 id,文章有封面 / 无封面 / 全站无文章,热门失败 / 标签为空 / 主列表失败,键盘切换焦点 / 自动加载两批 / Footer 可达,]这段不是自动化测试本身而是一份固定验收输入。每次调整首页布局或请求策略都应按相同案例复查避免只拿内容最完整的数据库截图作为“完成证明”。我们对首页至少核对了这些状态有配置焦点、无配置焦点、全站无文章。有封面与无封面文章混排。文章流首屏、追加、分类切换、失败重试与全部加载完成。侧栏单个接口失败时主区仍可阅读。自动加载停止后 Footer 仍可达。焦点按钮、分类页签能使用键盘操作。首页“看起来正常”往往只代表测试数据恰好完整。真正的稳定性来自每个内容区都知道数据缺失、请求失败和内容到底时应该怎样表达。适用边界这种信息结构适合文章、新闻、教程和多栏目内容站。如果站点只有一个明确转化目标例如售卖一款 SaaS焦点、最新、排行和标签同时出现反而会分散行动。如果编辑运营频率很高前端文件配置的焦点位也不够。那时需要正式的推荐位模型、生效时间、下线时间和预览流程这些都不应该藏在首页组件里。小结这个首页的核心改变不是多了一个轮播而是每块内容有了明确职责焦点建立印象最新提供时效文章流支持发现侧栏辅助导航。真实数据不够时它会诚实降级内容很多时它也不会用无限加载吞掉 Footer。各位看官下次做首页可以先暂停画卡片给每个区块写一句“它帮读者做什么”。如果三个模块的答案完全相同页面大概不需要它们全部存在。延伸阅读数据获取与缓存多级分类、标签与 URL文章列表服务端首屏与客户端持续加载如果这篇文章对你有帮助欢迎订阅我的 CSDN 专栏「成为全栈」 专栏地址https://blog.csdn.net/fungleo/category_13204651.html 本系列配套代码仓库https://github.com/fengcms/become-a-full-stack-developer
