很多团队做营销站，会把组件拆分理解成一件很表面的事：
- 首屏做一个 Hero.vue
- 卖点做一个 FeatureList.vue
- 价格做一个 Pricing.vue
文件是拆开了，但页面依然难维护，原因在于拆分只停留在视觉层，没有拆清楚每个组件的职责、输入和转化位置。
营销站和后台页面不同。后台更强调功能完整，营销站更强调一条连续的信息说服链：先抓注意力，再解释价值，再建立信任，最后推动行动。
如果你已经看过 Vue 做落地页的结构、表单与埋点、Vue + Tailwind 做网页制作、高转化落地页结构 和 组件库思维做落地页，这篇会继续往“组件拆解的工程层”走。
一、营销站组件不是按样式拆，而是按决策阶段拆
用户浏览营销站时，通常要完成四个判断：
- 你在卖什么。
- 这和我有什么关系。
- 为什么要信你。
- 我接下来该做什么。
所以组件拆解最先应该映射的是这四个阶段，而不是“设计稿有几块”。
| 决策阶段 | 常见组件 | 核心任务 |
|---|---|---|
| 识别问题 | Hero、Announcement、Badge | 让用户快速理解主题与对象 |
| 理解价值 | Feature、Use Case、Comparison | 解释收益与适用场景 |
| 建立信任 | Testimonial、Case Study、FAQ | 回答顾虑，降低风险感 |
| 推动行动 | Pricing、CTA、Lead Form | 让用户做下一步决策 |
当你这样拆，组件的边界就清楚得多。
二、Hero 组件最重要的不是大图，而是信息排序
Hero 组件最容易被误解成“视觉区块”，但它本质上是页面的第一轮资格筛选。
一个能工作的 Hero，至少要回答：
- 服务对象是谁
- 核心收益是什么
- 为什么现在值得继续看
- 下一步要点哪里
推荐最小结构：
- 标签或分类信息
- 主标题
- 一句结果导向副标题
- 主 CTA 与次 CTA
- 证据元素，例如客户数量、结果数据或 logo
常见错误反而不是“视觉不够高级”，而是：
- 标题写得很抽象
- 副标题重复标题
- CTA 太多
- 证据离得太远
三、Feature 组件的任务不是罗列功能，而是建立价值映射
很多页面的 Feature 区像一堵卡片墙，问题不在卡片数量，而在它们没有回答用户为什么该关心。
更有效的 Feature 组件，应该让每张卡片都能对应：
- 解决什么痛点
- 适合什么场景
- 带来什么结果
你可以把 Feature 数据结构设计成这样：
| 字段 | 作用 |
|---|---|
| title | 用户可快速扫描的能力点 |
| problem | 该能力解决的实际问题 |
| outcome | 使用后能得到什么结果 |
| evidence | 用数据、案例或机制补证据 |
| action | 是否要导向更深页面或 CTA |
这样 Feature 组件就不仅能展示，还能承接站内内链和后续实验。
四、Pricing 组件最容易出问题的，是“价格表写了，决策成本没降”
价格区的核心任务不是把三个套餐摆出来，而是帮助用户做选择。
一个真正有用的 Pricing 组件，应该把以下三层信息说清楚：
- 谁适合哪个方案。
- 每个方案的差异是什么。
- 用户选择之后会发生什么。
推荐结构：
- 套餐名与适用对象
- 关键差异点 3 到 5 个
- 限制条件或边界说明
- CTA
- 补充型风险说明，例如退款、试用、升级路径
如果没有这些，用户看到的只是“价格”，没有“选择依据”。
五、组件拆解要有“契约”，否则页面后面一定乱
所谓组件契约，指的是每个组件都要定义清楚：
- 接收哪些数据
- 允许哪些插槽或变体
- 负责什么，不负责什么
- 是否承担埋点和可见性逻辑
例如 Hero 不应该直接承担复杂业务判断；Feature 不应该私自决定 CTA 文案；Pricing 不应该自己拼凑用户案例。
如果没有契约，页面会慢慢演变成“哪里方便就往哪里塞逻辑”，最后看似组件化，实际耦合很高。
六、埋点和实验要在拆组件时一起设计
营销站不是静态作品，它要持续优化，所以组件拆解时就应该考虑实验与埋点。
建议为核心组件至少预留这些观测点：
- Hero 主 CTA 点击率
- Feature 区块滚动到达率
- Pricing 卡片点击或切换率
- FAQ 展开率
- 表单开始填写率和完成率
如果这些数据点是后面临时加的，往往会破坏组件边界，还容易漏埋。
七、失败案例：页面切成了十几个组件，但转化和维护都变差
一个常见失败模式是“过度组件化”。
团队为了追求复用，把一个营销站切成十几个很小的组件：标题组件、按钮组件、数字组件、段落组件、图标组件。结果页面层需要传一大堆零碎 props，任何一个文案调整都要改多个地方。
根因在于：
- 没有把组件按业务阶段聚合
- 过早抽象通用性
- 视觉原子组件替代了页面级组件
修复思路通常是两层：
- 页面级组件负责完整语义，例如 HeroSection、PricingSection。
- 基础组件只服务于页面级组件，不让页面自己拼一堆原子组件。
八、一个适合营销站的组件分层方式
推荐把营销站组件分成三层：
1. 页面段落层
例如 HeroSection、FeatureSection、PricingSection、FaqSection。
这一层负责信息结构、文案关系和转化节奏。
2. 业务片段层
例如 BenefitCard、PlanCard、CaseHighlight、TrustBadge。
这一层负责在多个页面段落中复用相似信息模式。
3. 基础 UI 层
例如 Button、Heading、Icon、Badge。
这一层只管视觉与基础交互，不管页面说服逻辑。
这样既不容易抽象过早，也更利于后续做 A/B 测试。
九、检查清单
- 组件拆分是否对应用户决策阶段，而不只是视觉分块
- Hero 是否在首屏内说清对象、价值和行动路径
- Feature 是否把能力点映射到用户问题和结果
- Pricing 是否帮助用户选择，而不是只列价格
- 是否为页面级组件定义了清晰的数据契约和职责边界
- 埋点和实验需求是否在拆组件阶段就已考虑
结语
Vue 做营销站，真正难的从来不是把设计稿切成文件，而是把页面的说服逻辑切成稳定、可演进的组件。只要你按决策阶段拆、按契约管理、按数据验证，Hero、Feature、Pricing 就不再是三个独立区块，而是一条连续的转化链。
