项目目录结构最佳实践：按技术栈给出业界主流的目录组织、分层与…

# Next.js 14 + Prisma 后台管理系统目录规划

核心结论：优先按「功能模块」划分

200个组件规模下，按功能域分模块比按页面划分更优。理由：

• 后台管理系统中，同一功能域的组件常被多个页面复用（如用户选择器在订单页、权限页都要用）
• 按页面分会导致跨页面复用时出现 ../.. 层级地狱
• 功能域与业务边界对齐，便于团队分工和维护

推荐目录树

```

src/

├── app/ # Next.js App Router 路由层（薄壳）

│ ├── (auth)/login/

│ ├── (dashboard)/

│ │ ├── users/page.tsx

│ │ ├── orders/page.tsx

│ │ └── settings/page.tsx

│ └── api/ # Route Handlers

├── features/ # ★ 核心层：按功能域划分

│ ├── users/

│ │ ├── components/ # 该域专属组件

│ │ ├── hooks/

│ │ ├── schemas/ # zod 校验

│ │ ├── services/ # 业务逻辑

│ │ └── types.ts

│ ├── orders/

│ └── settings/

├── components/ # 跨域通用组件（预计20-40个）

│ ├── ui/ # Button、Table、Modal 等基础件

│ └── layout/ # 侧边栏、顶栏

├── lib/

│ ├── prisma.ts # Prisma 单例客户端

│ └── utils.ts

├── hooks/ # 全局通用 hooks

├── prisma/ # schema.prisma、seed、migrations

├── server/ # 服务端专用逻辑（可选）

│ ├── services/

│ └── repositories/

└── types/

```

关键原则

• app 目录保持“薄”：page.tsx 只做组装和路由，业务逻辑下沉到 features
• 分层归属判断：组件只被一个功能用 → 放该 feature；被两个及以上用 → 提升到全局 components/
• server/client 隔离：Prisma 相关代码只在 server 环境使用，通过 server actions 或 API 层暴露给客户端，避免数据库客户端被打包进浏览器
• 组件命名：feature 内组件可加域前缀（如 UserTable），全局组件避免与 shadcn/ui 类基础件重名

200个组件的拆分预估

• 基础 UI 件：20-40 个
• 布局组件：5-10 个
• 其余按业务域分到 features 下，单个 feature 控制在 10-30 个组件为宜，超出说明该域应再拆子模块