Next.js 13是否必须使用Parallel Routes？其核心优势是什么？

先给你明确结论：你说的「在components文件夹编写组件，导入页面后用Suspense包裹实现多内容共存+流式加载」的方案完全可行，但Parallel Routes在路由控制、场景适配等方面有不可替代的优势，具体如下：

• 独立路由控制与状态隔离
  Parallel Routes的每个slot（比如@sidebar、@modal）对应独立的路由分支，每个slot里的页面有自己的路由状态、数据请求和生命周期。比如用户刷新页面时，每个slot的路由参数会被保留，自动恢复对应的内容；而用普通组件导入的方式，组件的状态和路由绑定在主页面上，没法单独控制某个内容块的路由跳转，也没法通过URL直接分享某个多内容共存的状态。

• 动态场景的灵活适配
  你可以用Parallel Routes轻松实现「侧边栏内容随主内容动态切换」「模态框页面复用现有布局」这类场景。比如电商项目里，主页面展示商品列表（/products），@quickview slot展示商品详情模态页，用户可以直接通过/products/@quickview/123访问这个状态，而且模态页能复用主布局的导航栏、全局样式；如果用普通组件，你得手动维护模态框的显示状态和数据，没法直接用URL分享这个模态页打开的状态。

• 路由级的加载与错误处理
  Parallel Routes默认支持给每个slot单独配置loading.tsx和error.tsx，不需要在主页面里逐个给组件套Suspense。比如@dashboard slot加载慢时，会自动显示它对应的loading组件，完全不影响其他slot的渲染；而普通组件的方式，你得手动给每个组件加Suspense，错误处理也要单独写，代码会越来越冗余。

• 更清晰的代码组织
  用Parallel Routes时，每个slot的页面代码都放在对应的路由文件夹下，比如app/products/@quickview/[id]/page.tsx，和主页面代码完全分离，职责划分清楚，多人协作时不容易冲突；而普通组件导入的方式，所有组件都堆在components文件夹，主页面还要处理一堆组件的导入和状态管理，内容块越多，代码越乱。

• 路由优先的内容切换
  在Parallel Routes里，你可以用next/navigation的push方法直接切换某个slot的内容，比如push('/products/@quickview/456')只会更新@quickview slot的内容，主页面的状态不受影响；而普通组件的方式，你得用状态管理（比如useState、Context）来触发组件内容切换，逻辑链路更长。

内容的提问来源于stack exchange，提问作者Lee SeongBae