原文：How Senior Frontend Developers think about React Architecture
小声 BB
本文在翻译过程中确保意思传达准确的前提下，会加入很多本人的个人解释和一些知识补充(使用引用块&&括号标注) ，像这样
（我是一个平平无奇的知识补充块）
🎊如果觉得文章内容有用，交个朋友，点个赞再走~ 🎊
一些比较清晰的视角，可以学习到如何高屋建瓴地去构造 React 组件。和读者分享什么才是一个资深开发者应该关注和做到的事情。
正文
好久没写了。
当我们谈论 React 时，我们通常会想到组件。无论是一个简单的按钮、一整个表格，还是一个带图表的完整仪表盘页面。这是我们大多数人开始时的方式。我们打开设计稿，看看屏幕上有什么，然后尝试用代码去还原。
但是，当我们已经开发 React 应用多年，做过数十个功能、上千个组件、几百个边界情况后，我们会意识到，React 其实不只是关于组件，而是关于架构。
而高级前端开发者看待架构的方式，和初级开发者完全不同。我在许多文章中都强调过这一点。这并不是因为他们知道某本书里隐藏的某个神秘设计模式，而是因为......他们看待系统的方式不一样。
架构在第一个组件之前就开始了
初级开发者从 UI 开始：
"这是一个界面，我先来为它构建组件。"
资深开发者不会从这里开始。他们从边界开始。
- 这个功能属于哪里？
- 它依赖什么？
- 谁拥有数据，这些数据应该传播到什么程度？
他们认为组件不是第一步，而是最后一步。组件只是更深层次内容的表层。其下隐藏着一个流程：数据、状态、业务规则、副作用，最后才是 UI。
这种思维转变改变了一切。它能防止在功能增长时架构的崩塌。在我看来，这是最重要的事情之一。
他们保持关注点分离
资深开发者通过艰难的经验学到一件事：当关注点混在一起时，项目就会（某种程度上）腐烂（变成屎山代码）。
初级开发者会很开心地在组件里放一个 API 调用，把表单验证和 UI 渲染混在一起，然后到处加 useEffect 来修修补补。它确实能工作......(能撑住一段时间)。
资深开发者会保持分离：
- UI 层：纯粹的展示型组件。没有逻辑，没有副作用。
- 状态层：数据存储、更新和同步的地方。
- 领域逻辑层：业务规则所在，独立于 UI。
为什么要这么严格？因为分离带来的是自由。如果 API 变了，只需要改领域逻辑层。如果 UI 重新设计了，只需要改组件。每一层都能独立呼吸，而不会扼住其他层的喉咙。
这就是为什么大型应用能存活多年，而不是被自己的重量压垮。
他们不追求完美，而是让改变变得便宜
初级开发者想要"完美"的架构，想预测未来。
资深开发者知道未来总会出乎意料。API 会崩，设计会转向，产品经理会提出全新的需求。再多的远见也无法预测一切。
所以，他们不追求完美，而是为变化而设计：
- 清晰的边界，方便替换。
- 层与层之间的松耦合，方便重构。
- 不做过度设计，只有在真正值得时才做抽象。
所以，我会说，真正的技能不在于今天做出最完美的架构，而在于让明天的改动毫无痛苦。
数据流如河流
React 的核心是数据向下流动、动作向上流动。但在真实的应用中，这些流会成倍增加。数据来自 API、缓存、Redux、context、socket 等等。
初级开发者会把 state 放在感觉方便的任何地方。
资深开发者会问：这个 state 真正属于哪里？
- 只属于一个组件？保持本地化。
- 跨越整个功能？放在 context 或某个状态切片中。
- 属于整个应用？用 Redux、Zustand 或其他 store 集中管理。
一个很好的比喻是：他们把数据流当作河流。水流清晰地向下流动，系统就是健康的；如果它泄漏、积水或泛滥，系统就会崩溃。
他们按"意义"组织代码，而不是按"外观"
这是最隐形但也最深刻的区别之一。
初级开发者按组件组织代码：按钮、卡片、表单。
资深开发者按领域组织代码：用户、支付、设置。
为什么？因为 UI 是临时的。同一个"卡片"可能在十个地方出现，每个地方的含义都不一样。但领域，比如"用户"、"交易"、"通知"，这些东西是长期存在的。
所以，资深开发者不会有一个叫 components/ 的文件夹，而是有 features/ 或 domains/。每个领域都管理自己的 UI、状态和逻辑。代码库开始像是产品的地图，而不是一堆小部件的集合。
这就是为什么新工程师走进资深开发者的项目，能立刻知道东西应该放在哪。
他们拥抱"约束"，而不是"可选项"
初级开发者常犯的一个错误是过度灵活。
"让我们把这个组件做得超级可复用。让它接受 10 个 props，这样什么场景都能用。"
资深开发者走向了相反的方向：我们能限制什么？
- 按钮组件只接受它真正需要的 props......别的不要。
- API 层应该返回有类型、可预测的数据......没有猜测。
- 团队的模式应该是严格的------没有无尽的变体。
约束减少了心理负担。它让系统以一种最好的方式变得无聊。每个人都以同样的节奏编码。架构变得可预测，而可预测性就是力量。
他们知道架构是为人服务的，而不是为机器
这是最后也是最重要的一个教训。我在其他文章里也强调过这一点。
架构根本不是关于代码的。它是关于人的。
- 新开发者能不能不问别人就知道该把文件放哪？
- 两个工程师能不能并行工作而不互相干扰？
- 未来的维护者能不能在没有上下文的情况下读懂这段代码的意义？
这才是架构的真正考验。它并不总是关乎性能、优雅或巧妙的抽象，而是它能否帮助人们无痛地协作。
简而言之......
React 给了我们组件。组件是砖头。但架构才是建筑。
资深开发者不会纠结该用 Redux 还是 Zustand，也不会纠结文件应该放在 src/components 还是 src/ui。这些都是细节。他们思考的是更深层次的东西：边界、数据流、领域、约束，以及人。
(有幸看过高手写代码，确实直接能上手，可以直接从目录结构，文件命名和方法命名，配合注释直接推导出功能，这也是后续学习的目标)
他们构建的系统能够让变更成本很低，让复杂性被控制，让代码的意义清晰可见。
而且他们解释得如此简单，以至于让人觉得理所当然。这就是资深开发者的特质。
我希望这篇文章能帮你用一个全新的视角看待前端开发。如果我有遗漏的地方，可以在评论区补充，让更多人看到。