我不是一开始就想做组件库。很多组件都是后台写多了以后自然浮出来的。

客户管理、产品管理、用户管理、咨询表单、代销记录，这些页面看起来业务不同，但反复出现同一类东西：表单、上传、筛选、表格、分页、搜索、状态同步和操作按钮。

重复出现才值得抽

我不太喜欢为了抽象而抽象。一个组件只用一次，直接写在页面里更清楚。

但当同样的查询表格和表单模式在多个项目里反复出现，问题就变了。每个项目都重新处理分页、筛选、重置、加载状态、错误提示和 URL 同步，不仅浪费时间，也容易出现不一致。

这时抽组件不是为了显得高级，而是为了减少重复判断。

表格真正麻烦的是状态

后台表格看起来只是展示数据，但真正麻烦的是状态。

当前页、每页数量、搜索词、筛选条件、排序、选中项、请求状态、URL 参数、刷新时是否保留查询，这些都要一起工作。表格如果只封装 UI，价值有限；真正值得封装的是查询状态和交互约定。

我会让表格组件尽量处理通用状态，把业务列和请求逻辑留给页面。这样页面仍然知道自己在做什么，组件也不会变成难懂的黑盒。

表单要处理不完整输入

后台表单的难点不是输入框，而是人怎么填。

字段会漏，文件会上传失败，校验错误要能显示，默认值要能回填，提交后要知道是否成功。文件上传和复杂字段尤其容易在不同项目里重复踩坑。

所以我在表单组件里更关注验证、错误展示、上传状态和提交反馈，而不是只做一组好看的控件。

组件库也会有维护成本

抽出组件以后，并不是从此省事。

组件库要处理版本、依赖、样式、文档、破坏性变更和项目间兼容。一个组件如果被多个项目依赖，随便改一个 API 就可能影响一片。

所以我现在会更克制：只有真正重复、边界稳定、能降低项目复杂度的东西，才适合进入组件库。

抽象来自项目，不来自想象

这类组件沉淀让我确认，好的抽象大多来自真实项目反复磨出来。

先在业务里写，等重复出现，再抽出稳定部分。这样组件更贴近真实后台，而不是为了展示技术而存在。表单和表格看起来普通，但它们决定了后台系统每天用起来是否顺手。