##摘要 本文详细阐述了小程序开发中"内容阅读"阶段的核心目标与实现要点。文章指出，内容阅读阶段的关键不是功能堆砌，而是构建完整的阅读体验链路，包括首页推荐、发现页导航、文章列表和详情页的流畅衔接。通过分析当前代码实现，文章展示了如何将用户从首页自然引导至搜索、分类和详情页，并强调了详情页作为阅读体验核心的重要性。最后，文章提供了开发提示词和效果图预留建议，帮助开发者避免常见误区，确保阅读主链路扎实落地。

基础框架立住之后，小程序第一次真正面向用户的阶段就是“内容阅读”。
这一步不是继续铺更多入口，而是把首页、发现、文章列表、文章详情、分类、标签和热门这些核心阅读路径接起来，让用户一进来就能看到内容、点进内容、读完内容。

对内容型产品来说，这一阶段其实比“功能很多”更重要。因为用户第一次打开小程序，不会关心你后面有没有树洞、消息中心、作者关注，他最先感知的是：首页有没有内容感，详情页好不好读，点进去之后会不会马上退出。

这个阶段到底要解决什么

产品文档里把“内容阅读”定义为：

• 首页推荐、最新内容、分类入口
• 发现页热门 / 分类 / 标签
• 文章列表和文章详情

当前仓库里已经能看到这条链路基本成型：

• 首页 pages/home/home.vue
• 发现页 pages/discover/discover.vue
• 文章列表 pages-article/list/list.vue
• 文章详情 pages-article/detail/detail.vue

这说明内容阅读已经不是“准备做”，而是正在按真实页面链路落地。

首页、发现和详情是怎么串起来的

首页已经不是普通占位页，而是有推荐流、分类快捷入口、精选卡片和 Liquid TabBar。比如首页里已经有很明确的入口动作：

function goSearch(): void {
  uni.navigateTo({ url: '/pages-article/search/search' });
}

function goDetail(id?: number): void {
  if (!id) return;
  uni.navigateTo({ url: `/pages-article/detail/detail?id=${id}` });
}

function goCategory(id?: number): void {
  if (!id) return;
  uni.navigateTo({ url: `/pages-article/list/list?categoryId=${id}` });
}

这段代码很简单，但它说明首页不只是“展示内容”，而是在把用户自然引到搜索、分类和详情。

发现页也不是静态入口宫格，而是已经接了热门文章和分类列表：

const [hot, categoryList] = await Promise.all([
  fetchHotArticles(1, 5),
  fetchCategoryList()
]);

这类实现特别适合写实战文，因为它能直接说明：
不是先设计一张发现页图，而是先把“用户还能继续找什么”这层数据入口接上了。

为了更清晰地展示用户在小程序中的阅读路径，以下是"内容阅读"阶段的流程图：

上图展示了用户从进入小程序到完成阅读的核心路径。首页作为起点，通过推荐流、分类入口和搜索功能将用户引导至具体内容；发现页则提供了热门文章和分类浏览的补充入口；最终所有路径都汇聚到文章详情页，完成阅读体验。这种设计确保了用户能够顺畅地在不同页面间跳转，形成完整的阅读闭环。

详情页为什么是阅读阶段的核心

这一阶段真正难的，不是把页面文件建出来，而是让这些页面在阅读体验上互相承接。首页要承担“第一眼看到什么”，发现页要承担“还有什么能继续找”，详情页要承担“读完之后值不值得留”。如果首页只是普通列表、发现页只是按钮宫格、详情页只是把 HTML 原样塞进去，阅读链路虽然表面存在，实际不会形成留存。

当前详情页已经具备比较完整的阅读主体结构：

<view class="detail__header s-card">
  <view class="detail__category">{{ article.categoryName || '文章' }}</view>
  <view class="detail__title">{{ article.title }}</view>
  <view class="detail__meta">
    <text>{{ article.author || article.user?.nickname || 'Sourcelin' }}</text>
    <text>{{ formatDate(article.createTime) }}</text>
    <text>{{ article.viewCount || 0 }} 阅读</text>
  </view>
</view>

<view class="detail__body s-card">
  <rich-text v-if="article.content" :nodes="article.content" />
</view>

这段结构说明阅读页已经不再是“先能显示出来”，而是在按文章阅读场景组织信息：分类、标题、作者、时间、阅读量、正文，这几个层次都已经有了。

为什么我认为这个阶段已经可以算完成

从当前代码看，内容阅读这一阶段可以确认完成，原因也比较直接：关键页面已经不再是骨架，而且读内容所需的主要路径都在。首页能跳搜索和分类，发现页能跳热门和分类，详情页能展示正文和评论入口，这已经不是“准备开发”，而是阅读主链路已经落地。至于更细的体验优化，比如富文本适配得有多好、长文滚动是否足够顺滑，可以继续打磨，但不影响这个大阶段已经完成。

这也是我觉得“阶段完成”要和“细节还可优化”分开看的原因。
一个阶段能确认完成，不代表它没有后续优化空间，而是说明主链路已经成立了。

效果图

开发过程提示词（优化版）

请先读取 AGENTS.md、rules/frontend-uniapp.md、rules/api-contract.md，
以及产品文档第 5.1 节“内容阅读”阶段目标。

本次只处理内容阅读，不扩展到搜索、登录、收藏、树洞或消息中心。

请优先推进：
1. 首页推荐和分类入口
2. 发现页热门、分类、标签
3. 文章列表
4. 文章详情正文与阅读体验

输出时必须说明：
1. 阅读主链路是否已经打通
2. 各页面依赖了哪些接口
3. 详情页正文、图片、评论入口如何处理
4. 还缺哪些阅读体验优化项

这类任务里 AI 最容易跑偏的点

• 把内容阅读理解成“多建几个页面”
• 首页、发现、详情各做各的，没有串成一条阅读链路
• 详情页先塞互动逻辑，反而把正文阅读体验放后面
• 还没把阅读主链路打通，就先扩消息、树洞、发布等后续阶段

把内容阅读阶段先做扎实，比急着扩更多功能更重要。因为用户只有先愿意看、看得下去，后面的搜索、点赞、收藏和回访才有意义。

项目地址

• 在线演示：https://sourcelin.cn
• Gitee：https://gitee.com/my_lyq/sourcelin-cloud-blog
• GitHub：https://github.com/SourceLin/sourcelin-cloud-blog