很多团队做落地页时，真正浪费时间的不是写代码，而是每次都从头重新搭模块。
今天这个页面做一个 Hero，明天那个页面再抄一个 Hero；按钮、卡片、表单和信任区看起来都差不多，但每次实现都略有不同。结果就是：
- 改版成本越来越高
- A/B 测试很难稳定对比
- 设计语言越来越散
所以落地页组件库的价值，不是“更像设计系统”，而是让页面增长变成可复用流程。建议搭配阅读 Design Tokens 工程化实践、设计系统完整指南、高转化 Hero 区手册 和 网页内容结构：导航、页脚、模块化。
先给结论：落地页组件库不是 UI 展示柜，而是转化组件的最小生产系统
一套可用的落地页组件库，至少要让团队回答这三个问题：
- 这个模块解决什么业务问题
- 它有哪些固定结构和可变参数
- 改一次后，能否在别的页面重复复用
如果一个组件无法复用，它更像特例页面，而不是组件资产。
一、最值得优先组件化的 5 类模块
| 模块类型 | 作用 | 为什么优先 |
|---|---|---|
| Hero | 传达主价值与 CTA | 首屏最常改、影响最大 |
| 按钮系统 | 统一主要行动 | 决定交互一致性 |
| 卡片模块 | 承载卖点、功能、案例 | 最容易多页复用 |
| 表单模块 | 承接转化 | 直接影响线索获取 |
| 信任模块 | 承载评价、数据、Logo | 决定可信度与转化 |
很多团队先做最复杂的组件，反而不如先把这 5 类打稳。
二、每个组件必须同时定义“固定骨架”和“可变参数”
例如按钮组件，不应该只是一个颜色块，而应该定义：
- 语义角色：主 CTA / 次 CTA / 文字操作
- 变体：主色、描边、浅色、危险态
- 尺寸：大、中、小
- 状态：默认、hover、disabled、loading
如果没有这套参数，所谓组件复用最终还是靠复制粘贴。
三、组件库的真正价值，在于把改版成本压下来
落地页不是一次性交付，它往往要持续：
- 改标题
- 改 CTA
- 改视觉风格
- 做 A/B 测试
- 换案例和信任信息
这时组件化能带来的收益非常直接：
$$ 改版成本 = 改动范围 \times 组件耦合度 $$
组件边界越清晰，改版时波及范围越小。
四、表单与信任区最适合做成组合组件
很多团队做表单时只抽输入框，忽略了完整转化路径其实还包括：
- 标题与引导文案
- 错误提示
- 隐私说明
- 提交成功反馈
- 周边信任证据
所以更实用的做法通常是把“表单 + 说明 + 反馈 + 信任说明”视为一个组合组件，而不是几个零散控件。
五、组件库也应该服务 A/B 测试，而不是阻碍测试
如果组件每次都写死，A/B 测试会很痛苦；如果组件参数边界明确，测试就变成：
- 换标题层级
- 换按钮文案
- 换案例排序
- 换信任区证据类型
也就是说，组件化不是让页面都长一样，而是让变化发生在可控参数上。
一个失败案例：页面很多，但没有组件资产
典型现象是：
- 团队已经做了 20 个落地页
- 每页都有按钮、卡片、FAQ、表单
- 但实现都略有不同，命名、间距、状态也不统一
- 想统一改 CTA 样式时，必须逐页返工
这类问题不是设计能力不足，而是没有把“共性”抽成资产。
落地页组件库检查清单
- 是否优先组件化 Hero、按钮、卡片、表单、信任模块
- 每个组件是否定义了固定骨架与可变参数
- 是否建立了尺寸、状态和语义变体体系
- 表单与信任区是否按转化链路组合设计
- 是否支持低成本 A/B 测试
- 改一个设计 token 时，是否能联动多个页面保持一致
