React/NextJS项目Features目录结构：页面文件是否存在冗余？

这种做法完全合理，甚至是大型Next.js项目采用特性驱动架构的标准实践，原因如下：

• 适配Next.js路由机制：Next.js依赖pages目录生成路由映射，这是框架的核心约定。在pages下保留仅做导入渲染的入口文件，既能遵守框架规则，又能让路由结构一目了然——扫一眼pages就能快速梳理出项目的所有路由节点。

• 实现严格的关注点分离：features/registration可以完整封装注册功能的所有相关代码（组件、状态逻辑、API调用、验证规则、样式等），形成独立的功能模块。pages/register.tsx只承担路由入口的单一职责，不混杂任何业务逻辑，代码边界更清晰。

• 提升功能复用性：封装成独立组件的注册功能，除了作为路由页面使用，还能轻松复用到其他场景（比如后台系统的用户注册弹窗、嵌入其他页面的注册模块），避免重复造轮子。

• 优化团队协作效率：大型项目中不同开发者负责不同功能模块，把注册相关代码集中在features/registration里，开发者不用在pages和零散子目录间来回跳转，定位、修改代码更高效，也能降低误改其他功能代码的风险。

给你一个具体的目录结构示例：

├── features/
│   └── registration/
│       ├── components/
│       │   ├── RegistrationForm.tsx
│       │   └── RegistrationSuccess.tsx
│       ├── hooks/
│       │   └── useRegistration.ts
│       ├── services/
│       │   └── registerUser.ts
│       ├── Registration.tsx  # 整合所有子模块的主组件
│       └── registration.module.css
└── pages/
    └── register.tsx

pages/register.tsx的内容会非常简洁：

import Registration from '@/features/registration/Registration';

export default function RegisterPage() {
  return <Registration />;
}

看似冗余的几行代码，其实是框架约定与架构合理性之间的最优平衡——既满足Next.js的路由要求，又能让项目架构随着规模增长保持清晰、易于维护，这种结构的优势在大型项目中会愈发明显。

内容的提问来源于stack exchange，提问作者Alex Sorensen