LIFF 是什麼？讓客人在 LINE 對話框內預約、查會員、看訂單
TL;DR
- LIFF（LINE Front-end Framework）是 LINE 平台提供的網頁應用嵌入框架，讓網頁能在 LINE 對話框內直接顯示與運行，省去客戶跳出 LINE 開瀏覽器的動線斷層。
- LIFF 與一般網頁的關鍵差異有三個：身份識別來源、物理顯示空間、與 LINE 原生功能的互動能力。技術上是同一份 HTML，但這三點決定了 LIFF 體驗能不能比一般網頁更順。
- 客戶在 LIFF 內可完成多數短行程操作：預約、查會員、看訂單、瀏覽菜單、領優惠券、活動報名等；但長表單、列印、深度搜尋這類場景，仍適合留在一般網頁完成。
- LIFF 整合的體驗差異來自設計，不來自技術。商家若沒為「對話框內單手滑動」的使用情境優化介面，即使技術上嵌進 LINE 了，客戶感受與一般網頁差異不大。
一、LIFF 是什麼？為什麼 LINE 需要這個技術框架？
核心觀點： LIFF 是 LINE 平台提供的「網頁應用嵌入框架」，目的是讓網頁能在 LINE 對話框內直接顯示與運行，免去客戶跳出 LINE 開瀏覽器的動線斷層。它不是 LINE 的某個新功能，而是讓既有網頁應用「以 LINE 為入口」的標準介面層。
LIFF 全名 LINE Front-end Framework，是 LINE 平台從 2018 年起推出的網頁應用嵌入框架。它的角色不是另一個 LINE 功能，而是一層介面標準——讓商家原本就有的網頁應用（網站、預約頁、會員系統）能透過特定設定後，在 LINE 對話框內直接顯示與運行。
從消費端看，LIFF 解決的是「客戶不想離開 LINE 開瀏覽器」這個動線摩擦：原本要點連結跳出 LINE、開瀏覽器、進入網站、操作完成的流程，被壓縮在 LINE 對話框內一站式完成。
從商家端看，LIFF 解決的是「不想為了 LINE 重寫一套 app」這個成本問題。商家原本就有官網或預約系統，不需要為了在 LINE 內呈現而重新開發原生 app，只需要為既有網頁加上 LIFF SDK（一段 JavaScript 引用）與 LINE Login channel 設定。
技術上，LIFF 有三個前提條件：
第一，必須掛載在 LINE Login channel 下——商家需要先在 LINE Developers 後台建立一個 channel 並取得 channel ID。第二，網頁必須以 HTTPS 提供。第三，網頁載入 LIFF SDK 後，啟動時可呼叫 liff.init() 取得對應的 LIFF context（包含 userId、displayName 等資訊）。
與「直接把網頁網址貼進 LINE 訊息」的做法相比，LIFF 在啟動時可取得 LINE userId、可呼叫 LINE 原生功能（傳訊息、開好友選擇器、關閉視窗返回對話），且結束後客戶能無痕回到對話框繼續對話。這三點是 LIFF 與「一般網頁掛在 LINE 訊息裡」的本質區別。
二、客人在 LINE 對話框內，可以完成哪些網站操作？
核心觀點： LIFF 內可承擔多數「短行程、單一目的」的客戶操作——預約、會員查詢、訂單追蹤、菜單瀏覽、點數查看、活動報名；不適合放進 LIFF 的，是長表單填寫、需要列印或下載的內容、需要橫向比較多項目的深度瀏覽。
判斷一個操作適不適合放進 LIFF，最簡單的標準是看「行程長度」與「目的單一性」。LIFF 在對話框內顯示，物理空間有限、客戶通常是邊聊邊操作，因此短行程、單一目的、結果可口頭回報的場景最適合。
適合放進 LIFF 的場景：
- 預約服務：客戶選日期、選時段、確認、完成，整個流程通常 3-5 步內結束，結果可立即收到 LINE 推播通知。
- 查會員資料、套票餘額、點數紀錄：單一目的的查詢操作，客戶看完即可關閉，不需要長時間停留。
- 查訂單與歷史紀錄：類似會員查詢，重點在「快速看一眼」而不是深度操作。
- 瀏覽菜單、服務列表、作品集：適合卡片式 UI、單手滑動瀏覽，客戶可隨時切回對話與商家確認細節。
- 領取優惠券、活動報名：點擊即完成的操作，配合 LIFF 內的「一鍵分享給好友」可以做出一般網頁做不到的傳播效果。
- 商家公告與即時訊息：商家發佈新訊息時，附上 LIFF 連結讓客戶直接進入詳細頁面。
不適合放進 LIFF 的場景：
- 長表單填寫：婚禮報名、合約簽署、保險投保等需要 10 個欄位以上的填寫，在對話框的有限空間內體驗會明顯弱於一般網頁。
- 需要列印或下載的內容：發票列印、合約 PDF 下載、購買憑證列印——這些操作在 LIFF 內可行但體驗弱於瀏覽器。
- 需要橫向比較多項目的電商瀏覽：大型電商會員逛 50 件商品做比較的場景，LIFF 的顯示空間會限制比較體驗。
換句話說，LIFF 不是「網站的縮小版」，而是「網站功能中最高頻、最簡單的部分，被搬到 LINE 對話框內」。商家在規劃 LIFF 整合時，第一個要決定的不是技術，而是「哪些客戶操作要進 LIFF、哪些保留在一般網頁」。
三、LIFF 跟一般網頁差在哪？三個關鍵差異
核心觀點： LIFF 與一般網頁的差異集中在三個地方——身份識別來源、物理顯示空間、與 LINE 原生功能的互動能力。技術上是同一份 HTML，但這三點決定了 LIFF 體驗能不能比一般網頁更順。
對商家而言，理解 LIFF 與一般網頁的差異，是判斷「值不值得做 LIFF 整合」的基礎。雖然兩者都是網頁，但這三個關鍵差異會在客戶體驗上產生明顯落差。
差異一：身份識別來源
一般網頁要識別客戶，需要客戶輸入帳號密碼，或透過 Google、Facebook 等第三方 OAuth 登入。流程上會出現一段「客戶要做動作才能被認出來」的時間。
LIFF 開啟瞬間，網頁可透過 liff.getProfile() 取得 LINE userId、displayName、頭像 URL。換句話說，客戶從 LINE 進入時，會員辨識可以「無感」完成——不需要輸入任何東西，網頁就知道這個人是誰。
對商家的意義是，預約頁、會員頁、優惠券頁都可以省去登入步驟，直接顯示「您好，王小美，這是您的會員資料」。摩擦消失。
差異二：物理顯示空間
一般網頁佔據整個瀏覽器 viewport，桌面版可以放置寬版表格、多欄佈局；手機版也至少有完整螢幕高度。
LIFF 在 LINE 對話框內以 modal 或 full size 顯示，但仍受對話框 UI 的影響——頂部有 LINE 的標題列、底部可能有對話輸入框。實際可用的顯示高度比一般網頁少。
對商家的意義是，直接套桌面版網頁設計通常會出問題：字級太小、按鈕間距太擠、複雜的下拉選單在小螢幕上難以操作。LIFF 的 UI 設計需要為「對話框內單手滑動」優化。
差異三：與 LINE 原生功能的互動
一般網頁無法主動觸發 LINE 內的動作：不能讓客戶用一個按鈕分享內容給 LINE 好友、不能在客戶完成操作後自動關閉視窗返回對話。
LIFF 透過 SDK 提供這些能力。例如 liff.shareTargetPicker() 可開啟好友選擇器讓客戶分享內容；liff.sendMessages() 可代客戶在當前對話發送訊息；liff.closeWindow() 可在客戶完成操作後關閉 LIFF 返回對話。
對商家的意義是，可以設計出一般網頁做不到的互動：客戶在 LIFF 內領到優惠券，點按鈕一鍵分享給 LINE 好友；客戶完成預約後 LIFF 自動關閉、商家的確認訊息隨即出現在對話。這些細節在客戶感受上是「LINE 內的完整體驗」，而不是「跳出 LINE 操作然後回來」。
四、商家設計 LIFF 體驗時，要考量什麼？
核心觀點： LIFF 整合的體驗差異來自設計、不來自技術。商家側若沒為「對話框內單手快速操作」優化介面，即使技術上嵌進 LINE 了，在客戶眼中與一般網頁無異。
LIFF 在技術上要做出來不算難——多數架站平台或開發團隊都能完成 channel 設定、SDK 載入、頁面包裝。但「能用」與「好用」之間的落差，幾乎都來自設計層面。商家在規劃 LIFF 整合時，常被忽略的四個設計考量如下。
考量一：UI 為「對話框內單手滑動」優化
LIFF 的使用情境是客戶單手拿手機、在對話框內快速操作。介面設計要為這個情境調整：按鈕大小要比桌面版放大、字級不能小於 16px、重要操作要在拇指可及範圍（畫面下半部）。避免複雜的下拉選單、hover 互動、需要精準點擊的小元素。
直接把桌面版網頁包成 LIFF，是商家最常見的設計疏失。介面看起來「有 LIFF」，但客戶實際操作時與一般網頁無異，沒享受到「對話框內快速操作」的便利。
考量二：流程要短
LIFF 場景的客戶通常是「順手做一件事」，不是「來辦完整任務」。預約 LIFF 從點開到完成預約，理想步驟在 3-5 步內：選日期、選時段、確認、完成。若流程超過 5 步，客戶在對話框內的注意力會被打斷（朋友傳訊息、其他通知跳出），完成率會明顯下降。
對於原本需要 10 步以上的長流程，建議拆分：把核心步驟放 LIFF、進階設定保留在一般網頁的會員後台。或者直接判斷這個流程不適合 LIFF，改用「LINE 通知 + 一般網頁完成」的混合動線。
考量三：身份合併
LIFF 拿到 LINE userId 後，要與網站既有會員身份對齊。架站平台層面的會員資料合併考量已在另一篇 LINE 官方帳號該怎麼用 中討論，本節聚焦在 LIFF 拿到 userId 後的實作層次。
具體做法是商家後台需要一張對應表，把 LINE userId 與會員 ID 綁定。客戶第一次從 LIFF 進入時，系統會詢問 email 或手機號碼以建立綁定；之後客戶從 LIFF 任何頁面進入，都能自動辨識為對應會員。
若沒做這層綁定，LIFF 拿到的 userId 與網站會員資料是兩套獨立系統，會員經營仍會出現斷層。
考量四：fallback
LIFF 連結不只在 LINE 內被點擊——客戶可能會把連結轉發給朋友、貼到 Email、加進瀏覽器書籤。在 LINE 之外的環境打開 LIFF 連結時，網頁要能以一般網頁形式打開，不能直接報錯。
此外，舊版 LINE 或某些 webview 環境不支援 LIFF SDK，網頁要有降級處理：偵測到 LIFF 環境不可用時，自動切換為一般網頁模式，引導客戶完成操作或提示客戶更新 LINE 版本。
對企業而言，fallback 不只是工程細節，是品牌風險控制——客戶在任何環境點連結，網頁都要能開，不能出現「LIFF 載入失敗」的錯誤頁。
延伸閱讀：
AHHA 在這方面內建 LIFF 預約流程、LINE userId 與會員身份自動綁定、一般網頁 fallback 三個層次，可作為「為對話框內單手操作優化」的實作參考。
常見問題
LIFF 跟 LINE Login 是同一件事嗎？
不是,但兩者相關。LINE Login 是讓客戶用 LINE 帳號登入網站的身份驗證機制;LIFF 是把網頁嵌入 LINE 對話框內運行的應用框架。LIFF 必須掛載在 LINE Login channel 下才能運行,但兩者解決的問題不同。
設定 LIFF 需要程式開發能力嗎？
視做法而定。從零為自有網站串接 LIFF 需要在 LINE Developers 後台建立 channel、載入 LIFF SDK、處理 userId 取得與會員綁定邏輯,需要前端開發能力。若使用內建 LIFF 整合的架站平台,多數設定能透過後台 UI 完成。
LIFF 在 iOS 和 Android 上行為一致嗎？
整體一致,但細節有差異。例如返回上一頁的手勢、底部安全區域處理、鍵盤彈起時的 viewport 變化在兩個平台上略有不同。實作 LIFF 時建議在兩個平台都測試一輪。
LIFF 有訊息費或使用費嗎？
LIFF 本身免費,只要有 LINE Login channel 即可建立。但 LIFF 內若呼叫 Messaging API(例如預約完成後自動推播通知),推播訊息會計入 LINE 官方帳號的訊息費方案。
LIFF 跟 PWA、Native App 有什麼不同？
LIFF 技術上仍是網頁,只是掛在 LINE 對話框內運行,沒有 app store 發佈、沒有原生功能存取(相機、檔案系統等)。PWA 是讓網頁有部分原生 app 體驗(離線、推播);Native App 是針對 iOS/Android 開發的原生應用。三者開發成本與功能深度遞增。
多個 LIFF 應用要分開建立 channel 嗎？
不一定,視整合需求而定。同一個 LINE Login channel 下可建立多個 LIFF endpoint(每個對應一個獨立網頁路徑)。若不同 LIFF 應用是同一家商家提供、共用同一份會員資料,建議使用同一個 channel;若是不同品牌或要分開管理 token,才需要分開建立。
線上預約 分類其他文章
繼續閱讀同主題的延伸內容
留言討論
只有會員能留言（防止垃圾訊息），留言顯示於此頁。