按业务边界而非UI区域切分组件更有效，以完整业务动作（如下单）为单位封装自洽闭环逻辑；区分UI与容器组件，收敛副作用，状态管理仅用于必要跨组件共享数据，限制props透传深度。
按业务边界切分组件，比按UI区域切分更有效。关键不是“看起来像不像一个模块”，而是“改一处逻辑是否只影响一个业务域”。
以业务动作为单位拆分
把用户完成一项完整业务动作所需的所有逻辑和界面打包成一个组件。比如“下单”不是只做一个按钮，而是包含商品校验、地址选择、优惠计算、提交接口调用、结果反馈的闭环。
- 每个动作组件内部自洽，不依赖外部状态或方法
- 组件间通过明确的 props 和事件通信，不共享数据实例或直接调用对方方法
- 例如：将“创建订单”封装为 OrderCreationPanel，它自己管理表单、校验、提交流程，父组件只传入初始商品信息、监听成功事件
区分 UI 组件与容器组件
UI 组件只接收数据、渲染视图、抛出语义化事件；容器组件负责获取数据、组织逻辑、协调子组件。两者职责隔离，修改样式不影响逻辑，调整流程也不动 UI。
- UI 组件如 UserAvatar、PriceTag，无副作用，可跨项目复用
- 容器组件如 ProfilePageContainer，处理用户信息拉取、权限判断、错误重试，并把结构化数据传给 UI 组件
- 避免在 UI 组件里写
fetch或localStorage操作
收敛副作用与共享逻辑
重复出现的数据获取、格式化、权限判断等，不应散落在多个组件中。统一收口，再按需注入。
- 用组合式函数（Vue 的 composable）或 React 的自定义 Hook 封装通用逻辑，如 useUserPermissions()、useFormattedPrice()
- 状态管理仅用于跨多组件共享且频繁变更的数据（如登录态、全局通知），非必要不引入 Vuex/Pinia/Zustand
- 避免通过全局变量、单例对象或直接 import 其他组件内部方法来传递行为
限制跨组件数据流深度
父子组件通信尽量控制在一层以内。超过两层的 props 透传，说明中间组件承担了不该有的“管道”角色。
- 深层嵌套时，用 provide/inject（Vue）或 Context（React）替代长链 props
- 但仅限于稳定的、低频变化的上下文信息，如主题、语言、API 配置，不用于实时业务状态
- 当发现某个组件总是在转发 props + emit 事件，就该把它重构为容器组件，接管这部分协调职责
