北京
最近在学习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语法层面的技巧，而是把代码组织方式对齐到产品形态。仪表盘不是放大的表单页面，它的数据流动性、布局稳定性、权限复杂性，都要求架构层面提前回答"这段代码明年谁维护"的问题。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
