最近在学习React时，我动手搭建了一个企业级仪表盘——就是那种带有侧边栏导航、数据表格、筛选器和权限控制的复杂界面。这个项目逼着我跳出了新手教程的舒适区，也让我意识到一个痛点：教科书式的React写法，在真实业务场景里根本撑不住。

以下是我踩坑后总结的三个架构教训。

打开网易新闻 查看精彩图片

一、数据获取：从手动fetch到RTK Query的质变

一开始我的直觉很朴素：用useEffect调fetch，把数据存进useState。简单页面没问题，直到"质量检查"表格需要支持标签切换和筛选器联动——状态管理瞬间变成 spaghetti code，loading逻辑到处复制粘贴。

切换到RTK Query后，最直观的收益是不再需要手动管理加载状态和缓存逻辑。

具体做法是把API逻辑抽离到独立的slice文件，定义端点时直接声明数据标签（tagTypes）。组件层简化为一个hook调用：当activeTab变化，请求自动触发更新。没有useEffect的依赖地狱，没有重复的isLoading判断，代码行为终于"像仪表盘该有的样子"。

二、布局架构：三栏式设计与样式分离原则

新手项目通常是整页滚动，但企业UI要求导航始终可见、仅数据区滚动。我最终采用三栏结构：固定顶部栏 + 固定侧边栏 + 可滚动内容区。

关键认知是布局样式与组件样式必须解耦。根布局只负责框架级规则（flex布局、高度计算、溢出控制），内容组件绝不碰这些属性。这个分离让UI从"网页感"跃迁到"工具感"——用户感知不到实现细节，但交互体验完全不同。

三、权限控制：从条件渲染到路由级防护

最初的做法很直接：{user.role === "admin" && }。但问题很快暴露：权限逻辑散落在几十个组件里，新增角色需要全局搜索替换，测试时根本不知道哪里漏了判断。

重构方案是单一权限配置源 + 路由包装器。所有菜单和路由的权限规则集中在一个配置文件，ProtectedRoute组件统一处理未登录跳转和无权访问。新角色"Manager"上线时，只需改配置表，零组件入侵。

这三个决策的共同点？都不是React语法层面的技巧，而是把代码组织方式对齐到产品形态。仪表盘不是放大的表单页面，它的数据流动性、布局稳定性、权限复杂性，都要求架构层面提前回答"这段代码明年谁维护"的问题。