用 App Router 设计博客、项目、笔记三层结构
把内容模型变成真实目录、路由与布局分层，让站点结构从一开始就适合扩展。
Tutorial Path
从 0 搭建一个可持续写作的 Next.js 个人网站
当前位置：04 / 10
把抽象的内容模型落成真实的路由和目录。
上一篇我们已经确定了站点要同时承载 blog、projects 和 notes。接下来要做的不是立刻开发所有页面，而是先把目录边界定好。因为目录边界会直接影响你后面写页面的方式、拆组件的方式，以及内容读取层的设计。
我会先画一张最小可用的路由图
对于这个项目，我会先确定最核心的一圈路由：
/首页/blog与/blog/[slug]/projects与/projects/[slug]/notes与/notes/[slug]/categories与/categories/[slug]
这张图有两个特点。第一，所有内容类型都必须有“列表页 + 详情页”的闭环；第二，所有与公开内容相关的页面都归到同一套主站布局下。
Route Groups 的价值不在“炫技”，而在“提前分区”
我会用 (main) 把主站页面收进去，不是因为它更高级，而是因为它能明确告诉未来的自己：这些页面共享同一套导航、页脚和视觉语言。以后如果真的要做游戏频道、实验频道或者后台区域，就可以放进别的 route group，而不会把主站结构搅乱。
这种提前分区的好处，在项目小的时候不明显；但当页面开始变多、布局开始分化时，它会让你的修改范围非常清晰。
为什么列表页和详情页必须成对考虑
很多人会先写详情页，再回头补列表页。短期看没问题，但一旦涉及 SEO、分页、分类聚合、上一篇下一篇、站内搜索，就会发现详情页其实依赖着整个内容集合的组织方式。
所以我更喜欢成对地设计：有列表页，就同时考虑它怎么进入详情页；有详情页，就同时考虑它如何回到列表、如何被分类页和搜索页发现。
这一层不应该承载太多业务逻辑
App Router 的页面文件，最好只做三件事：拿参数、调内容读取函数、拼页面结构。不要把 frontmatter 解析、分类规范化、标签去重这些逻辑散落到页面里。那些逻辑应该统一沉到 src/lib/content 这种更稳定的边界层。
这样做最大的好处是：页面层始终薄，后续你换内容源、补缓存、加测试，都有明确入口。
配套笔记：App Router 路由地图速记如果你想快速回看这一套路由结构，可以把这篇笔记当作目录卡片使用。小结
一个适合长期维护的 App Router 结构，不是文件夹堆得多漂亮，而是内容类型、布局边界和读取职责都足够清楚。下一篇我们继续把结构再往里推进：给这三类内容建立一套真正可持续写作的 MDX 内容系统。