你有沒有遇過那種時刻：主管一句「做成一個小工具給大家用」，你腦子裡翻譯成「好，我要寫模型」，結果現實翻譯成「我在跟 CSS 打架，還要處理登入」。為什麼會變成這樣？
多數資料科學家不需要做真正的 Web App
多數資料科學家的互動工具用 Streamlit、Dash 就能交差；只有當需求牽涉多使用者驗證、背景任務、API 與部署治理時，才需要 FastAPI + 前端框架。用錯框架最常見的代價是時間被吃光，模型反而沒時間改。（來源：Plotly Dash 文件、FastAPI 文件）
- 要的是「一次性內部展示」還是「長期營運的產品」？
- 會不會有多使用者、權限、審計？
- 任務是「秒出結果」還是「要跑 30 分鐘」？
- 你要不要碰 JavaScript？不想的話路就窄一點。
- 公司其實只想要報表？那 BI 工具有時更像解答。
幻想跟現實差在哪 你以為在做分析 其實在補洞
資料科學家的「做個小工具」通常指的是把 notebook 包裝一下；軟體工程的「做 App」通常指的是要維運、要監控、要回溯、要擴充。這兩個世界對「完成」的定義不一樣，框架選錯就會痛很久。（來源：OWASP ASVS、NIST SSDF 公開文件）
我記得當時：最常見的起點真的很單純：一個圖、一個篩選條件、一個「給老闆看比較不會被忽略」的介面。然後需求開始長牙。
先是「可不可以讓別人也能用」。再來是「要不要登入」。接著「不同部門看不同資料」。
講到登入，我腦子會自動跳到資安那條線，因為你只要碰到帳號密碼，就會碰到OWASP Top 10（常見 Web 弱點清單）那一整包，什麼注入、XSS、Session 管理。你原本只想畫個圖耶。
核心落差：互動展示偏「單機腳本」，產品型 App 偏「系統工程」。兩者不是誰比較高級，是成本結構完全不同。
框架分層的真相 快速交差到工程級 不是同一種痛
Streamlit、Shiny for Python 適合把 Python 腳本快速變成介面；Dash、FastHTML 適合需要更細的 UI 控制與路由；FastAPI + React 適合有 API 合約、非同步任務與前後端分工的產品型系統。（來源：Streamlit 文件、Posit Shiny 文件、Plotly Dash 文件、FastAPI 文件）
| 層級 | 代表選項 | 適合的場景 | 你會踩到的雷 |
|---|---|---|---|
| S 快速層 | Streamlit、Shiny for Python | 內部 demo、一次性工具、把 notebook 變成能點的東西 | 狀態管理一複雜就開始怪；多使用者、驗證、長任務會讓你懷疑人生 |
| A 控制層 | Dash、FastHTML | 需要比較像「真的 App」但又不想全套前端工程 | 要懂一些 Web 概念；UI 一多就要整理架構，不然檔案會長得像災難現場 |
| B 工程層 | FastAPI + React、Flask + 自訂前端 | 產品化、多人同時用、API 要被別的系統串、要監控與權限 | 前後端溝通、部署、測試、CI/CD；你會花很多時間在「不是模型」的地方 |
| C 報表替代層 | Tableau、Power BI、Looker Studio | 本質是資料呈現、KPI 看板、管理層要固定報表 | 互動邏輯被工具限制；要做很客製的流程會卡住，但至少不會被前端折磨 |
| D 小眾玩具層 | Gradio、NiceGUI、Taipy、Panel、Quarto 等 | 自己玩、原型、特定社群剛好有人用 | 社群小、遇到坑找不到人；你會在凌晨兩點對著 issue tracker 發呆 |
順手講個名詞：非同步（async，讓伺服器同時處理多個請求而不被單一長任務卡死）跟背景任務（background jobs，把長時間運算丟到隊列跑）這兩個東西，基本上就是「從玩具走向系統」的分水嶺。
很現實啦。你只要說「要跑很久」，下一句就會變「那使用者要不要看到進度」。
進度條這種小東西，背後常常是隊列、worker、狀態儲存。突然就工程了。
時間 vs 金錢 算帳矩陣 你到底是在省誰的成本
用 Streamlit 省的是開發時間，用 FastAPI + React 省的是長期維運與擴充成本；選 Dash 或 FastHTML 通常是在「可控」與「不要碰太多前端」之間折衷。把需求的使用人數、驗證、部署頻率寫成成本矩陣，決策會清楚很多。（來源：Google SRE 公開觀念、Microsoft Power BI 文件）
我那時候的算法：不要用感覺。就把兩條軸拉出來：時間（你要多快交付）跟金錢（包含人力、維運、出事的代價）。
這裡我用一個很土的矩陣，但真的好用。
| 情境 | 時間成本 | 金錢成本 | 我看過最常落點 |
|---|---|---|---|
| 明天要 demo，只有你自己用 | 低到爆，今天熬夜就能上 | 幾乎沒有，最多是一台筆電 | Streamlit：快，粗，先活下來 |
| 部門內 10–50 人用，不太管權限 | 中等，要整理流程跟狀態 | 開始出現：部署、版本、壞了誰修 | Dash：比較像「正經工具」但還能用 Python 撐住 |
| 跨部門、多角色、要登入與審計 | 高，要對接 SSO、RBAC | 高，因為資安與合規出事很貴 | FastAPI + 前端：不然後面會一直補洞 |
| 其實只是固定看板，管理層每週看一次 | 低到中，看資料源整不整齊 | 買授權或雲服務，錢花得很明確 | Power BI / Tableau / Looker Studio：把「做 App」這件事關掉 |
偵探式問題：你要省的到底是「這週交付」的時間，還是「未來半年一直修」的錢？兩個只能選一個先付。
有時候公司以為叫你做 App 是省錢，結果你把一個資料專業的人變成半吊子前端。
很虧。
那些很怪但又有人說好用的選項 真的用得上嗎
H2O Wave、Reflex、Vaadin、Tornado、Svelte + Python 後端各有利基：Wave 偏 ML 儀表板、Tornado 偏即時串流、Svelte 偏輕量前端體驗；但小眾工具的主要風險是社群與維運資源不足。（來源：H2O Wave 文件、Tornado 文件）
講到小眾框架：我腦子會先浮出一個畫面：半夜卡 bug，搜尋結果只有兩篇，而且其中一篇是三年前的。
像原文提的 H2O Wave，那種「做 ML 儀表板很順」的定位其實滿清楚的。Reflex（以前叫 Pinecone）也有人玩，純 Python 的 UI 寫法看起來很香，但它還在長大，長大的意思就是 API 會變、教學會跟不上、你會一直對照版本。
Vaadin 更妙，Java 的世界跑來跟 Python 握手。可以。只是 JVM 的 stack trace 有時候像摩斯密碼，你要有心理準備。
Tornado 我覺得最誠實：它就是快，非阻塞 I/O（non-blocking I/O，不讓單一請求卡住整個伺服器）那套很硬派。可是你真的需要那個快嗎？還是你只是想在會議上看起來很懂。
對了，Svelte 這個詞一出現，我會忍不住把 React 拿來比較，React 有時候像行李箱，什麼都能裝，但你每次出門都背一個行李箱也怪怪的；Svelte 比較像隨身包，輕。舒服。
但資料人通常不想碰前端。這也是真的。
最後那個很刺的真相 有些 App 根本不該你做
當需求包含 SSO、RBAC、審計紀錄、監控告警與 CI/CD 時，這已經是軟體工程交付範疇；資料科學家最划算的角色通常是把資料產品的指標、模型與驗證做紮實，再交給工程團隊產品化。（來源：OWASP ASVS、Google SRE 公開觀念）
我記得最累的不是寫程式：是「需求一直加，但沒有人承認這已經是產品」。你就會一直補，一直補，補到你忘記自己本來要做什麼分析。
所以我後來會用一個很粗暴的檢核：只要提到 SSO、權限分級、稽核、或「之後要給客戶用」，那就不是「做個小工具」。那是另一個案子。另一種預算。另一種責任。
如果硬要給一句話：把 Streamlit 當快刀，把 FastAPI + 前端當工廠產線；刀很好用，但你不會拿刀去蓋工廠。
好，拉回來。
你現在手上的狀況是哪一種？是「明天要 demo」那種緊急案，還是已經有人在問「可不可以加登入、加權限、加歷史紀錄」那種慢慢變大的怪物？你卡住的點，是 UI、部署、還是其實是資料本身不乾淨？
