把 OpenAI 模型能力接進自家系統的介面，按使用量計費；也提供 Embedding 等非對話用途。
💰 API 計費⚖️ 可商用🔒 預設不用於訓練📌 活躍（OpenAI 官方營運）
不適合資料完全不能離開公司、需要離線運作、沒有工程資源的團隊
看完整判斷
你需要注意- 需要工程資源串接與維護
- 按量計費，長文件與大量請求成本累積快
- 模型會改版，同一段 prompt 行為可能改變
用一個 API 存取數百個不同供應商的模型，不必為每家各接一次。
💰 API 計費⚖️ ⚠️ 依你用的那個模型而定🔒 訓練政策未查證📌 活躍（OpenRouter 官方營運）
不適合對資料流向要求極嚴的場合（多一層中介）、不需要多模型的單純應用
看完整判斷
你需要注意- ⚠️ 資料會經過中介平台再轉給實際的模型供應商，等於多一層信任
- 官方入門文件未交代資料政策，要另外查
- 各模型的可用性與價格會變動
在自己電腦上跑開源模型的工具。官方訴求是本機執行的內容不會離開你的機器。
💰 Freemium⚖️ ⚠️ 依個別模型而定🔒 本機執行時資料不離開你的機器📌 活躍（Ollama 官方維護）
不適合硬體不足的機器、需要最強模型能力的正式服務、不懂技術的一般使用者
看完整判斷
你需要注意- 本機模型能力通常明顯不如最新雲端大模型
- 吃硬體，筆電跑大模型會很慢
- ⚠️ 模型授權要個別確認
把大型語言模型服務化的高效能推論框架，源自 UC Berkeley，現由社群維護。
💰 Free⚖️ 可商用🔒 自架不上傳，資料留在自己的環境📌 活躍（社群與多家機構共同維護）
不適合只是想試玩模型的階段（用桌面工具就好）、沒有維運人力的團隊
看完整判斷
你需要注意- 要有 GPU 與會維運的人
- 模型本身的授權要另外確認
- 調校參數對吞吐與延遲影響大，要實測
開放 AI 模型與資料集的平台，官方說明託管超過 200 萬個模型、150 萬個資料集與 150 萬個應用。
💰 Freemium⚖️ ⚠️ 依個別模型而定🔒 訓練政策未查證📌 活躍（Hugging Face 官方營運）
不適合不懂技術的一般使用者直接使用、把它當成單一 AI 產品
看完整判斷
你需要注意- ⚠️ 每個模型授權不同，不能一概而論
- 模型品質參差，公開不等於可用於正式環境
- 需要工程能力才能實際使用
在終端機裡跟 AI 結對寫程式的開源工具，會直接改檔案並自動 git commit。
💰 Free⚖️ 可商用🔒 依你選用的模型供應商而定📌 活躍（Aider-AI 維護）
不適合完全不熟 git 的人（它的安全網就是 git）、不想讓 AI 直接動檔案的場合
看完整判斷
你需要注意- ⚠️ 會直接改你的檔案並 commit，用前確認 git 狀態乾淨
- 要自備 API 金鑰，用量就是錢
- 程式碼會送到你選的模型供應商
在 IDE 裡跑的開源 AI 編碼代理，能讀專案結構、跨檔案改碼、執行指令，有 Plan／Act 兩種模式。
💰 Free⚖️ 可商用🔒 依你選用的模型供應商而定📌 活躍（Cline 官方維護）
不適合不想讓 AI 執行指令的環境、沒有版本控制的專案
看完整判斷
你需要注意- ⚠️ Act 模式會執行指令，要看清楚再放行
- 要自備 API 金鑰，用量就是錢
- 程式碼會送到你選的模型供應商
阿里巴巴的開源大型語言模型系列，權重採 Apache-2.0，是商用授權最單純的選擇之一。
💰 Free⚖️ 可商用🔒 自架不上傳，資料留在自己的機器📌 活躍（阿里巴巴 Qwen 團隊維護）
不適合沒有 GPU 或推論預算的團隊、需要最前沿推理能力的場合（仍以閉源旗艦為主）
看完整判斷
你需要注意- 要有 GPU 與會維運的人
- 小尺寸模型能力明顯不如旗艦閉源模型
- 中文以外語言的表現要自己實測
Meta 的開放權重模型系列，生態最大，但**授權是自訂條款不是標準開源**，有三條硬性商用義務。
💰 Free⚖️ ⚠️ 可商用但有三條硬性義務🔒 自架不上傳，資料留在自己的機器📌 活躍（Meta 官方維護）
不適合⚠️ 月活躍使用者超過 7 億又沒申請授權的公司、不想在產品上標示「Built with Llama」的場合、衍生模型不想被要求以 Llama 命名的情況
看完整判斷
你需要注意- ⚠️ 三條商用義務常被忽略，產品上線前要逐條確認
- 要有 GPU 與維運人力
- 授權條款各版本略有差異，要看你用的那一版
Google 的開放權重模型系列，輕量、可在較小硬體上跑，但採自訂使用條款而非 OSI 開源授權。
💰 Free⚖️ ⚠️ 自訂條款，非 OSI 開源🔒 自架不上傳，資料留在自己的機器📌 活躍（Google 官方維護）
不適合⚠️ 不想受禁用政策與下游傳遞義務約束的產品、需要標準開源授權以簡化法遵的場合
看完整判斷
你需要注意- ⚠️ 不是標準開源授權，法遵流程要另外處理
- ⚠️ Google 保留遠端限制使用的權利
- 各世代授權不同，要確認你用的版本
向量資料庫：專門存放「意思的數值表示」並快速找出相似項目，是語意搜尋與 RAG 的儲存層。
💰 Freemium⚖️ 可商用🔒 自架不上傳，資料留在自己的伺服器📌 活躍（Qdrant 官方維護）
不適合資料量小的場合（用 pgvector 或檔案就夠）、沒有工程人力的團隊
看完整判斷
你需要注意- 要有人維運（備份、擴容、升級）
- 向量品質取決於你用的嵌入模型，資料庫本身不負責準確度
- 小規模場景是過度設計
讓現有的 PostgreSQL 直接做向量相似搜尋的擴充套件——**不用另外架一套向量資料庫**。
💰 Free⚖️ 可商用🔒 自架不上傳，資料留在自己的資料庫📌 活躍（作者持續維護）
不適合超大規模、對延遲極敏感的向量檢索、沒有在用 PostgreSQL 的環境
看完整判斷
你需要注意- 極大規模時效能不如專用向量資料庫
- 要會 PostgreSQL 運維
- 索引參數調校會明顯影響查詢速度與準確度
把自己的資料接給 LLM 的開發框架：資料連接、索引、查詢一整套，是做 RAG 最常見的骨架之一。
💰 Free⚖️ 可商用🔒 依你選用的模型供應商而定📌 活躍（LlamaIndex 官方維護）
不適合不寫程式的使用者（那用 NotebookLM 這類現成服務）、只有幾份文件的簡單需求
看完整判斷
你需要注意- 它是框架不是模型，還要自己選模型與向量庫
- 版本更新快，API 會變
- RAG 的品質主要取決於資料整理，不是框架
產生 Embedding（把文字變成可比較的數值）與重排序的標準函式庫，官方說明可用超過 15,000 個現成模型。
💰 Free⚖️ 可商用🔒 自架不上傳，資料留在自己的機器📌 活躍（UKPLab 維護）
不適合直接回答問題（那是 LLM 的工作）、沒有工程人力的團隊
看完整判斷
你需要注意- ⚠️ 函式庫授權與模型授權是兩件事
- 中文任務要挑對模型，通用英文模型效果會差很多
- 需要工程人力
LLM 應用的觀測平台：把每一次呼叫的輸入輸出、成本、延遲記錄下來，並支援提示詞版本管理與評估。
💰 Freemium⚖️ 核心可商用（MIT）🔒 自架不上傳，資料留在自己的伺服器📌 活躍（Langfuse 官方維護）
不適合還在原型階段的專案、沒有工程人力的團隊
看完整判斷
你需要注意- ⚠️ 追蹤紀錄會存下使用者的輸入內容，本身就是要保護的資料
- 核心與企業版授權不同
- 自架要有人維運
自架的 AI 對話介面，可接 Ollama 本機模型或 OpenAI 相容 API，能完全離線運作。
💰 Free⚖️ ⚠️ 自訂授權，且要求保留品牌🔒 自架不上傳（取決於你接的模型）📌 活躍（Open WebUI 官方維護）
不適合⚠️ 想移除品牌標示的商業部署、沒有維運人力的團隊
看完整判斷
你需要注意- ⚠️ 授權要求保留品牌，白牌部署要先確認
- ⚠️ 授權變更過，要看 LICENSE_HISTORY 對應版本
- 自架要有人維運與更新
最普及的監控與儀表板工具，可接各種資料源做即時視覺化與告警。
💰 Freemium⚖️ ⚠️ AGPL-3.0🔒 自架不上傳，資料留在自己的伺服器📌 活躍（Grafana Labs 官方維護）
不適合⚠️ 要嵌進對外商業產品又沒評估授權的情況、純粹做商業分析報表（BI 工具更合適）
看完整判斷
你需要注意- ⚠️ AGPL-3.0，商業嵌入要先評估
- 自架要有人維運
- 儀表板做得多之後，維護成本比想像高
可自架的聚合搜尋引擎：把多家搜尋結果合併呈現，且不追蹤、不側寫使用者。
💰 Free⚖️ ⚠️ AGPL-3.0🔒 自架不上傳，查詢留在自己的伺服器📌 活躍（SearXNG 社群維護）
不適合⚠️ 對外商業服務又沒評估 AGPL、需要穩定商業支援的關鍵應用
看完整判斷
你需要注意- ⚠️ AGPL-3.0
- 上游搜尋服務可能限流或擋，需要維護
- 結果品質取決於所聚合的來源
持久化工作流引擎：讓跨越數天、會失敗、要重試的流程能可靠地跑完，狀態不會因為重啟而遺失。
💰 Free⚖️ 可商用🔒 自架不上傳，資料留在自己的伺服器📌 活躍（Temporal Technologies 維護）
不適合簡單的定時任務（cron 就夠）、沒有工程人力的團隊、只是要串兩個 SaaS（Zapier 類更快）
看完整判斷
你需要注意- 概念門檻高（workflow／activity／determinism），學習曲線陡
- 自架要維運資料庫與叢集
- 小規模需求是過度設計
做 AI Agent 的編排框架：支援持久化執行、狀態記憶、以及在流程中插入人工確認。
💰 Free⚖️ 可商用🔒 依你選用的模型供應商而定📌 活躍（LangChain 官方維護）
不適合單次問答就結束的需求（直接呼叫模型就好）、不寫程式的團隊、還沒試過寫死流程（Workflow）就想上 Agent
看完整判斷
你需要注意- ⚠️ Agent 難以驗收——先確認寫死的流程真的做不到再上
- 版本更新快
- 除錯需要搭配追蹤工具才看得清楚
多 Agent 協作框架：用角色分工的方式讓多個 AI 代理人一起完成任務，也支援事件驅動的固定流程。
💰 Free⚖️ 可商用🔒 依你選用的模型供應商而定📌 活躍（CrewAI 官方維護）
不適合單一 Agent 就能做完的任務（多開只會更難驗收）、對輸出穩定性要求高的正式流程
看完整判斷
你需要注意- ⚠️ 多 Agent 的成本與不可預測性都是倍增的，先確認單一 Agent 真的不夠
- Agent 之間的交接容易累積誤差
- 驗收設計比開發更花時間
設計成「最容易開始」的向量資料庫，可以嵌在程式裡跑，也能當伺服器用。
💰 Freemium⚖️ 可商用🔒 本機或自架時資料不外傳📌 活躍（Chroma 官方維護）
不適合超大規模、高併發的正式環境、已經在用 PostgreSQL 又不想多一套系統（用 pgvector）
看完整判斷
你需要注意- 大規模場景的效能與運維成熟度不如專用向量資料庫
- 自動處理嵌入很方便，但也讓人忽略嵌入模型的選擇
- 資料備份與遷移要自己規劃
視覺化的 LLM 應用開發平台：工作流、RAG 管線、Agent、模型管理與觀測一整套，可自架。
💰 Freemium⚖️ ⚠️ 可商用但有兩條硬性限制🔒 自架不上傳（取決於你接的模型）📌 活躍（LangGenius 官方維護）
你會在什麼情況下想到它要做一個「查得到出處」的問答機器人，而你不想從向量庫、切塊、檢索、prompt 組裝一路自己寫。
怎麼用（最短路徑）
- 自架或用雲端版，建一個 workspace（＝一個 tenant，這個詞等一下會咬人）。
- 知識庫丟文件，它幫你切塊建索引；切塊大小與重疊可調，這是後面答不答得準的關鍵。
- 建一個 Chat App 掛上知識庫，prompt 裡把「答不出來就說不知道、並附出處」寫死。
- 拿 API Key 打 /chat-messages，blocking 或 streaming 兩種模式擇一。
- 前面接你自己的管道：LINE、Teams、網頁 widget。
真實案例：產銷履歷法規諮詢 LINE 客服服務約 6,000 位農民本站作者實作
LINE Webhook → Cloudflare Workers 中繼層 → Dify /chat-messages → LINE Reply API
為什麼不讓 LINE 直接打 Dify？中間那層 Worker 看起來多餘，但它做四件 Dify 不會幫你做的事。這是整個案子最值錢的一個決定。
- 驗簽LINE 的 x-line-signature 要用 channel secret 做 HMAC-SHA256 驗證，失敗回 401。沒有這層，任何人都能對你的 endpoint 灌訊息，每一則都燒你的 token。
- 群組防洗版Bot 拉進農民群組後，每句閒聊都會觸發。規則設成只有 @提及，或 #問／#／？／? 開頭才回應。
- 非文字訊息直接丟掉貼圖、照片、位置不進 Dify，不消耗額度。
- 逾時防呆LINE 的 reply token 有時效。Dify 慢了要回一句友善的預設訊息，不能讓農民看到空白。
踩坑
- 授權不是 Apache。官方 LICENSE 兩條硬限制：未經書面授權不得用原始碼經營多租戶環境（官方定義「一個 tenant 對應一個 workspace」），以及不得移除或修改 console 與應用前端的 LOGO 與著作權資訊（原始碼的 web/ 目錄，或 Docker 的 web image）。
- 「幫三個客戶各開一個 workspace」就是多租戶。顧問最常用的交付方式，正好踩在這條上——這是授權問題，不是技術問題。
- 答不準，先回頭調切塊與檢索，不要急著換模型。切塊大小、重疊、取幾段才是主要變因；換更貴的模型通常只是變貴。
- blocking 模式的逾時要自己抓。平台不會替你處理下游（LINE、Teams）的時限。
什麼時候不要用它
- 只有 20 題 FAQ：直接塞進 prompt，不需要向量庫，也不需要平台。
- 要白牌交付給客戶：先把商業授權的錢算進報價再決定。
- 已經有 n8n 或 Make 在跑，而且只是要串一支 API：那段用既有平台就好。
要換的話
RAGFlow（切塊與文件解析更細）、AnythingLLM（更輕、更快上手），或完全不要平台——自己寫檢索直接接模型 API，像上面那個案子的中繼層一樣。
費用、授權、資料政策與維護狀態
你需要注意- ⚠️ 多租戶與品牌兩條限制是自架公司最容易違反的
- 自架要有人維運（Docker、資料庫、升級）
- 版本更新快，升級前要看遷移說明
視覺化拖拉建 AI Agent 流程的工具。⚠️ 官方 repo 已於 2026-08-13 封存。
💰 Free⚖️ 可商用🔒 自架不上傳（取決於你接的模型）📌 已封存
不適合⚠️ 新專案（上游已封存，不宜當長期基礎）、需要持續安全更新的正式環境
看完整判斷
你需要注意- ⚠️ **官方 repo 已於 2026-08-13 封存**，後續發展要看官方公告
- 新專案建議改用仍在維護的替代方案
- 封存後的安全性更新不可期待
自架軟體與網路服務的權威清單：想把服務放在自己伺服器上時，先來這裡找有什麼選擇。
💰 Free⚖️ ⚠️ 依個別軟體而定🔒 訓練政策未查證📌 活躍（社群持續維護，官方另有網站版）
不適合⚠️ 當成產品目錄直接照用（它是清單不是評測）、沒有維運能力的團隊——自架的成本在人不在授權費
看完整判斷
你需要注意- ⚠️ 它是清單不是評測，收錄不等於推薦
- 上面的專案品質與維護狀態差異極大，要自己再查一輪
- 自架的真正成本是維運人力
Model Context Protocol 的官方參考伺服器：讓 AI 助理能安全地存取檔案、Git、記憶體等外部工具與資料。
💰 Free⚖️ 可商用🔒 視你接的 AI 服務而定📌 活躍（由 MCP steering group 維護；已封存的伺服器另移他處）
不適合⚠️ 直接拿參考實作上正式環境（官方明說是教育用途）、不寫程式的使用者
看完整判斷
你需要注意- ⚠️ 官方明示這些是參考實作、供教學用，不是 production-ready
- ⚠️ 給 AI 檔案系統存取權限本身就是風險，範圍要收窄
- 社群伺服器品質參差，要個別評估
Anthropic 官方公開的 Agent Skills 範例集：把「怎麼做某件事」寫成 Claude 可以動態載入的資料夾。
💰 Free⚖️ ⚠️ 依個別 skill 而定🔒 訓練政策未查證📌 活躍（Anthropic 官方維護）
不適合⚠️ 未經測試就用在關鍵任務（官方明示為示範與教育用途）、不熟 AI 工具的一般使用者
看完整判斷
你需要注意- ⚠️ 官方免責：僅供示範與教育，實作可能與 Claude 內建行為不同，關鍵任務前要自行充分測試
- ⚠️ 文件類 skill 非開源授權
- Skill 的效果取決於你寫得多清楚，不是複製就會變強
靜態網站與 PWA 的免費託管：把一個資料夾推上去就有網址與 HTTPS。本站與 17 支作品都放這裡。
💰 Freemium⚖️ 商用權利未查證🔒 訓練政策未查證📌 活躍（Cloudflare 官方營運）
不適合需要資料庫或後端邏輯的應用（那是 Workers 的事）、拿狀態碼判斷檔案存不存在的自動化（不存在的路徑可能回 200）、沒清乾淨的專案資料夾（整包上傳等於整包公開）
看完整判斷
你需要注意- ⚠️ 不存在的路徑可能回 200＋首頁（SPA 回退），用狀態碼驗檔案在不在會被騙
- 整個資料夾部署就整個公開，開發檔要先清掉再上傳
- 刪掉部署後邊緣快取仍可能餵舊檔一陣子，驗證要帶 cache-buster
- 免費方案每月 500 次建置，CI 一直推很快用完
在邊緣節點跑後端程式的無伺服器平台，配 KV 鍵值庫與 D1 SQL 資料庫。本站需要後端的作品（代理外部 API、排程寫資料）都跑這裡。
💰 Freemium⚖️ 商用權利未查證🔒 訓練政策未查證📌 活躍（Cloudflare 官方營運）
不適合每天寫入量大的資料服務（免費 D1 每天 100,000 列寫入）、重運算（免費方案每次請求 CPU 只有 10 ms）、直接搬 Node 程式上來不改（執行環境不是 Node）
看完整判斷
你需要注意- ⚠️ 額度是每天算的，資料量一大就是長期工程
- 執行環境不是 Node，本機測過不等於線上會跑
- 免費 D1 單庫 500 MB，超過要付費
- KV 同一個鍵每秒只能寫 1 次
輕量的網頁地圖程式庫（官網自述約 42 KB），配 OpenStreetMap 圖磚就能免金鑰畫地圖。本站 14 支作品的地圖都是它。
💰 Free⚖️ 可商用🔒 訓練政策未查證📌 活躍（Volodymyr Agafonkin 與社群維護）
不適合3D 或大量向量圖層的視覺化、需要離線地圖卻不想自己做快取、以為裝了它就有地圖：圖磚與資料是另外的來源
看完整判斷
你需要注意- 它只負責畫，圖磚是別人的伺服器，流量大要換來源
- 離線要自己快取，做不到就老實標「需要網路」
- 2.0 仍是 alpha（官網 2025-08 公告），正式專案先留在 1.x
全球開放地圖資料庫，附三種免費取用管道：圖磚、地址與座標查詢（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 登錄頁原文）
純前端的全文搜尋程式庫：幾百到幾萬筆資料在瀏覽器裡建索引、模糊比對、前綴搜尋，不用後端。
💰 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 物件，不是純字串
Google 出的 Service Worker 工具組：自動列出要預快取的檔案、算內容雜湊、管理快取策略，PWA 的離線與更新不用手寫。
💰 Free⚖️ 可商用🔒 訓練政策未查證📌 活躍（Google Chrome 團隊維護）
你會在什麼情況下想到它你的 PWA 有十幾個檔，每次改一個就要記得升 sw.js 裡的 CACHE 版號，忘了一次使用者就卡在舊版。
怎麼用（最短路徑）
- `npm i -D workbox-build`，寫一支 `build-sw.mjs` 呼叫 `generateSW({ globDirectory, globPatterns, swDest })`。
- 它掃目錄、對每個檔算內容雜湊寫進 sw.js——檔案內容變，雜湊就變，不用手動升版。
- `skipWaiting: false` 保留「等待＋橫幅＋SKIP_WAITING 訊息」那套更新流程；設 true 就是改完立刻換。
- 外部資源（地圖圖磚、字型）用 `runtimeCaching` 設 CacheFirst 加上 `expiration`。
- 把 `build-sw` 接進部署指令，跟 staging 清洗一起跑。
真實案例：米其林指南 App 的 sw.js 改成自動產9 個檔、543 KB本站作者實作（最小落地，2026-09-19）
index.html＋restaurants.json＋icons → workbox-build generateSW → sw.js＋workbox 執行期檔
為什麼保留 skipWaiting: false？因為家族的更新機制是「等待、顯示橫幅、使用者按了才切換」。自動產 sw 不該偷偷改掉這個行為。
- 產出8 個預快取項目、543,238 bytes，排掉 og 分享圖；產生耗時 2,151 ms。
- 檔案sw.js 只有 1,588 bytes，另外多一個 workbox-e190f46a.js 執行期檔——這個檔要一起部署，漏了 sw 就掛。
- 版號每個項目帶 32 字元內容雜湊，改 restaurants.json 重跑就自動變；原本手寫的 2,635 bytes sw.js 裡那個 CACHE 版號從此不用人記。
- 圖磚OSM 圖磚設 CacheFirst、最多 200 張、7 天——只快取使用者實際看過的，符合 OSM 圖磚政策；預抓是被禁止的。
踩坑
- 執行期檔要一起出貨。generateSW 預設用 importScripts 載入 workbox-<hash>.js，只上傳 sw.js 會靜默失敗。要單檔就設 `inlineWorkboxRuntime: true`。
- 它接管更新流程。skipWaiting 與 clientsClaim 兩個旗標決定使用者何時看到新版，接進既有橫幅機制前先確認這兩個值。
- 預快取超過 2 MB 的檔會被跳過並警告，大資料檔要改 runtime 快取或提高上限。
什麼時候不要用它
- 三、五個檔的單檔 App：手寫 30 行 sw.js 更清楚，也不用加建置步驟。
- 沒有 Node 建置流程的專案：它是建置工具，沒地方跑。
- 要精細控制每個請求的快取邏輯：直接寫 Service Worker。
要換的話
vite-plugin-pwa（用 Vite 的專案，底層就是 Workbox）、手寫 sw.js（本站 17 支 Pages 作品目前都是這樣，用了才知道要不要換）。
費用、授權、資料政策與維護狀態
你需要注意- ⚠️ 產出的 sw.js 旁邊還有一個 workbox-<hash>.js 執行期檔，要一起出貨
- 預快取上限預設 2 MB，大檔要明說或改 runtime 快取
- 快取外部圖磚要遵守對方的使用政策（OSM 只准快取使用者看過的）
跑在 Cloudflare Workers、Deno、Bun、Node 上的輕量 Web 框架：路由、JSON、中介層幾行搞定，用的是 Web 標準的 Request／Response。
💰 Free⚖️ 可商用🔒 訓練政策未查證📌 活躍（Yusuke Wada 與社群維護）
你會在什麼情況下想到它健康家族那種一支 Worker 塞八個小 App、或農漁產行情那種要開幾個查詢端點的後端，原生 `fetch(request)` 裡的 if/else 已經長到看不懂。
怎麼用（最短路徑）
- `npm i hono`，`const app = new Hono()`，`app.get('/x/:id', c => c.json(...))`，`export default app`——wrangler 直接認得。
- 路徑參數 `c.req.param('id')`、JSON body `await c.req.json()`、環境綁定 `c.env.DB`。
- `app.notFound()` 與 `app.onError()` 一開始就寫，不要讓 Workers 回預設的空白錯誤。
- 本機 `wrangler dev --local` 起來，用 Node 的 `fetch` 寫測試腳本打它。
真實案例：一支 Worker：三個端點加 404，接本機 D14 個路由、含 GROUP BY 彙總本站作者實作（最小落地，2026-09-19）
Hono → drizzle-orm/d1 → wrangler dev --local 的 D1
為什麼測試腳本改用 Node fetch，不用 curl？因為 curl 在 Windows 的 Git Bash 下會把中文參數轉成 ANSI 碼頁送出，資料寫進資料庫就是亂碼——這不是 Hono 的錯，但你會先怪它。
- 路由GET /health、POST /prices、GET /prices/:item、GET /stats 加 notFound，全部各回對應狀態碼（201／200／404）。
- 中文參數用 Node fetch 打 `/prices/青江菜` 與 `/prices/%E9%9D%92…` 兩種寫法，`c.req.param()` 都回「青江菜」、查到 2 筆——原生就解碼，不用自己 decodeURIComponent。
- 假警報同一個端點用 Git Bash 的 curl 送「高麗菜」，寫進 D1 的是 CP950 亂碼，查詢當然 0 筆。花了一輪才確認是殼層，不是框架。
- 啟動wrangler dev 幾秒內 Ready，之後每個請求在本機都是毫秒級。
踩坑
- Windows 殼層會污染中文測試。Git Bash 呼叫原生 exe 時中文參數走 ANSI 碼頁；測試一律用 Node 腳本或檔案輸入，不要在命令列打中文。
- 中介層順序就是執行順序。驗簽、CORS 要註冊在路由之前，寫在後面等於沒寫。
- `export default app` 之後 wrangler 的 scheduled（排程）handler 要另外掛，Hono 只接 fetch。
什麼時候不要用它
- 只有一個端點：原生 fetch handler 更短。
- 要 Session、樣板、完整後端：那是 Next.js／Remix 那一層的事，Hono 是路由層。
- 不是跑在 Web 標準執行環境（例如老的 Express 專案）：沒有換的理由。
要換的話
itty-router（更小、更少功能）、原生 fetch handler（單端點）、Cloudflare 自家的 Pages Functions（檔案即路由，適合放在 Pages 專案裡）。
費用、授權、資料政策與維護狀態
你需要注意- 路由靠字串比對，路徑設計要先想好
- 中介層順序決定行為，驗簽要放最前面
- 在 Windows 用 Git Bash 的 curl 測中文會被殼層轉成 ANSI 碼頁，看起來像框架的錯
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` 樣板，不是每個函式都包好了
IndexedDB 的封裝：一行宣告 schema，`where().equals()` 查索引、`bulkAdd` 批次寫入、直接存 Blob，離線 App 的本地資料庫。
💰 Free⚖️ 可商用🔒 訓練政策未查證📌 活躍（David Fahlander 與社群維護）
你會在什麼情況下想到它錯題管理器那種要在手機上存幾千題、每題帶一張圖、還要依科目與答對次數查的 App，手寫 IndexedDB 的 transaction 與 cursor 已經寫到懷疑人生。
怎麼用（最短路徑）
- `npm i dexie`；`db.version(1).stores({ mistakes: '++id, subject, [subject+streak], createdAt' })`——只列要索引的欄位，其他欄位照存。
- 寫入 `bulkAdd(rows)`；Blob 直接放在物件裡，不用轉 base64。
- 查詢 `where('[subject+streak]').equals(['數學', 3])`、`where('subject').equals('英文').reverse().sortBy('createdAt')`。
- 改 schema 就 `version(2).stores({...})` 加 `upgrade()`，舊的 version 宣告要留著。
- 測試在真瀏覽器跑：Playwright 開一個本機頁面呼叫這些函式。
真實案例：錯題管理器的資料模型在真 Chrome 上壓測1,000 題、每題 4 KB 圖片 Blob本站作者實作（最小落地，2026-09-19）
Dexie 4.4.6 → 本機 http 頁面 → Playwright 驅動已安裝的 Chrome 153
為什麼堅持在真瀏覽器測，不用 Node 的假 IndexedDB？因為測試環境的容忍度跟執行環境不同，本機綠燈會說謊——這個站已經為此付過學費。
- 寫入1,000 筆含 Blob `bulkAdd` 283 ms。
- 複合索引`[subject+streak]` 查「數學、連對 3 次」count 0.9 ms，84 筆。
- 索引＋排序科目「英文」333 筆依建立時間反排 10.6 ms。
- Blob取第 500 筆，`image instanceof Blob` 且 size 4,096 一致；storage 用量 5,111,808 bytes。
踩坑
- version 號只能往上。改了 `stores()` 沒升版，開庫就拋錯；升了版但砍掉舊 version 宣告，舊使用者的資料會遷移失敗。
- Node 測不到。Node 沒有 IndexedDB，裝假實作能讓測試綠，但 Blob、配額、瀏覽器清資料這些行為都不在假實作裡。
- 複合索引要在 `stores()` 宣告 `[a+b]` 才能用，事後查會直接拋錯，不是回空。
什麼時候不要用它
- 幾個鍵值的設定：localStorage。
- 資料要跨裝置：先想同步層，本地庫只是快取。
- 資料量到十萬筆以上還要複雜查詢：考慮 sql.js 或 DuckDB-wasm。
要換的話
idb（更薄，只是 Promise 化的 IndexedDB）、localForage（key-value 抽象、API 最簡單）、直接寫 IndexedDB（本站錯題管理器目前就是這樣，1 支作品）。
費用、授權、資料政策與維護狀態
你需要注意- ⚠️ 改 `stores()` 定義必須升 version 號，否則開庫直接拋錯
- Node 沒有 IndexedDB，用假實作跑的測試不等於瀏覽器會過
- 瀏覽器可能在空間不足時清掉資料，重要的東西要能重建或匯出
微軟出的瀏覽器自動化：用程式開真的 Chrome／Firefox／WebKit，設手機視窗、量 DOM、截圖、跑端對端測試，可以直接用機器上已裝的 Chrome。
💰 Free⚖️ 可商用🔒 訓練政策未查證📌 活躍（Microsoft 維護）
你會在什麼情況下想到它你用 headless Chrome 加手工 CDP 輪詢做截圖驗證，發現 window-size 小於 504 會被夾住、virtual-time 會讓每次失敗在不同項目——想要一個不用自己修的驅動層。
怎麼用（最短路徑）
- `npm i playwright`；不想下載瀏覽器就 `chromium.launch({ channel: 'chrome' })` 用機器上的 Chrome。
- `browser.newPage({ viewport: { width: 390, height: 844 }, deviceScaleFactor: 2 })`——視窗寬度是真的 390，不會被夾。
- `page.goto(url, { waitUntil: 'networkidle' })`，然後 `page.evaluate()` 量 `scrollWidth` 與 `clientWidth`。
- `page.screenshot()` 留證據，但斷言要寫在 DOM 數字上。
- 本機頁面用 `python -m http.server` 起一個埠，`file://` 下 IndexedDB 與 fetch 行為不一樣。
真實案例：找工具頁在手機寬度的自動體檢1 個線上頁、99 張卡本站作者實作（最小落地，2026-09-19）
Playwright channel: 'chrome' → Chrome 153 → ridgeline-lab.com/tools/
為什麼用 channel: 'chrome' 而不下載 Playwright 自己的 Chromium？因為這台機器已經有 Chrome，而且使用者用的也是 Chrome；少下載幾百 MB，測的還是真正會被用的那個瀏覽器。
- 啟動274 ms 起 Chrome 153.0.8010.52，沒有下載任何東西。
- 手機寬度viewport 390 實際生效：`clientWidth` 390、`scrollWidth` 390，沒有橫向捲動——之前用 window-size 參數會被夾到 504。
- 內容networkidle 4,432 ms 後 DOM 裡有 99 張 `article.tool`、21 張 `.scard`，跟建置輸出一致。
- 順手同一個瀏覽器實例先跑完 Dexie 的 IndexedDB 壓測再來量這頁，兩件事一支腳本。
踩坑
- 截圖會騙人，DOM 不會。截圖只證明「看起來對」，橫向捲動要量 `scrollWidth > clientWidth`。
- networkidle 不等於載完。有 analytics 或長輪詢的頁面它會等到逾時；改等特定元素出現。
- `file://` 頁面的 IndexedDB、fetch、Service Worker 行為跟 http 不同，測本機頁一律起一個 http 伺服器。
什麼時候不要用它
- 單元測試邏輯函式：不需要瀏覽器。
- 只是想看一眼：手動開 DevTools 更快。
- 要爬有反機器人的網站：那是另一個問題，工具再好也過不去。
要換的話
Puppeteer（只驅動 Chrome、API 相近）、手工 CDP（本站之前的做法，坑很多）、Cypress（偏向前端開發者的測試框架）。
費用、授權、資料政策與維護狀態
你需要注意- 預設會下載三套瀏覽器（幾百 MB），用 `channel: 'chrome'` 可以直接用已裝的 Chrome
- `networkidle` 在有長輪詢的頁面會等很久
- 截圖不是驗證，量 DOM 才是；兩個都要
全球行政區界資料庫，涵蓋所有聯合國會員國的省、縣層級邊界，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⚖️ 可商用🔒 訓練政策未查證📌 活躍（美國地質調查所營運）
不適合取代官方防災警報（它不是台灣的官方發布單位）、需要台灣本地最快速報（那是氣象署）、以為每筆規模都是最終值（初判會被修正）
看完整判斷
你需要注意- ⚠️ 它是資料來源不是警報系統，防災決策要看當地官方
- 初判規模與位置會被後續修正，快取太久會顯示舊值
- 網站上的照片與插圖不一定是公眾領域
各語言與地區的在地化資料：國名、語言名、貨幣、日期與數字格式、時區顯示名，是幾乎所有作業系統與程式語言在地化的底層。
💰 Free⚖️ 可商用🔒 訓練政策未查證📌 活躍（Unicode 協會維護）
不適合以為它管時區規則（那是 IANA tz）、直接當資料庫用（多數人是透過程式語言的國際化函式庫間接用）、需要行銷用的國家分類
看完整判斷
你需要注意- 資料龐大且結構複雜，多數情況該用程式語言的國際化 API 而不是自己讀
- 每年改版，顯示字串會變動
- 繁簡與區域變體要指定對，zh-TW 與 zh-Hant 不完全等價
全球各地當地時間的歷史與規則：時區邊界、UTC 偏移、日光節約時間的變更歷史，公眾領域。
💰 Free⚖️ 可商用🔒 訓練政策未查證📌 活躍（IANA 與 tz 社群維護）
不適合把時區當固定不變（各國政治決定會改）、需要時區的地理多邊形（那要另外的資料集）、以為只要存 UTC 就沒事（顯示仍需規則）
看完整判斷
你需要注意- ⚠️ 規則一年改好幾次，系統沒更新就會算錯當地時間
- 歷史資料以「有代表性的地點」為單位，不是每個城市都有自己的條目
- 時區名稱會被淘汰改成別名