Smart/Dumb组件模式：智能组件特殊场景及潜在弊端问询

1. 无对应路由的智能组件场景 #

当然存在这类场景，常见的例子有：

• 全局状态驱动的通用模块：比如用户信息卡片，它需要从全局状态里读取用户头像、昵称这类数据，还得处理刷新用户信息的请求逻辑，但它只是页面里的一个局部模块，不需要独立路由。
• 带交互逻辑的功能块：比如购物车悬浮组件，要监听购物车状态变化、处理商品增减的请求，但它只是嵌在页面头部或侧边的组件，不是单独的页面。
• 模态框类组件：比如登录弹窗，需要处理表单提交、调用登录接口，还得管理弹窗的显示隐藏，这类组件一般是全局挂载或嵌在其他组件里，不需要对应路由。

2. 作为哑组件子组件的智能组件场景与弊端 #

适用场景 #

你提到的「Page级智能组件拿太多无关数据」确实是最典型的场景：

• 当Page组件的状态和数据过于庞杂，拆分深层智能组件能让职责更单一。比如电商商品列表页，原本Page要拿商品列表、用户收藏状态、优惠券信息，现在可以把「带收藏功能的商品卡片」拆成：外层哑组件ProductCard只管渲染UI，内层智能组件ProductCardSmart负责获取该商品的收藏状态、处理收藏/取消的请求。这样Page只需要拿商品列表，收藏相关的逻辑都封装在深层组件里，避免Page逻辑臃肿。
• 复用交互逻辑：如果多个哑组件都需要相同的状态交互逻辑，把智能组件当它们的子组件就能复用代码。比如多个页面的表单都要处理验证码发送，就可以封装一个CodeSenderSmart智能组件，嵌到不同的哑表单里。

潜在弊端 #

这种做法也有不少坑：

• 层级变复杂，调试麻烦：智能组件在深层会增加组件树的嵌套层数，排查问题时要逐层找，比如要查收藏状态的问题，得从Page一路挖到深层的智能组件。
• 数据重复请求：如果上层哑组件已经拿到了部分数据，深层智能组件又重复请求，会浪费资源。比如Page已经获取了商品的基础信息，深层组件又去请求一遍。
• 组件耦合度变高：如果智能组件依赖上层哑组件的props，或者哑组件依赖智能组件的状态输出，两者就绑死了，各自的复用性会降低。比如哑组件必须配合这个智能组件才能用，没法单独放到不需要该逻辑的场景里。
• 状态管理分散：太多深层智能组件订阅全局状态，会导致状态订阅分散，不好统一管理哪些组件在监听哪些状态，状态变更时调试难度大增。

内容的提问来源于stack exchange，提问作者tlt