组件把界面拆小，却可能通过共享变量重新绑在一起。复用的关键是明确输入和输出。
本文使用浏览器 JavaScript、HTML 与局部演示数据。前端复杂性常来自状态与异步关系，而不是组件数量。本文把服务器业务事实、页面查询条件和用户临时编辑分别表达，避免多个界面位置互相覆盖。
1. 从现象推到机制
列表组件接收数据与加载状态，向上报告选择或翻页意图，不直接猜测全局业务。加载中、空结果与加载失败是不同状态。组件事件表达用户动作，是否真的保存成功由业务层按服务端结果决定。
图中的四个节点分别表示显式输入、展示组件、用户事件、业务协调。顺着实线检查输入如何变成输出，再沿虚线核对反馈条件。图示表达的是本文讨论的关系，不是实测曲线或现场截图。
2. 最小实现与输入条件
以分页列表为例列出输入和事件，再用固定数据独立渲染。不要让展示组件直接改父级查询对象。
1
2
3
inputs: rows, loading, error, page, total
events: page_requested, row_selected, retry_requested
owner: parent coordinates request and verified result
先用不连接真实业务的小页面观察状态迁移，保存每次输入与渲染结果。组件拆分之后仍需验证整体任务，不能只检查每个按钮能响应。
3. 用对照区分原因
下表列出需要主动改变的条件。预期行为来自机制分析，复现时还需记录运行环境和原始输出，不能将预期当作已经测得的结果。
| 改变的条件 | 需要验证的行为 |
|---|---|
| 加载失败但 rows 为空 | 应显示错误而非没有数据 |
| 用户点击下一页 | 组件报告意图而不伪造数据 |
| 两个页面复用同一组件 | 不应共享隐式查询状态 |
对照 1：加载失败但 rows 为空
应显示错误而非没有数据。观察时记录loading error empty 三种分支。把这个条件与基准情形分开，有助于判断变化来自哪一层；若得到相反结果，应先核对前提，再修改实现。
对照 2：用户点击下一页
组件报告意图而不伪造数据。观察时记录请求事件与服务端响应。把这个条件与基准情形分开，有助于判断变化来自哪一层；若得到相反结果，应先核对前提，再修改实现。
对照 3：两个页面复用同一组件
不应共享隐式查询状态。观察时记录每个实例的输入与内部状态。把这个条件与基准情形分开，有助于判断变化来自哪一层；若得到相反结果，应先核对前提，再修改实现。
4. 适用条件与取舍
抽象层级要匹配实际复用。只出现一次的复杂业务可先保持清晰局部结构，避免为“通用”暴露几十个互相矛盾的开关。
一次正常运行只覆盖了这组输入。继续扩展前，应把上面的异常对照保留下来，尤其关注“两个页面复用同一组件”这一分支。后续方案若改变了图中任意一处依赖，原来的判断就要重新验证，不能仅凭界面相似或返回值相同沿用结论。
