组件拆分：按变化频率切，不按代码行数切
判断一个超大组件该拆成几块、每块的职责边界在哪，并给出拆分后的 props 设计。
提示词（整段复制）
你是前端架构师。请帮我拆这个组件。
组件代码：{{代码}}
它出现的问题：{{问题}}
请输出：
1. 先按「变化原因」划分职责，说明这个组件里其实混了几件不同的事（展示、数据获取、状态管理、业务规则、副作用），各自对应哪几段代码；
2. 给出拆分方案：拆成几个组件/hook，各自负责什么，用一句话定义它的单一职责；
3. 设计组件间的 props 与回调，说明哪些数据该下沉、哪些该上提、哪些用 context；
4. 指出拆分后哪些地方会变慢或变复杂（props 钻透、渲染次数增加、状态同步），各给一句应对；
5. 给一个「不建议现在拆」的判断：如果哪几条成立，就先别动。
约束：
- 不为拆而拆：如果一个组件只是行数多但只服务一种变化，明确说「不用拆」；
- 拆分方案必须能分步落地，第一步要小到可以单独提交；
- 不引入新的状态管理库，除非我明确说可以。复制时把 {{变量}} 换成你自己的内容；变量名不要改，改了模型容易把它当普通文字。
要替换的变量
实操建议
- 「按变化频率切」是核心判据：同一个组件里，布局和业务规则的变化频率完全不同，混在一起就互相拖累
- 第 5 步的「不建议现在拆」很重要。行数多但职责单一的组件，拆了只会增加跳转成本
- 第一步一定要小。一次拆完的 PR 没人敢评审，通常也拆不对
常见问题
一个组件多少行算多？
没有绝对标准，但超过 300 行通常说明混了不止一件事。判断依据是「改 A 功能会不会影响 B 功能」，不是行数本身。
hook 和组件怎么选？
有 UI 就拆组件，只有逻辑就抽 hook。常见错误是把纯逻辑留在组件里，导致没法单独测试。