Skip to content

Next.js 项目专题

如何设计一个 Next.js 中后台项目的目录和模块边界?

这道题考察的不只是 API 记忆,而是能否解释机制、边界、工程取舍和线上风险。

适合阶段:高级前端 / 资深前端 / 架构面核心能力:架构设计 · 工程落地 · 稳定性 · 协作

面试官想考什么

  • 你能否先给出明确结论? 考察是否理解题目的核心问题,而不是只罗列术语。
  • 你能否解释内部机制和关键链路? 考察能否把框架行为落到运行时、网络、浏览器或构建过程。
  • 你能否说明适用边界和代价? 考察技术选型、风险识别和长期维护意识。
  • 你能否讲清生产落地? 考察测试、监控、降级、回滚和问题定位能力。

一句话回答

text
按领域组织业务代码,框架路由层只负责页面组装;共享层区分 UI、领域逻辑、服务端访问和基础设施。

面试回答详解

这道题的重点不是背诵一个孤立结论,而是把概念、机制、边界和工程实践串起来。面试现场可以先给出上面的核心回答,再按以下层次展开。

1. 先明确问题边界

按领域组织业务代码,框架路由层只负责页面组装;共享层区分 UI、领域逻辑、服务端访问和基础设施。

需要先区分它解决的具体问题,以及它不负责解决的部分。高级回答要避免把语法、运行时机制、框架约定和业务架构混成一个概念。

2. 解释核心机制

app 管路由与布局;features 管业务用例;components 管跨领域 UI;server 管服务端访问;lib 管基础设施和配置。

text
输入或用户操作 -> 框架/运行时处理 -> 状态、数据或资源更新 -> 可观察结果

如果题目涉及 React,要说明渲染、更新、提交、状态或组件边界;如果题目涉及 Next.js,要说明服务端、客户端、边缘运行时、路由、数据获取和缓存边界;如果题目涉及性能,要把用户指标和具体链路对应起来。

3. 讲清边界和相近概念

  • 概念边界:说明它和相邻 API、渲染模式、缓存层或架构方案的区别。
  • 状态与数据:区分局部 UI 状态、服务端数据、缓存数据和持久化数据。
  • 运行位置:明确代码是在浏览器、Node.js、Edge 还是构建阶段执行。
  • 失败模式:列出竞态、过期数据、重复执行、hydration mismatch、权限绕过或性能退化等风险。

4. 讲工程取舍

禁止客户端模块直接导入服务端密钥或数据库代码;通过 lint、依赖规则和 code review 固化边界。

  • 适合场景:边界清晰、收益可测量、团队已有对应基础设施的场景。
  • 不适合场景:数据规模、实时性、安全约束或运行时环境不满足时,不要强行使用。
  • 评估维度:复杂度、性能、可测试性、可观测性、兼容性和迁移成本。
  • 验证方式:用类型检查、单元测试、E2E、Profiler、Network、RUM 或服务端 trace 证明判断。

5. 生产落地与风险控制

如何避免 utils 变成垃圾桶?如何拆分 monorepo 与共享组件包?

落地时至少要补齐输入校验、错误态、空态、超时、取消、重试、降级和回滚。涉及用户数据时,还要检查鉴权、授权、租户隔离、敏感信息脱敏和缓存隔离。涉及性能时,要同时看实验室数据和真实用户分位数,避免只优化一个孤立指标。

可直接背诵的 30 秒回答

text
这道题的核心是按领域组织业务代码,框架路由层只负责页面组装;共享层区分 UI、领域逻辑、服务端访问和基础设施。实现上我会先确认它在整条链路中的位置,再解释`app` 管路由与布局;`features` 管业务用例;`components` 管跨领域 UI;`server` 管服务端访问;`lib` 管基础设施和配置。选型时不会只看“能不能实现”,还会结合数据规模、性能、可测试性、运行时和团队维护成本判断边界。生产环境要补上如何避免 `utils` 变成垃圾桶?如何拆分 monorepo 与共享组件包?,并通过测试、监控和指标验证方案确实有效。

扩展知识

面试回答框架

text
定义问题 -> 运行机制 -> 概念边界 -> 工程取舍 -> 风险控制 -> 指标验证

常见答题误区

  • 只背 API 名称,不说它解决的真实问题。
  • 只讲优点,不讲缓存、性能、安全、兼容性或维护成本。
  • 把服务端、客户端、构建时和边缘运行时的行为混为一谈。
  • 说“可以优化”,但没有说明基线、工具、指标和回滚方案。

面试官追问链

追问一:如果线上出现异常,你会怎么排查?

  • 考察点:是否具备从现象定位到根因的能力。
  • 回答方向:先记录版本、路由、用户上下文和复现条件,再根据题目检查控制台、Network、React Profiler、Performance、服务端日志、trace 和监控,逐层缩小到输入、状态、渲染、缓存、网络或部署。

追问二:这个方案有什么缺点,什么时候不用?

  • 考察点:是否理解方案边界而不是绝对化背答案。
  • 回答方向:从复杂度、性能、可测试性、兼容性、安全、团队理解成本和迁移成本说明;如果约束不满足,选择更简单或更靠近数据源的方案。

追问三:如果数据量、访问量或团队规模继续增长,你会如何调整?

  • 考察点:是否能从 demo 方案升级到生产架构。
  • 回答方向:缩小边界、分层、缓存、分页、虚拟化、异步化、限流、降级和服务端聚合,并用容量、延迟、错误率和业务指标验证收益。

推荐阅读

基于 MIT 协议开源