Gunicorn 為什麼比直接 python app.py 更適合正式上線
很多人剛開始學 Flask 時，第一個跑網站的方法通常都是直接執行 python app.py。這在開發階段完全沒有問題，因為它簡單、直接，而且改完程式馬上就能看到結果。不過如果你要把網站正式對外提供服務，通常就不建議繼續用這種方式，而是改用 Gunicorn 這類 WSGI Server。 原因很簡單，Flask 內建的 server...
很多人剛開始學 Flask 時，第一個跑網站的方法通常都是直接執行 `python app.py`。這在開發階段完全沒有問題，因為它簡單、直接，而且改完程式馬上就能看到結果。不過如果你要把網站正式對外提供服務，通常就不建議繼續用這種方式，而是改用 Gunicorn 這類 WSGI Server。
原因很簡單，Flask 內建的 server 本來就不是拿來做正式部署的。它的定位比較偏向開發測試，重點是讓你快速把程式跑起來，而不是長期穩定承受外部請求。所以你在終端機裡其實也常常會看到類似這樣的提醒：
python app.py
* Serving Flask app 'app'
* Debug mode: on
WARNING: This is a development server. Do not use it in a production deployment.這句警告不是裝飾而已，它是在告訴你這個 server 並不是為正式環境設計的。開發 server 的優點是方便，但缺點也很明顯，例如效能、穩定性、程序管理與 worker 模型都不是以正式上線為目標。
Gunicorn 不一樣。Gunicorn 是專門用來承載 Python WSGI 應用程式的 server，定位就是正式環境使用。你可以指定 worker 數量、綁定 port、搭配 Nginx 或 Cloudflared，也比較容易跟 `pm2`、systemd 這類程序管理工具整合。
最常見的 Flask 啟動方式大概是這樣：
/root/projects/news/venv/bin/gunicorn -w 4 -b 0.0.0.0:5002 app:app這裡的 `-w 4` 代表開四個 worker，`-b 0.0.0.0:5002` 代表綁定到 `5002` port，而 `app:app` 則表示載入 `app.py` 裡的 Flask app 物件。這樣的好處是結構清楚，也更適合讓外部流量穩定打進來。
如果你的專案是工廠模式，而不是直接有一個全域 `app`，那也可以這樣寫：
/root/projects/news/venv/bin/gunicorn -w 4 -b 0.0.0.0:5888 "app:create_app()"也就是說，Gunicorn 不只是比 `python app.py` 更穩，它也更彈性，能配合不同專案結構。
另外，當你開始有多個網站時，Gunicorn 的優勢會更明顯。因為你可以把每個專案都變成固定格式：固定 port、固定 worker、固定啟動方式，再交給 `pm2` 或其他管理工具統一控制。例如：
pm2 start bash \
--name python-site \
--cwd /root/projects/python \
-- -lc '/root/projects/news/venv/bin/gunicorn -w 4 -b 0.0.0.0:5002 app:app'這種做法就比單純手動執行 `python app.py` 穩定很多。你可以重啟、查看 log、保存程序清單，也比較容易在主機重開後恢復服務。
再來是 debug 模式的問題。很多人在開發時會把 Flask 的 debug 開著，這對本機寫程式很方便，但正式環境通常不應該這樣做。Gunicorn 上線時通常會配合關閉 debug，把程式維持在比較穩定的執行狀態。這不只是安全問題，也是避免一些不必要的行為，例如自動 reload、雙進程、錯誤頁過度暴露等。
從維護角度來看，Gunicorn 也比較符合「應用程式和程序管理分離」的思路。Flask app 專心處理網站邏輯，Gunicorn 專心處理 Web Server 角色，而 `pm2` 或 systemd 再負責程序生命週期。這樣每一層都很清楚，日後出問題也比較容易定位。
所以如果你現在只是本機開發，用 `python app.py` 沒問題；但只要你準備對外上線、綁網域、掛 Cloudflared 或交給 Nginx 代理，基本上就應該改用 Gunicorn。因為正式環境最重要的不是「能跑」，而是穩定、可管理、可重啟、可維護。這幾件事情，Gunicorn 都比 Flask 內建 server 更適合。