主题
React 项目实践
如何设计大型 React 项目的目录和模块边界？
面试官关注的不是目录名称，而是模块是否能沿业务领域演进、测试和发布。
面试官想考什么
- 你如何避免所有代码都堆进 components、hooks 和 utils？ 考察领域建模能力。
- 什么应该放在共享层？ 考察复用边界和依赖方向。
- 如何防止客户端代码依赖服务端或基础设施？ 考察工程治理和安全意识。
- 目录设计如何服务测试和发布？ 考察是否考虑长期演进。
一句话回答
text
大型 React 项目应按领域和用例组织业务代码，公共 UI、领域逻辑、服务端访问和基础设施分层，并用依赖规则保证方向稳定。面试回答详解
这道题的重点不是背一个固定目录，而是说明目录如何承载领域边界。可以采用“路由入口 + 领域模块 + 共享能力 + 基础设施”的结构。
1. 建议的分层方式
text
app/pages -> features/domains -> shared UI/hooks
features -> services/repositories -> API/database adapter- 路由层：负责页面组装、参数解析和布局，不承载大量业务规则。
- 领域层：围绕订单、内容、账户等用例组织状态、组件、校验和 API adapter。
- 共享层：只放跨领域且契约稳定的 UI、基础 Hook、类型和工具。
- 基础设施层：封装 HTTP、日志、埋点、配置和第三方 SDK。
2. 关键边界
领域模块可以依赖共享层和基础设施抽象，但共享 UI 不应反向依赖某个业务领域。客户端入口不能导入数据库、私钥或服务端专用模块。通过 ESLint import rules、TypeScript project references 或 monorepo package boundary 固化约束。
3. 工程取舍
按领域拆分适合中大型项目和多人协作；小项目不必为了形式引入过多层。utils、hooks 和 components 如果没有所有权和命名边界，很快会变成无法迁移的公共垃圾场。
4. 生产落地
每个领域应有入口、类型、测试和错误边界；共享包要有变更记录和兼容策略。用构建依赖图、类型检查、测试覆盖和发布影响范围验证目录设计。
可直接背诵的 30 秒回答
text
我会按业务领域和用例组织大型 React 项目，路由层负责组装，领域层负责业务状态和行为，共享层只放真正稳定的 UI、Hook、类型和工具，基础设施层封装请求、日志和第三方依赖。核心是依赖方向不能反转，客户端不能直接碰服务端资源，并通过 lint、类型、测试和构建依赖图持续治理。扩展知识
目录治理信号
- 一个模块是否能被单独测试？
- 修改一个领域是否会触发全站依赖？
- 共享层是否出现大量业务判断？
- 服务端密钥和客户端 bundle 是否有明确隔离？
面试官追问链
追问一：为什么不直接按技术类型分 components/hooks/utils？
- 考察点：是否理解技术分层和领域分层的差异。
- 回答方向：纯技术分层在小项目可用，但大型项目会造成跨领域耦合；可以在领域内部保留技术子层，顶层仍按业务边界组织。
追问二：如何判断一个组件应该进入公共组件库？
- 考察点：是否避免过早抽象。
- 回答方向：至少有稳定语义、多个真实场景、明确 API、行为测试和维护责任，而不是仅仅复制过一次。
追问三：如何自动阻止错误依赖？
- 考察点：是否能落到工程手段。
- 回答方向：使用 ESLint boundaries、路径别名约束、独立 package、CI 类型检查和 code review 规则，并对服务端模块做客户端构建保护。