Nuxt 新文件结构带来的变化，表面上看只是从“项目根目录里放很多前端文件”变成了更明确的 app/ 组织方式。但它真正影响的，是团队如何理解边界：哪些是应用代码，哪些是服务端代码，哪些是配置和运行时约定。
如果只把它当成一次目录搬家，迁移通常很快又会退回混乱状态。
app 目录的价值在于边界更清楚
把页面、布局、组件和 composables 聚合到 app/ 下，最直接的收益不是“更时髦”，而是让应用层代码有了清晰边界。
app/
├── components/
├── composables/
├── layouts/
├── pages/
├── plugins/
└── app.vue
这样做对团队协作尤其有价值，因为它减少了“这个文件到底算应用层还是工程层”的歧义。
新结构不只是收纳方式，也在影响默认约定
目录变化背后通常伴随约定变化，例如：
- 自动导入扫描范围
- 页面和布局的组织逻辑
- 插件和中间件的归属判断
- 与 server 目录、public 目录的边界
因此迁移时要关注的不只是路径改动，还要确认工具链、自动导入和团队文档是否一起更新。
团队要先统一“放哪里”的原则，再迁目录
新结构如果没有配套放置原则，很快又会出现另一种混乱。建议团队至少先回答几个问题：
- 页面级专属组件放页面旁还是统一组件目录
- 业务 composable 和通用 composable 如何区分
- 仅服务某个模块的类型与常量放哪里
- app 内外哪些目录允许混用，哪些不允许
把这些原则定清楚以后，目录结构才会真正变成协作规则。
渐进迁移时优先迁“认知成本最高”的部分
并不是所有项目都适合一次性迁完整个结构。更稳的策略通常是先迁那些最容易导致认知混乱的部分：
- 页面和布局
- 插件与运行时逻辑
- 业务 composables
然后再处理类型、工具脚本和边缘目录。这比一次性全量搬迁更容易稳定。
export default defineNuxtConfig({
srcDir: 'app/',
})
一个常见失败案例：目录迁完了，协作成本却没降
原因通常不在 Nuxt 本身，而在于团队只做了文件搬迁，没有同步：
- 放置原则
- 代码评审标准
- 新目录说明文档
- 自动导入和路径约定
结果就是新目录存在了，但成员仍然按旧习惯随意放文件。
一份可直接复用的检查清单
- 是否理解了 app 目录带来的应用层边界价值
- 目录迁移是否同步更新了自动导入和工具链配置
- 团队是否先统一了文件放置原则和命名约定
- 是否优先迁移了认知成本最高的目录，而不是一次性全搬
- 文档和评审规则是否随新结构一起更新
总结
Nuxt 新文件结构与约定变化的重点，不在于目录本身，而在于它给团队带来的边界清晰度。只要先把 app 目录的职责、放置原则和渐进迁移顺序设计好，新结构就会真的降低协作成本，而不是制造另一层混乱。
进一步阅读：
