把 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 就沒事（顯示仍需規則）
看完整判斷
你需要注意- ⚠️ 規則一年改好幾次，系統沒更新就會算錯當地時間
- 歷史資料以「有代表性的地點」為單位，不是每個城市都有自己的條目
- 時區名稱會被淘汰改成別名
Telegram 官方的機器人 HTTP 介面，免費，用來把系統通知、警示訊息推播給使用者。本站農地衛星監測作品用它推播 NDVI 異常通知。
💰 Free⚖️ 商用權利未查證🔒 訓練政策未查證📌 活躍（Telegram 官方營運）
不適合需要保證送達的關鍵通知（使用者需自行安裝 Telegram 並訂閱）、高頻廣播（免費額度私聊每秒 1 則、群組每分鐘 20 則）、需要官方 SLA 的商用通知服務
看完整判斷
你需要注意- 免費額度有速率上限，高頻通知要走付費廣播
- 使用者必須自行加入該機器人才收得到訊息
- Bot Token 外洩等於帳號被接管，不可寫進前端
開源的 HTML5 canvas 圖表庫，折線／長條／圓餅等常見圖表都內建。本站健康家族 7 支子 App 共用它畫血壓、血糖、生長曲線趨勢圖。
💰 Free⚖️ 可商用🔒 訓練政策未查證📌 活躍（Chart.js 核心團隊與社群維護）
不適合需要高度客製化或特殊圖表型態（雷達圖之外的少見圖型要另找）、大量資料點（十萬級）的即時互動圖、React／Vue 專案想要框架原生元件（可改用 recharts／vue-chartjs 這類封裝）
看完整判斷
瀏覽器端直接產生 PDF 的 JS 庫，不需要後端。本站名片管理 App 用它在使用者裝置上即時輸出名片／履歷 PDF。
💰 Free⚖️ 可商用🔒 訓練政策未查證📌 活躍（社群維護）
不適合複雜排版的正式文件（發票、合約，版面控制較弱）、從既有 PDF 做編輯或合併（那是 pdf-lib 的事）、需要精確字型嵌入與印刷級輸出
看完整判斷
純 JavaScript 的 PDF 建立與編輯庫，可在瀏覽器與 Node 環境操作既有 PDF（填表單、合併、加浮水印）。本站名片管理 App 用來組合／編輯 PDF。
💰 Free⚖️ 可商用🔒 訓練政策未查證📌 ⚠️ 官方倉庫近年更新緩慢，社群有 fork 接手維護，用前先確認目前引用的版本來源
不適合從零產生排版複雜的新文件（那是 jsPDF 較擅長的方向）、掃描件 OCR（那是文件解析工具的事）、印刷級色彩管理
看完整判斷
把一段 DOM 畫面轉成 canvas／圖片的 JS 庫。本站名片管理 App 用它把畫面截成圖片再嵌入分享卡或 PDF。
💰 Free⚖️ 可商用🔒 訓練政策未查證📌 活躍（社群維護，主倉庫更新較慢）
不適合需要像素級精確的截圖（CSS 效果不一定完整還原）、跨網域圖片／字型（CORS 限制常見）、動畫或影片內容
看完整判斷
TypeScript／Node.js 的 ORM，統一操作 PostgreSQL、MySQL、SQLite、D1 等多種資料庫。本站產業災情監測平台、企業風險快篩用它管理資料存取。
💰 Free⚖️ 可商用🔒 訓練政策未查證📌 活躍（Prisma 公司與社群維護）
不適合極簡單只需要幾個 SQL 查詢的小專案（直接寫 SQL 更輕）、非 JS/TS 生態系、需要資料庫最底層效能調校（ORM 有抽象成本）
看完整判斷
TypeScript 優先的 schema 驗證庫：宣告一次 schema，同時拿到執行期驗證與型別推導。本站產業災情監測平台、企業風險快篩用它驗證 API 輸入輸出。
💰 Free⚖️ 可商用🔒 訓練政策未查證📌 活躍（Colin McDonnell 與社群維護）
不適合非 TypeScript／JavaScript 專案、極簡單、不需要驗證的內部資料、效能極敏感的高頻迴圈（驗證有執行期成本）
看完整判斷
把既有網頁／PWA 包裝成 iOS／Android 原生殼層的框架，可存取相機、檔案系統等原生功能。本站一支健康家族子 App 用它包裝成 Android App 上架。
💰 Free⚖️ 可商用🔒 訓練政策未查證📌 活躍（Ionic 團隊與社群維護）
不適合需要極致原生體驗與效能的重度互動 App、沒有網頁版、從零開始的原生專案、不想維護 Xcode／Android Studio 建置環境（仍需要原生工具鏈打包）
看完整判斷
Google 出的無頭瀏覽器自動化庫，用程式控制 Chrome／Firefox：截圖、產生 PDF、自動化測試、爬取需要 JS 渲染的頁面。本站學習計畫日曆用它產生課表 PDF／截圖。
💰 Free⚖️ 可商用🔒 訓練政策未查證📌 活躍（Google Chrome 團隊維護）
不適合靜態 HTML 就能滿足的簡單爬蟲（不需要真瀏覽器開銷）、伺服器資源緊張的環境（無頭瀏覽器吃記憶體）、需要遠端瀏覽器叢集的大規模平行測試（另需自架或用雲端方案）
看完整判斷
計算日出日落時刻、太陽方位、月相與月出月落的輕量 JS 庫，純計算不連外。本站親子釣魚作品用它算潮汐規劃相關的天文時刻。
💰 Free⚖️ 可商用🔒 訓練政策未查證📌 活躍（Volodymyr Agafonkin 與社群維護）
不適合需要高精度天文計算（它是簡化演算法，非天文台等級精度）、潮汐計算（那是另一套海洋資料，SunCalc 不算潮汐）、深空天體或行星位置計算
看完整判斷
用 React 元件宣告式組圖表的庫，底層是 D3。本站企業風險快篩用它畫風險指標圖表。
💰 Free⚖️ 可商用🔒 訓練政策未查證📌 活躍（社群維護）
不適合非 React 專案、極度客製化的視覺化（複雜情況需直接用 D3）、大量資料點的高效能渲染（虛擬 DOM 有開銷）
看完整判斷
Apache 基金會的互動式圖表庫，支援大量資料點、地圖視覺化、3D 圖表。本站商業節能與 MV 平台用它畫能源用電趨勢圖。
💰 Free⚖️ 可商用🔒 訓練政策未查證📌 活躍（Apache 軟體基金會與社群維護）
不適合只需要簡單折線圖的小專案（Chart.js 較輕量）、React／Vue 原生元件風格偏好者（ECharts 是指令式 API，需另包裝）、極簡單、不需要互動的靜態圖
看完整判斷
開源的道路路徑規劃引擎，官方有公開示範伺服器（router.project-osrm.org），也可自架。本站名片管理與旅程紀錄作品用它算兩點間駕車路線。
💰 Free⚖️ 可商用🔒 訓練政策未查證📌 活躍（OSRM 社群維護）
不適合正式產品直接打公開示範伺服器（官方明言僅供測試，不保證可用性與速率）、需要即時路況、收費站等動態路網資訊、大眾運輸路線規劃（OSRM 只做道路網路）
看完整判斷
你需要注意- ⚠️ 公開示範伺服器不保證可用性與速率，官方建議僅供測試
- 正式使用需自己準備伺服器並定期更新路網資料（OSM 資料會變動）
- 只算道路路徑規劃，不含大眾運輸或即時路況
商業匯率查詢 API，165 種幣別，需免費帳號取得 API key。本站名片管理、旅遊工具箱、旅程紀錄作品用它做即時匯率換算。
💰 Freemium⚖️ 商用權利未查證🔒 訓練政策未查證📌 活躍（ExchangeRate-API 官方營運）
不適合金融交易級即時匯率（免費版每日只更新一次）、超過月額度的高頻查詢（免費版每月 1,500 次）、需要歷史逐筆分鐘級匯率的分析用途（要看付費層級）
看完整判斷
你需要注意- 免費版每日只更新一次匯率，非即時
- API key 不可寫進前端，要走後端代理
- 同公司舊網域 open.er-api.com 現已導回 exchangerate-api.com，若程式碼還在用舊網域要留意轉址
Cloudflare 的隱形防機器人驗證服務，取代傳統 CAPTCHA，多數情況不需要使用者互動。本站對外網站的訂閱表單用它擋機器人。
💰 Freemium⚖️ 可商用🔒 訓練政策未查證📌 活躍（Cloudflare 官方營運）
不適合需要超過免費額度的大量網站/主機名（免費版每個 widget 上限 10 個主機名、共 20 個 widget）、需要 30 天以上分析回溯（免費版僅 7 天）、不用 Cloudflare 帳號體系的專案（需要 Cloudflare 帳號設定 site key/secret key）
看完整判斷
你需要注意- siteverify 驗證步驟需要後端呼叫，secret key 不可寫進前端
- 免費額度以主機名與 widget 數計算，多網域專案要注意上限
- 屬於 Cloudflare 帳號體系，換供應商需重新整合
給開發者用的寄信 API，官方支援 Cloudflare Workers 整合。本站對外網站的訂閱雙重確認信用它寄送。
💰 Freemium⚖️ 可商用🔒 訓練政策未查證📌 活躍（Resend 官方營運）
不適合超過免費額度的大量發信（免費版每日 100 封、每月 3,000 封）、行銷型大量發信（另有獨立方案與計費）、需要極低單價的超大量交易信（費用隨量遞減但仍是按封計費）
看完整判斷
你需要注意- 免費額度有每日上限（100 封／天），突發大量發信會卡住
- 需要自己網域並完成 DNS 驗證才能用自訂寄件地址
- API key 外洩等於帳號被冒用寄信，不可寫進前端
Google 官方的登入與 OAuth 2.0 授權服務，涵蓋 Web／Android／iOS。本站名片管理 App 用它做 Google 登入，並串接 People API 建立/更新聯絡人。
💰 Free⚖️ 可商用（須遵守 Google API 使用者資料政策）🔒 訓練政策未查證📌 活躍（Google 官方營運）
不適合不想遵守 Google API 使用者資料政策（Limited Use）的專案、沒有 Google Cloud 專案與 OAuth 同意畫面審核流程的預算/時間、只需要純訪客模式、不想要求使用者登入的產品
看完整判斷
你需要注意- 正式上線（超過測試名單）需通過 Google 的應用程式驗證，審核有時間成本
- 敏感/受限 scope（如聯絡人寫入）審核更嚴格
- 使用者資料處理受 Limited Use 政策約束，違規可能被撤銷存取權
美國國家氣象局官方的預報、警報與觀測資料 API，免金鑰、免費。本站洛磯山脈國家公園作品用它查美國境內的天氣預報與觀測站資料。
💰 Free⚖️ 可商用🔒 訓練政策未查證📌 活躍（美國國家氣象局／NOAA 營運）
不適合美國以外地區（它只涵蓋美國，加拿大要用另一個官方源）、不帶 User-Agent 識別的請求（官方要求識別你的應用程式）、需要保證極低延遲的高頻交易級應用
看完整判斷
你需要注意- 只涵蓋美國境內地點
- 官方原文：「A User Agent is required to identify your application...will be replaced with an API key in the future」——目前免金鑰但未來會改，程式要預留改動空間
- 有速率限制但官方未公開確切數字，官方原文只說「a generous amount for typical use」，超過限制建議 5 秒後重試
免費的等高線地形圖磚服務，資料來自 OpenStreetMap＋SRTM 高程模型。本站多洛米蒂、勃朗峰環線、奧地利山區三支健行作品用它畫地形底圖。
💰 Free⚖️ 可商用（須標示出處，衍生地圖須同授權釋出）🔒 訓練政策未查證📌 活躍（OpenTopoMap 團隊與社群維護）
不適合不標示出處的專案（授權明文要求標示）、高流量商業服務直接打公用圖磚伺服器（無 SLA，建議自架或用商業圖磚服務）、需要即時更新地形資料的應用（SRTM 高程資料非即時）
看完整判斷
你需要注意- ⚠️ 公用圖磚伺服器跑在志工資源上，不保證可用性，高流量要自架或換商業來源
- 未標示出處等於違反授權條款
- 地形資料依 SRTM，部分地區精度較粗
免費的機器翻譯 API，背後是全球最大的翻譯記憶庫之一。本站世界盃推估器作品用它做英翻中的即時翻譯。
💰 Freemium⚖️ 商用權利未查證🔒 訓練政策未查證📌 活躍（Translated 公司營運）
不適合大量文字翻譯（匿名每日僅 5000 字元）、需要專業校對品質的正式文件翻譯、商用高頻服務（條款細節需另讀 Terms of Service，本站未逐條查證）
看完整判斷
你需要注意- 免費額度低（匿名 5000 字元/天），量大會被擋
- 翻譯品質是社群貢獻的記憶庫比對，非神經網路翻譯引擎等級
- 商用條款細節未逐條查證，正式產品用前應自行確認
免金鑰的體育賽事資料庫 API，涵蓋賽程、隊伍、選手與視覺素材。本站世界盃推估器作品用它查賽事資料。
💰 Freemium⚖️ 商用權利未查證🔒 訓練政策未查證📌 活躍（TheSportsDB 營運）
不適合需要正式 SLA 保證的生產環境（免費層無專屬 key，官方頁未列明限制數字）、需要即時逐秒比分更新的關鍵應用、商用政策未經逐條查證的正式產品（建議先讀 Terms of Use）
看完整判斷
你需要注意- 免費層未列明確切速率限制，正式產品建議升級付費層取得穩定 key
- 商用條款細節未逐條查證
- 資料更新頻率依賽事而異
ESPN 網站前端自己在用、但沒有正式文件或公開條款的 JSON 資料端點（site.api.espn.com），開發者社群逆向整理出賽程、比分、新聞等用法。本站世界盃推估器作品用它抓賽事資料。
💰 Free⚖️ 商用權利未查證🔒 訓練政策未查證📌 維護狀態未確認
不適合⚠️ 任何正式或商業產品——這不是公開發布的官方 API，沒有條款、沒有 SLA、沒有申訴管道、需要長期穩定性的應用（ESPN 可隨時改格式或封鎖，不會事先通知）、不能承受被中斷風險的關鍵路徑
看完整判斷
你需要注意- ⚠️ 非官方、無文件、無條款，ESPN 可能隨時改動或封鎖而不通知
- 沒有官方支援管道，出問題只能自己排查
- 不建議用於任何商業或正式產品
加拿大環境與氣候變化部（ECCC）／加拿大氣象局（MSC）的官方地理空間開放資料服務，涵蓋即時與歷史氣象、氣候、水文資料。本站洛磯山脈國家公園作品用它查加拿大境內的天氣資料。
💰 Free⚖️ 商用權利未查證🔒 訓練政策未查證📌 活躍（加拿大環境與氣候變化部營運）
不適合加拿大以外地區（它只涵蓋加拿大，美國要用 NWS）、不支援地理空間網路服務格式的簡易前端（官方要求用支援 OGC 的軟體存取）
看完整判斷
你需要注意- 只涵蓋加拿大境內
- 需要支援地理空間網路服務（OGC API／WMS 等）的用戶端
- 商用授權條款未在本次查證中確認