LINE Confirm Template：两个动作上限、Buttons 四个动作，以及该换用什么

LINE confirm template 适合一个明确的二选一决策：确认或取消、同意或拒绝、继续或返回。只要你需要三个或四个可见动作，就应该看 buttons template；如果需要更多临时选项，则看 quick replies；如果选项是商品、门店或方案卡片，则考虑 carousel 或 Flex Message。

重点结论

• LINE 官方的 Message types 文档把 confirm template 描述为一段文字加两个按钮。
• Messaging API reference 是更细的对象参考，confirm template 的核心字段包括 type、text 和 actions。
• Buttons template 是另一种 template 类型，最多四个 action object；如果你正遇到四个动作上限问题，可以先看这篇 LINE buttons template 替代方案。
• Quick replies 能放更多临时选项，但 LINE 官方说明它们会随着对话变化而消失，不能当作持久菜单。
• UnifyPort 不替代 LINE 原生 UI 组件；它更适合在用户回复之后，把 LINE、WhatsApp、Zalo、Telegram、TikTok 和 X 的入站消息放进同一个 webhook 流程。

Confirm template 到底是什么

LINE 把 template messages 定义为预设版式，包含 buttons、confirm、carousel、image carousel 等类型。Confirm template 的边界很窄：文字加两个按钮。这个设计不是限制，而是为了让用户只做一个清楚的二选一决定。

适合它的场景包括：

• “确认预约” / “取消”
• “使用这个地址” / “修改地址”
• “联系人工客服” / “继续浏览”
• “批准” / “拒绝”

如果你想在一张卡片里塞进四条路径，或让用户从多个商品分类中选择，confirm template 就不是合适组件。

Confirm、Buttons、Quick Replies、Carousel、Flex 怎么选

LINE 组件	最适合	主要交互边界	何时使用
Confirm template	一个二选一决策	两个 action button	明确的是/否、确认/取消步骤
Buttons template	一张紧凑卡片上的少量主动作	最多四个 action object	三到四个同等重要选择
Quick replies	临时下一步菜单	最多 13 个 quick reply button，但不是持久显示	用户应该马上选择
Carousel template	浏览重复结构的对象	多个结构一致的 column	商品、方案、门店、地点
Flex Message	自定义视觉层级	JSON 更复杂，需要多端检查	品牌化、信息密集或复杂版式

所以，“LINE Messaging API confirm template actions limit”的直接答案是：confirm template 不应该超过两个动作。动作数一旦变多，就换一个更匹配决策形状的 LINE 组件。

如果你对比的是 LINE MINI App custom action button，请先读 MINI App custom action button 实现指南。MINI App 分享、LIFF 与 Messaging API templates 是不同任务，不要混在同一个实现里判断。

一个实用判断流程

1. 用户只需要二选一吗？ 用 confirm template。
2. 需要三到四个可见动作吗？ 用 buttons template。
3. 需要五到十三个即时选项吗？ 用 quick replies，并接受它不是持久菜单。
4. 选项是商品、地点或方案卡片吗？ 用 carousel template。
5. 核心问题是版式、品牌或信息层级吗？ 用 Flex Message，并做渲染测试。
6. 真正的问题是收到用户回复并路由到后端吗？ 保留 LINE 官方 UI，把入站事件交给签名 webhook 队列。

UnifyPort 放在哪里

UnifyPort 不负责发送 LINE confirm template、buttons template、quick replies、carousel template 或 Flex Message 这些原生 UI。需要 LINE 原生呈现时，请使用 LINE 官方 Messaging API。

UnifyPort 的位置在入站侧：用户回复之后，你可以用同一个 handler 处理 LINE 与其他消息平台的入站事件。UnifyPort 文档里的事件 envelope 使用真实字段，例如 id、type、provider、account_id、occurred_at 和 data；接收消息时订阅 message.received。

{
  "id": "evt_01j7lineconfirm8p7m4w6n2a",
  "type": "message.received",
  "provider": "line",
  "account_id": "acct_line_support_01",
  "occurred_at": "2026-08-25T09:30:00Z",
  "data": {
    "message": {
      "id": "msg_line_4281",
      "direction": "inbound",
      "type": "text",
      "text": "确认"
    },
    "conversation": { "id": "conv_line_2841" },
    "sender": { "id": "user_line_73" }
  }
}

做出站能力判断前，先看 UnifyPort provider message support matrix；如果下一步是稳定接收回复，则看 webhook events reference。这个分层也和 LINE Service Messages vs Messaging API 的结论一致：原生呈现交给 LINE，客服入站队列保持独立和标准化。

常见问题

LINE confirm template 可以有几个 action？

它适合两个 action button。超过两个选择时，应改用 buttons template、quick replies、carousel 或 Flex Message。

Confirm template 和 buttons template 一样吗？

不一样。LINE 把它们列为不同的 template message 类型。Confirm 是二选一，buttons template 是一张卡片上的少量主动作。

Quick replies 能替代 confirm template 吗？

有时可以。Quick replies 适合临时选择，并且可以显示更多按钮；但它们会随着对话变化而消失，不适合持久导航。

UnifyPort 会发送 LINE confirm template 吗？

不会。UnifyPort 适合用非官方接口接收入站消息并统一路由，不用于渲染 LINE 原生 template UI。

下一步

如果你的目标是 LINE 原生模板呈现，请用 LINE 官方 Messaging API。若目标是把 LINE 和其他平台的回复接入同一个后端，请阅读 UnifyPort webhook events reference。

来源

• LINE Developers: Message types
• LINE Developers: Messaging API reference
• LINE Developers: Use quick replies
• LINE Developers: Flex Message elements

核对日期：2026-08-25。