SQLite 推新版本~修復資料庫損壞漏洞以及漂亮呈現的QRF(Query Result Formatter)

SQLite 是全世界應用最廣泛的嵌入式資料庫引擎,從手機 App、瀏覽器到物聯網裝置都能看到它的身影。2026 年 7 月 24 日發布的 3.53.4 版本,除了修補前幾個小版本(3.53.1~3.53.3)遺留的問題外,也整合了自 3.53.0 以來累積的多項重要功能。以下用淺顯的方式,把這次更新拆解成幾個重點面向來介紹。

一、最值得關心的修復:資料庫損壞漏洞

這次更新最關鍵的一項,是修復了與 WAL(Write-Ahead Log,預寫式日誌)重置有關的資料庫損壞問題。WAL 是 SQLite 用來提升寫入效能與並行處理能力的機制,一旦這個環節出錯,最壞情況可能導致資料庫檔案損毀。對一般使用者來說,這代表:只要有使用資料庫寫入操作的應用程式,都建議儘快升級到這個版本,以避免潛在的資料遺失風險。

二、新增QRF(Query Result Formatter)

QRF(Query Result Formatter)是這次版本很有特色的新功能,簡單來說,它能把 SQL 查詢結果自動排版成整齊的表格,方便在文字介面(例如命令列視窗)中閱讀,例如數字會自動靠右對齊、輸出以框線字元組成表格。這對於習慣用命令列工具查資料庫的工程師或維運人員來說,等於是「不用額外工具,資料庫自己就把報表排版好了」。目前互動式命令列(CLI)已預設採用這種新格式,而批次執行(例如寫腳本自動跑 SQL)則仍維持舊格式,避免既有自動化流程被打亂。

三、SQL 語法更靈活

這次也強化了 SQL 語言本身的能力,重點包括:

  • ALTER TABLE 更彈性:現在可以直接新增或移除欄位的 NOT NULL、CHECK 限制條件,不需要像以前一樣重建整張表。
  • REINDEX EXPRESSIONS:可以單獨重建「表達式索引」(例如根據函數運算結果建立的索引),用來修復索引過期失效的問題。
  • VACUUM INTO 加強:備份資料庫時可以透過 URI 參數指定保留空間大小,方便預留未來成長空間。
  • 新增了 json_array_insert()jsonb_array_insert() 兩個 JSON 處理函數,讓操作 JSON 陣列更方便。

四、查詢效能與規劃器的優化

SQLite 的「查詢規劃器」負責決定一條 SQL 該怎麼執行最有效率,這次做了幾項調整:對於 EXCEPT、INTERSECT、UNION 這類集合運算,一律改用排序合併演算法,官方說明這樣「幾乎總是」比雜湊表快;另外也改善了多表格連接(JOIN)時的順序選擇邏輯,減少不必要的運算。對開發者而言,這些改動通常不需要修改任何程式碼,資料庫會自動跑得更快。

五、浮點數精度改變 — 需要留意的相容性議題

比較值得注意的是,浮點數與文字互相轉換的精度,預設從過去的 15 位有效數字,提升到 17 位。這代表數字顯示可能比以前更精確,但也可能讓某些依賴舊有顯示格式的程式或測試出現差異。如果需要維持舊行為,可以透過 SQLITE_DBCONFIG_FP_DIGITS 設定調整回來。這是一個「預設值改變」型的更新,建議有大量數值運算的系統在升級前先做測試。

六、命令列工具(CLI)多項細節優化

命令列工具本身也有不少貼心的小改進,例如 .timer 指令可以設定只計時下一句 SQL、.progress 可以設定逾時自動中斷查詢、.indexes 指令的搜尋邏輯改為比對索引名稱本身(而非資料表名稱),讓搜尋功能真正符合預期。另外要特別提醒:點指令結尾若有沒加引號的分號,現在會被直接忽略,這是一項可能造成相容性問題的改變,若有腳本依賴舊行為,需要特別檢查。

七、其他技術亮點

新增了多個 C 語言介面函數,方便進階開發者操作字串緩衝區與虛擬表;Session 擴充功能新增了逐項新增變更的介面,方便做資料同步;JavaScript/WASM 版本則新增了 opfs-wl 檔案系統選項,透過瀏覽器的 Web Locks 機制達到更公平的鎖定共享,不過需要較新版本的瀏覽器支援。

重點總結

如果只想記住三件事:第一,這個版本修了一個可能造成資料庫損壞的漏洞,建議儘快升級;第二,新增的 QRF 讓命令列查詢結果變得更好讀;第三,浮點數精度與分號規則有變動,升級前建議簡單測試一下既有系統是否受影響。

需要特別說明的是,官方頁面提到 3.53.4 這個修補版本,主要是為了修正前幾個版本(3.53.1 至 3.53.3)中「主要由人工智慧引起的問題」,詳細細節官方僅指向提交紀錄,並未在頁面上進一步展開說明。

LINE 開發者的 2026 年中震撼彈:Rate Limit 被腰斬 99.5%、帳號終於能「刪除重來」,還有那個消失的最小化按鈕

身為一個每天跟 LINE Messaging API、LIFF 混在一起的 .NET 開發者,我必須說 2026 年這個五月到七月,LINE 官方明顯是把「改版」這件事當成連續劇在更新,一集接一集,還時不時來個「未完待續」。這篇就把這段期間比較有感的更新,一次幫大家整理清楚,順便碎念幾句。

一、Rich Menu 終於有「數據」可以看了,不用再靠感覺

7 月 1 日這天,Messaging API 新增了兩支端點:取得 rich menu 洞察總覽、取得每日洞察數據。以前如果你的圖文選單是用 Messaging API 建的,你只能默默祈禱使用者有點下去;現在終於可以像用 LINE Official Account Manager 建的選單一樣,看到「顯示次數」跟「點擊次數」了。有趣的是官方特別強調,這兩套數據是互不相通的:API 建的選單看不到後台的數據,後台建的選單也看不到 API 的數據。所以如果你們家專案是兩種方式混用,記得數據要分開看,不然老闆問起「圖文選單成效」,你可能要交出兩份報告。

二、Rate Limit 被砍到只剩 0.5%,這是要逼死誰

這大概是整個五月最有戲劇張力的一則公告。5 月 7 日官方先預告:Get rich menu list 這支端點的速率限制,將從每秒 2000 次,改成每秒 10 次。沒錯,你沒看錯,是從 2000 掉到 10,砍幅超過 99%。然後 5 月 26 日,這件事真的發生了。

Get rich menu list
之前:2,000 requests / 秒
之後:   10 requests / 秒

如果你的系統有那種「每次使用者互動就順手查一次 rich menu 清單」的懶惰寫法,這波更新等於直接把你的架構考卷發回來重寫。建議是把清單資料快取起來,別再每次都問 LINE 要清單,畢竟現在問一次的成本,可能比你想像中貴很多。

三、LINE MINI App 內購:免費試用期結束,該收錢了

LINE MINI App 的應用內購買功能,原本佛心來著開放免費使用到 6 月底,官方在 6 月 5 日先預告、7 月 1 日正式上路:從 7 月 1 日之後的交易開始收取服務費用,費率則是以你申請當下公告的費率為準。同時官方也順手修訂了《LINE 應用內購買服務條款》,主要是把費用計算與請款結算方式講得更清楚。如果你們家產品有掛 MINI App 內購,這波記得回頭檢查一下財務試算,別讓會計部門措手不及。

四、日本認證 MINI App 可以跟 Business Manager 組織「牽紅線」了

6 月 10 日這則比較偏在地化:日本地區的已驗證 MINI App,現在可以把 MINI App 頻道連結到 Business Manager 組織,進而跟同組織底下的其他服務(目前支援 LINE 官方帳號)做整合。條件不少,包括地區都要設成日本、服務提供者跟已發布資料的營運公司要一致等等,細節偏繁瑣,但方向很明確:LINE 想把底下這些帳號體系越串越緊,官方也說未來會開放更多整合功能,值得先卡個位。

五、開發者帳號終於可以「刪除」了,但這是不歸路

6 月 24 日的更新算是補了一個长期缺口:LINE Developers Console 終於支援刪除開發者帳號。不過這裡有個重點要劃起來——刪除之後不能復原。而且如果你是某個 Provider 或 Channel 底下唯一的 Admin,刪除前系統會要求你先把權限交接給其他帳號,不然那個服務就等於被鎖死,沒人能再進去改設定。所以與其說這是「刪除帳號」功能,不如說它是一個「離職交接檢查表」,公司內部帳號有異動的話,記得先做好交接再按下去。

六、LIFF 悄悄升級了兩次,但你可能完全沒感覺

5 月 13 日發布 LIFF v2.29.0,6 月 29 日再發布 v2.29.1,兩次都寫著同一句話:只調整 SDK 內部行為,功能沒有變化。這種更新最適合「设了自動更新就不用管」,如果你是走 CDN edge path(https://static.line-scdn.net/liff/edge/2/sdk.js),會自動吃到新版;如果是 npm 使用者,記得手動更新一下:

bash
npm install @line/liff@2.29.1
# 或
yarn add @line/liff@2.29.1

雖然官方說功能沒變,但內部行為調整這種話,老實講我都會半信半疑地多測一輪回歸測試,你們也是吧?

七、LIFF 瀏覽器大改版:多分頁圖示退場,換成三顆點點

5 月 19 日這則跟 UI/UX 關係最大:從 LINE 26.7.0 版開始,LIFF 瀏覽器的標頭規格整個翻新。原本那顆代表「多分頁檢視」的按鈕圖示,換成了直式三個點的選單圖示;點下去也不再直接跳去分頁畫面,而是彈出一個下拉選單,裡面塞了全部分頁、重新整理、最小化瀏覽器、分享、加到主畫面、我的最愛、權限設定、關於此服務、回報問題等一長串選項。另外,已驗證 MINI App 原本在標頭上的「最小化」按鈕,現在被收進下拉選單裡,原本的位置換成了「關閉」按鈕。如果你的 MINI App 有針對舊版標頭做過任何客製化引導教學或截圖說明,這波更新後這些素材大概都要重拍一輪了。

八、五月那場 LIFF/MINI App 事故:一段從 4/27 燒到 5/14 的小插曲

最後提一下背景插曲:4 月 27 日到 5 月 14 日之間,Android 版 LINE 26.6.0 / 26.6.1 有個 bug,導致在特定情境下(LIFF 瀏覽器開著時,用 Intent 或 App Link 又叫出同一個或另一個 LIFF/MINI App)會拿不到使用者 profile、LIFF API 也會怪怪的。官方後來在 5 月 14 日推出修復版 LINE 解決問題,但在那之前也貼心提供了一段暫時解法,用 location.href 做頁面轉跳、並在偵測到類似 invalid_request 的錯誤時手動登出再登入:

javascript
const params = new URLSearchParams(location.search)
const liffState = params.get('liff.state')
const redirectUri = liffState
  ? new URL('.' + liffState, location.href).toString()
  : location.href

liff.login({ redirectUri })

這種「先給暫時解法、再補正式修復」的節奏,其實蠻值得學起來——不管是自己開發的服務出包,還是等第三方修 bug,先讓使用者有路可走,永遠比讓他們卡死畫面來得體貼。

小結:這波更新告訴我們什麼

整體看下來,這兩個月 LINE 平台的更新可以歸納成三個關页字:限流變嚴、收費上路、體驗微調。速率限制被砍等於在提醒大家該做快取就要做;MINI App 收費代表商業模式正式進入下一階段;LIFF 的一連串小改版則是提醒我們,前端串接這種東西永遠不能「串完就沒事了」,得定期回去看看官方公告,免得哪天使用者截圖來問你「這個按鈕怎麼不見了」,你才第一次知道有這回事。