嵌在程式裡就能跑的分析型資料庫，可以直接用 SQL 查 CSV 與 Parquet 檔，不用架伺服器。
💰 Free⚖️ 可商用🔒 本機執行，資料不離開你的機器📌 活躍（DuckDB 基金會維護）
不適合多人同時寫入的交易型系統、完全不會 SQL 的使用者、需要即時串流處理
看完整判斷
你需要注意- 要會 SQL
- 不是給多人同時寫入的線上系統用的
- 超大規模資料仍需要分散式方案
讓不會寫 SQL 的人也能查資料、做儀表板的 BI 工具，可自架。
💰 Freemium⚖️ ⚠️ 開源版是 AGPL🔒 自架不上傳，資料留在自己的伺服器📌 活躍（Metabase 官方維護）
不適合⚠️ 想把它嵌進自家產品賣人卻沒看清授權的情況、只有自己一個人分析（DuckDB 更輕）
看完整判斷
你需要注意- ⚠️ AGPL 授權，嵌入對外產品要先確認
- 自架要有人維運
- 複雜分析仍需要會 SQL 的人
時序預測的統計模型函式庫（AutoARIMA、AutoETS 等），官方宣稱比 Prophet 快 500 倍。
💰 Free⚖️ 可商用🔒 本機執行，資料不外傳📌 活躍（Nixtla 維護）
不適合結構性斷裂的情境（疫情、政策改變）、資料太短或太零散、把預測當成保證的用法
看完整判斷
你需要注意- 要會 Python 與基本統計概念
- 預測建立在「過去模式會延續」的假設上
- 極端事件無法預測，要留人工判斷空間
最普及的監控與儀表板工具，可接各種資料源做即時視覺化與告警。
💰 Freemium⚖️ ⚠️ AGPL-3.0🔒 自架不上傳，資料留在自己的伺服器📌 活躍（Grafana Labs 官方維護）
不適合⚠️ 要嵌進對外商業產品又沒評估授權的情況、純粹做商業分析報表（BI 工具更合適）
看完整判斷
你需要注意- ⚠️ AGPL-3.0，商業嵌入要先評估
- 自架要有人維運
- 儀表板做得多之後，維護成本比想像高
Python 的資料工作流編排工具：排程、重試、快取、事件觸發，把腳本升級成能上線的流程。
💰 Freemium⚖️ 可商用🔒 自架不上傳，資料留在自己的伺服器📌 活躍（Prefect 官方維護）
不適合不寫 Python 的團隊、單純兩個系統串接（Zapier 類更快）
看完整判斷
你需要注意- 要寫 Python
- 自架要維運伺服器與資料庫
- 版本之間 API 有過較大變動，升級要看遷移指南
以 Rust 寫成的高效能資料處理引擎，官方說明串流模式下「有機會在筆電上處理 250GB 的資料集」。
💰 Free⚖️ 可商用🔒 本機執行，資料不外傳📌 活躍（Polars 官方維護）
不適合不寫程式的使用者、小資料（pandas 或試算表就夠）
看完整判斷
你需要注意- API 與 pandas 不同，既有程式要改寫
- 生態系與教學資源少於 pandas
- 要會寫程式
Apache 基金會的資料探索與視覺化平台，可用無程式介面或 SQL 編輯器建圖表與儀表板。
💰 Free⚖️ 可商用🔒 自架不上傳，資料留在自己的伺服器📌 活躍（Apache 軟體基金會）
不適合小團隊只要看幾張圖（Metabase 上手更快）、沒有維運人力的團隊
看完整判斷
你需要注意- 安裝與維運比 Metabase 複雜
- 初期設定與權限模型學習成本高
- 要有人長期維護
全球開放地圖資料庫，附三種免費取用管道：圖磚、地址與座標查詢（Nominatim）、資料查詢（Overpass）。本站山脈與釣魚作品的座標與軌跡底層。
💰 Free⚖️ 可商用（須標示出處，衍生資料庫須同授權釋出）🔒 訓練政策未查證📌 活躍（OpenStreetMap 基金會與 FOSSGIS 營運）
不適合高流量或商業級的即時地理編碼（公用服務有嚴格限流）、自動完成搜尋（Nominatim 政策明文禁止）、需要保證可用性的服務（官方不保證）
看完整判斷
你需要注意- ⚠️ 公用服務跑在捐贈的伺服器上，不保證可用性，可能不通知就封鎖
- Nominatim 同名道路會錯配到幾公里外，每一批都要做離群掃描
- Overpass 有空位不代表查詢跑得完，逾時要換路不是重試
- 資料是志工編的，缺漏與錯誤要自己驗
免金鑰的天氣預報 API，回 JSON。本站 13 支作品的天氣來源，是全站用最多的一個。
💰 Freemium⚖️ ⚠️ 商用要付費方案🔒 訓練政策未查證📌 活躍（Open-Meteo 官方營運）
不適合⚠️ 商業用途（要付費方案）、需要台灣官方觀測值、每分鐘超過 600 次的高頻服務
看完整判斷
你需要注意- 預報是全球模型算的，山區地形細節看不到；要台灣本地官方觀測還是得回氣象署
- 免費額度是給非商業用的，有廣告或收費就算商業
- 不同高度的溫度是兩件事，要先看它在講哪個高度
查任一座標海拔的開源 API，公用端點免金鑰。本站 10 支山岳作品用它驗山峰座標、算爬升。
💰 Free⚖️ 商用權利未查證🔒 訓練政策未查證📌 活躍（ajnisbet 維護，GitHub）
不適合每天超過 1,000 次的批次查詢（要自架）、把單一資料集當作真值（不同解析度差很多）、沒逐資料集看授權就商用
看完整判斷
你需要注意- ⚠️ 不同解析度的資料集不能共用同一套誤差門檻，同一座標可以差數百公尺
- 刀刃地形與塔狀山頂會被網格抹平，低估是常態
- 每天 1,000 次很快用完，批次要自架
台灣官方的天氣預報與觀測資料 API，要申請授權碼。本站山域與海邊作品的官方天氣來源。
💰 Free⚖️ 商用權利未查證🔒 訓練政策未查證📌 活躍（中央氣象署營運）
不適合直接從瀏覽器打（授權碼會外露）、不想註冊帳號的專案、需要全球資料
看完整判斷
你需要注意- ⚠️ 授權碼寫進前端就等於公開，本站作品都繞 Worker 代理
- 說明與條款頁需 JS，程式化查證做不到
- 大量下載官方要求另外申請會員（data.gov.tw 登錄頁原文）
全球物種出現紀錄的彙整庫，API 免金鑰。本站物種圖鑑的分布資料來源。
💰 Free⚖️ ⚠️ 逐資料集看授權（CC0／CC BY／CC BY-NC 三種）🔒 訓練政策未查證📌 活躍（GBIF 秘書處營運）
不適合整批當可商用（約 15% 是 CC BY-NC）、需要精確座標的應用（各資料集精度不一）、沒逐筆看授權就拿去做產品
看完整判斷
你需要注意- ⚠️ 不能整批當可商用，要逐筆看 license
- 資料是各機構上傳的彙整，座標精度與鑑定品質差異大
- 條款頁需瀏覽器才能開，程式化查證做不到
純前端的全文搜尋程式庫：幾百到幾萬筆資料在瀏覽器裡建索引、模糊比對、前綴搜尋，不用後端。
💰 Free⚖️ 可商用🔒 訓練政策未查證📌 活躍（Luca Ongaro 維護；最近推送 2025-09）
你會在什麼情況下想到它站上有一份幾百筆的名錄（餐廳、步道、題目），使用者想打幾個字就找到，而你不想為了搜尋養一台伺服器。
怎麼用（最短路徑）
- `npm i minisearch`，或直接用 ESM CDN 引入。
- 宣告要索引的欄位（`fields`）與要回傳的欄位（`storeFields`），`addAll(rows)`。
- 中文一定要自訂 `tokenize`：把連續中文切成兩字一組（bigram），否則「牛肉麵」整句是一個詞，搜「牛肉」找不到。
- 查詢時開 `prefix: true` 與 `fuzzy: 0.2`，前者讓打一半就有結果，後者容錯一個字。
- 資料變動就整份重建，幾百筆不到半秒，不要試著增量維護。
真實案例：米其林指南的 433 家餐廳做站內搜尋433 筆、18 個文字欄位本站作者實作（最小落地，2026-09-19）
restaurants.json → MiniSearch（bigram tokenizer）→ 瀏覽器內查詢
為什麼在瀏覽器建索引，而不是把索引檔一起出貨？因為索引比資料還大。實測數字讓這個決定沒有懸念。
- 建索引433 筆、18 個欄位，362.9 ms 建完。
- 索引大小序列化後 489,079 bytes，原始 JSON 只有 364,552 bytes——出貨索引等於多載一份資料。
- 查詢速度「牛肉麵」29 筆 7.63 ms、「鼎泰豐」1 筆 2.30 ms、「綠星」3 筆 0.28 ms。
- 找不到的「ramen」0 筆——資料裡英文名沒有這個字，字面搜尋不會自己懂拉麵＝ramen，同義詞要另外餵。
踩坑
- 預設 tokenizer 對中文無效。它用空白與標點切詞，「蔡家牛肉麵」整個是一個 token，搜「牛肉麵」會用前綴比對勉強中，搜「肉麵」就沒了。bigram 切法是最省事的解。
- 不要序列化索引再出貨。433 筆的索引就比資料大 34%，資料越多差距越大；在瀏覽器建只要零點幾秒。
- `fuzzy` 開太大會把「台中」配到「台北」，0.2 是能容錯又不亂配的數字，要自己拿資料試。
什麼時候不要用它
- 資料超過幾萬筆：索引記憶體與建索引時間都會讓手機吃不消，該上 DuckDB-wasm 或後端。
- 只是要「篩選」不是「搜尋」：下拉選縣市、選類別，直接 `filter()` 就好，不需要索引。
- 需要語意（「便宜的日本料理」）：那是向量檢索或 LLM 的事。
要換的話
FlexSearch（更快但 API 較繞）、Fuse.js（純模糊比對、不建倒排索引，幾百筆以內夠用）、DuckDB-wasm（真的要 SQL 與大資料時）。
費用、授權、資料政策與維護狀態
你需要注意- ⚠️ 預設的斷詞把整句中文當一個詞，中文一定要自訂 tokenizer
- 序列化後的索引可能比原始資料還大，別把索引出貨，在瀏覽器現場建
- 只做字面比對，同義詞（拉麵／ramen）要自己餵
瀏覽器與 Node 都能跑的地理計算程式庫：兩點距離、最近點、點在不在多邊形內、緩衝區，吃標準 GeoJSON。
💰 Free⚖️ 可商用🔒 訓練政策未查證📌 活躍（Turf 社群維護）
你會在什麼情況下想到它你有一批經緯度（山峰、店家、釣點），要回答「離我最近的是哪個」「有幾個在 10 公里內」，或懷疑其中有幾筆座標是錯的。
怎麼用（最短路徑）
- `npm i @turf/turf`（整包）或只裝 `@turf/distance`、`@turf/nearest-point` 這種單模組。
- 把座標包成 GeoJSON：`turf.point([lng, lat])`——經度在前，跟平常寫 lat,lng 相反。
- `nearestPoint`、`distance`、`booleanPointInPolygon`、`bboxPolygon` 四個函式就能做完大部分事。
- 離群掃描：不要用一個大框，改算「每個點到名單內最近鄰的距離」，異常大的才是錯。
真實案例：郊山漫遊的 100 座小百岳做座標體檢100 座、含標高與縣市本站作者實作（最小落地，2026-09-19）
xiao-baiyue.js → GeoJSON FeatureCollection → nearestPoint／distance／booleanPointInPolygon
為什麼離群掃描不能用「台灣本島邊界框」？因為框會把對的當成錯的。這次就抓到三筆假警報。
- 最近點台北 101 最近的小百岳是南港山，2.37 km；10 km 內有 6 座。
- 邊界框掃描用本島框（119.9–122.1，21.8–25.4）掃，3 座在框外：雲台山、太武山、蛇頭山——全是金門馬祖，座標沒錯，是框錯了。
- 最近鄰掃描改算兩兩距離，最近的三對是 2,999 m、3,022 m、3,240 m，沒有異常近的重複點，也沒有異常遠的孤點。
- 結論外島是資料現實不是錯誤；離群要用相對距離判，不用絕對框。
踩坑
- 經緯度順序。GeoJSON 是 `[lng, lat]`，資料檔通常是 `lat, lng`，包錯順序所有距離都算得出來、而且全錯，不會報錯。
- 邊界框會誤判外島。金門、馬祖、蘭嶼在任何本島框外，掃出來要先問「它是不是本來就在外面」。
- `@turf/turf` 整包引入體積大，前端出貨要改成單模組引用。
什麼時候不要用它
- 只是算兩點距離：Haversine 公式十行就寫完，不必裝套件。
- 要路程或等時圈：那是路由引擎（OSRM、Valhalla）的事。
- 資料量到十萬點以上：改用 PostGIS 或 DuckDB 的空間擴充。
要換的話
geolib（更輕、只做距離與方位）、Python 端的 shapely＋geopandas（建置腳本階段做同樣的事，本站山岳作品多半在這一層做）。
費用、授權、資料政策與維護狀態
你需要注意- ⚠️ 用本島邊界框做離群掃描，外島會全部被標成錯
- 整包很大，正式出貨要只引用用到的模組
- 距離是大圓距離，不是路程
瀏覽器與 Node 的 CSV 解析器：處理引號、換行、BOM、串流大檔，幾十 MB 的政府開放資料一秒內解完。
💰 Free⚖️ 可商用🔒 訓練政策未查證📌 活躍（Matt Holt 與社群維護）
你會在什麼情況下想到它政府開放平臺給你一個幾十 MB 的 CSV，你想在建置腳本或瀏覽器裡直接讀，而不是先開 Excel 另存。
怎麼用（最短路徑）
- `npm i papaparse`；Node 端 `Papa.parse(text, { header: true, skipEmptyLines: true })`。
- 看 `result.errors`，空陣列才算解成功；`result.meta.fields` 是欄名。
- 檔案大於幾十 MB 改 `Papa.parse(stream, { step })` 一列一列處理，不要整份讀進記憶體。
- 抓下來的檔先看 Content-Type 以外的東西：政府平臺的 CSV 會標成 text/html，程式照標頭判斷會走錯分支。
真實案例：政府資料開放平臺全目錄 CSV 一次解完67,744,251 bytes、52,422 列、22 欄本站作者實作（最小落地，2026-09-19）
curl 全目錄匯出 → PapaParse（header 模式與串流模式各跑一次）
整份讀還是串流？67 MB 兩種都跑得動，差別在記憶體不在速度；決定的依據是它會跑在哪台機器。
- 整份解析讀檔 322 ms、解析 861 ms，52,422 列 22 欄，0 個錯誤；第一欄名乾淨無 BOM 殘留（它自己處理掉了）。
- 串流解析977 ms 跑完同樣 52,422 列，記憶體只留當下那一列。
- 順手統計授權方式：政府資料開放授權條款第 1 版 52,380 筆、CC BY 4.0 16 筆、CC0 15 筆、CC BY-SA 8 筆、OFL 3 筆。
- 目錄每天在變09-17 抓是 53,191 列，09-19 是 52,422 列——少了 769 個資料集。要重複跑的統計必須記日期。
踩坑
- Content-Type 說謊。這份 CSV 的回應標頭是 text/html，內容是 CSV；程式若照標頭決定解析器會走錯路，要看內容開頭。
- BOM 它會吃掉，但不是所有工具都會。同一份檔用別的解析器第一欄名可能多一個看不見的字元，篩不到。
- 所有欄位都是字串：`'12' > '9'` 是 false，數值欄要自己 `Number()`。
什麼時候不要用它
- 檔案是 .xlsx：用 SheetJS 或 exceljs。
- 要做真正的分析（group by、join）：把 CSV 丟進 DuckDB 或 Polars，不要在 JS 裡手寫聚合。
- 只是十幾列的小設定檔：`split(',')` 就夠，不必裝套件。
要換的話
csv-parse（Node 端、串流原生）、DuckDB-wasm（要 SQL 時直接 `read_csv`）、Python 的 pandas／Polars（建置腳本階段）。
費用、授權、資料政策與維護狀態
你需要注意- `header: true` 要求第一列是欄名，多列表頭的公文式 CSV 要先砍
- 所有值都是字串，數字要自己轉
- 串流模式在瀏覽器要用 File 物件，不是純字串
TypeScript 的輕量 ORM，直接支援 Cloudflare D1：用程式碼宣告資料表，查詢寫起來像 SQL 但有型別檢查。
💰 Free⚖️ 可商用🔒 訓練政策未查證📌 活躍（Drizzle Team 維護）
你會在什麼情況下想到它Worker 裡 `env.DB.prepare('SELECT ...').bind(...)` 的字串越寫越多，欄位改名要全文搜尋，沒有任何東西幫你檢查。
怎麼用（最短路徑）
- `npm i drizzle-orm`；用 `sqliteTable()` 宣告表與欄位，這份宣告就是 schema 的單一來源。
- Worker 裡 `const db = drizzle(c.env.DB)`，`db.select().from(t).where(eq(t.item, x)).orderBy(desc(t.day)).limit(5)`。
- 插入用 `db.insert(t).values([...]).returning({ id: t.id })`，D1 支援 returning。
- 彙總用 `sql`avg(${t.price})`` 樣板配 `groupBy`。
- 建表這次用 `wrangler d1 execute --local --file=schema.sql`；正式流程要走 drizzle-kit 遷移，本站還沒測。
真實案例：農漁產行情那種每日價格表：宣告、寫入、查詢、彙總1 張表、2 個索引、3 種查詢本站作者實作（最小落地，2026-09-19）
sqliteTable 宣告 → drizzle(env.DB) → wrangler dev --local 的 D1
為什麼 schema 用程式碼宣告，而不是只留 schema.sql？因為查詢時的欄位名會被型別系統檢查。打錯欄位名在編輯器就紅，不用等到線上回空陣列。
- 寫入POST 三筆 → `insert().values().returning()` 回 3 個 id，HTTP 201。
- 查詢`where(eq(item, '青江菜')).orderBy(desc(day)).limit(5)` 回 2 筆，依日期新到舊。
- 彙總`select({ avg: sql`avg(price)`, n: sql`count(*)` }).groupBy(item)` 回每個品項的均價與筆數，青江菜 13.25。
- 沒測的drizzle-kit 產遷移檔、`wrangler d1 migrations apply`——這次建表直接跑 SQL 檔，正式專案要補這段。
踩坑
- 遷移是另一套工具。drizzle-orm 只管查詢，表結構變更要 drizzle-kit；兩個版本要對齊。
- D1 額度照算。免費方案每天 500 萬列讀、10 萬列寫，`select *` 掃全表就是全表的列數，ORM 不會幫你加 WHERE。
- 聚合函式要自己用 `sql` 樣板寫，型別是 unknown，要手動標。
什麼時候不要用它
- 三個查詢的小 Worker：`env.DB.prepare()` 直接寫更短。
- 團隊沒有 TypeScript：型別檢查是它一半的價值，純 JS 用只剩語法糖。
- 資料庫不是 SQLite 系：D1 以外它也支援 Postgres／MySQL，但本站沒驗過。
要換的話
原生 D1 API（小專案）、Kysely（純查詢建構器、沒有 schema 宣告）、Prisma（功能多但在 Workers 上有 WASM 體積問題，見 Next.js＋Prisma 那一列）。
費用、授權、資料政策與維護狀態
你需要注意- ⚠️ 本站只實測了查詢層；drizzle-kit 的遷移產生與套用沒測，那是另一套流程
- D1 的每日列讀寫額度照算，ORM 不會幫你省
- 聚合要用 `sql` 樣板，不是每個函式都包好了
全球行政區界資料庫，涵蓋所有聯合國會員國的省、縣層級邊界，CC BY 4.0，API 直接回 GeoJSON。
💰 Free⚖️ 可商用（須標示出處）🔒 訓練政策未查證📌 活躍（William & Mary geoLab 維護）
不適合以為邊界代表官方立場（它明說是彙整不是政治表態）、需要村里級的細緻邊界、不願意標示出處的專案（標示是授權條件）
看完整判斷
你需要注意- ⚠️ 標示出處是授權條件不是禮貌，漏標等於沒授權
- 各國的行政層級定義不同，ADM1 在甲國是省、在乙國可能是州
- 邊界來源逐國不同，精度不一致
全球地名資料庫：2,500 萬個地名、1,200 萬個獨立地物，含座標、人口、行政層級與多語別名，CC BY 授權。
💰 Free⚖️ 可商用（須標示出處）🔒 訓練政策未查證📌 活躍（GeoNames 營運）
不適合門牌級的地址解析（那是地理編碼服務的事）、高頻商業查詢直接打公用 API（有限流）、不標示出處的專案
看完整判斷
你需要注意- ⚠️ 公用 API 有每日限額，正式用途要下載資料庫自架
- 地名品質逐國不同，小地方可能缺漏或重複
- 同名地點很多，配對要加上國家與行政區條件
由 Meta、Microsoft、Amazon、TomTom 等組成的開放地圖基金會出品：地點、建物、道路、行政區與地址，以 Parquet 格式整批釋出。
💰 Free⚖️ ⚠️ 可商用但逐主題授權不同🔒 訓練政策未查證📌 活躍（Overture Maps Foundation，Linux 基金會旗下）
不適合前端直接讀（檔案是資料工程格式，不是 API）、只要幾個點的小專案（殺雞用牛刀）、沒看清楚各主題授權就整批商用
看完整判斷
你需要注意- ⚠️ 不同主題不同授權，ODbL 的主題有同授權義務
- Parquet 檔案巨大，要用 DuckDB 或雲端查詢，不能直接開
- 出處標示要逐主題寫，官方頁列了很長一串
美國地質調查所的全球地震資料：即時 GeoJSON 摘要（過去一小時／一天／一週／一月）與歷史查詢 API，美國公眾領域。
💰 Free⚖️ 可商用🔒 訓練政策未查證📌 活躍（美國地質調查所營運）
不適合取代官方防災警報（它不是台灣的官方發布單位）、需要台灣本地最快速報（那是氣象署）、以為每筆規模都是最終值（初判會被修正）
看完整判斷
你需要注意- ⚠️ 它是資料來源不是警報系統，防災決策要看當地官方
- 初判規模與位置會被後續修正，快取太久會顯示舊值
- 網站上的照片與插圖不一定是公眾領域
NASA 地球科學資料的總入口：衛星影像、大氣、海洋、陸地、植生等數千個資料集，免費但要註冊帳號。
💰 Free⚖️ 可商用🔒 訓練政策未查證📌 活躍（NASA 營運）
不適合不想註冊帳號的專案、只要一張好看的衛星圖（資料是科學格式不是圖片）、沒有資料處理能力的團隊（檔案大、格式專業）
看完整判斷
你需要注意- ⚠️ 要註冊帳號，自動化程式要處理登入
- 檔案格式專業（HDF、NetCDF），要專門工具讀
- 資料集數千個，找對的那一個本身就是門檻
開放的學術文獻資料庫：論文、作者、機構、期刊與引用關係，3 億筆以上，免金鑰 API，資料 CC0。
💰 Free⚖️ 可商用🔒 訓練政策未查證📌 活躍（OurResearch 非營利組織營運）
不適合取得論文全文（它給的是中繼資料與連結）、以為每筆中繼資料都正確（自動彙整會有錯）、高頻查詢不帶聯絡信箱（官方請你標示自己）
看完整判斷
你需要注意- 只有中繼資料與連結，沒有全文
- 自動彙整的作者與機構對應會有錯配
- ⚠️ 官網首頁對程式回 403、說明中心需 JavaScript，查證要走 API 與官方文件庫
- 整批下載的快照很大，要有儲存與處理能力