—— 從快速開發、Admin、權限管理到企業 CMS 的技術選型比較
近幾年 Python 的熱度非常高。
尤其 AI、Machine Learning、Data Science、LLM 與自動化工具快速發展之後，Python 幾乎成為許多工程師的第一選擇。
因此很自然會出現一個問題：
既然大家都在使用 Python，那麼 Web 後台、CMS、企業管理系統，是不是也應該全面改用 Python？
我的答案是：
不一定。
這不是因為 Python 不夠強。
恰恰相反，Python 在 AI、資料科學與 API Service 領域非常強。
真正需要比較的是：
Django / FastAPI 生態，與 Laravel + Filament，在特定類型的 Web 系統上，誰能用更低的成本完成需求並長期維護？
因此，這篇文章不討論「哪個語言比較好」，而是討論一個更實際的問題：
不同類型的專案，應該選擇什麼樣的 Web 技術棧？
一、先釐清：Python 並不是只有 Django
談 Python Web，最常見的兩條路線大概是：
Python
│
├── Django
│ └── Full-stack + ORM + Admin
│
└── FastAPI
└── API-first + Type Hint + OpenAPI
兩者其實解決的是不同問題。
Django
Django 是完整的 Web Framework。
它包含：
ORM
Authentication
Authorization
Admin
Form
Routing
Middleware
Template
Migration
Cache
Session
其中 Django Admin 是它非常重要的一部分。
Django 官方本身就將 Admin 定位為可以快速建立模型管理介面的工具，而不是單純的「資料庫 CRUD 頁面」。(Django Admin)
FastAPI
FastAPI 的核心則更加偏向：
API
+
Type Hint
+
Validation
+
OpenAPI
+
Async
它非常適合：
REST API
Microservice
AI Service
Backend Service
API-first Architecture
FastAPI 的 Security / OAuth2 Scope 也可以與 OpenAPI 文件整合，這對 API-first 系統非常方便。(FastAPI Security)
因此，不能簡單把：
Django
FastAPI
Laravel
當成三個完全相同定位的 Framework。
二、Django Admin 其實比很多人想像的強
這點值得特別強調。
如果有人說：
「Django Admin 只能做簡單 CRUD。」
這個說法其實已經過時。
Django Admin 本身就支援：
List Display
Search
Filter
Ordering
Inline
Custom Action
Permission
Custom Form
Custom View
Custom Template
而且 Django 本身有 User / Group / Permission 的完整授權機制。
基本 Permission 可以對應：
add
change
delete
view
再搭配 Group：
Content Editor
Content Manager
Administrator
就能建立基本的 RBAC。
更重要的是，Django 生態還有大量成熟套件可以進一步補足企業需求。
例如：
django-admin-interface
django-import-export
django-guardian
django-simple-history
可以分別補足：
Admin UI
Import / Export
Object-level Permission
History / Audit
因此比較正確的說法應該是：
Django Admin 是一個非常成熟的 Admin Framework，而且可以透過生態系擴充成相當完整的企業後台。
而不是：
Django 只能做基本 CRUD。
三、那為什麼還要談 Laravel + Filament？
因為問題不在於：
「Django 能不能做到？」
Django 當然能做到。
真正的問題是：
需要多少組裝？
這是 Laravel + Filament 與 Django 的核心差異之一。
四、Filament 的核心優勢：高度整合
Laravel 本身提供：
Routing
ORM
Migration
Validation
Authentication
Authorization
Queue
Event
Notification
Mail
Storage
Cache
Scheduler
API
再加上 Filament：
Admin
Resource
Form
Table
Action
Widget
Dashboard
Relation Manager
Import
Export
File Upload
Rich Editor
因此可以形成：
Laravel
↓
Filament
↓
企業 Admin / CMS
這種架構的最大優勢不是「功能比較多」。
而是：
這些功能本來就是設計成一起工作的。
五、快速開發真正比較的是「需要自己組多少東西」
假設今天要建立：
Product
包含：
name
price
category
status
image
published_at
在 Laravel + Filament 中，可以透過 Resource 建立：
Product
├── List
├── Create
├── Edit
├── View
├── Form
├── Table
├── Filter
└── Action
Filament 4 也提供 Resource / Schema 等抽象，讓 Form、Table 與 Action 可以使用宣告式方式組合。(Filament Resources)
六、Django 其實也可以非常快
如果使用 Django：
Model
↓
ModelAdmin
↓
Admin
同樣可以快速得到：
List
Search
Filter
Create
Edit
Delete
而且 Django Admin 已經非常成熟。
因此，如果比較：
「誰能快速做 CRUD？」
不能說 Laravel + Filament 一定勝出。
Django 完全有資格競爭。
七、真正的差異開始出現在複雜後台
當需求從：
CRUD
開始變成：
CMS
+
Permission
+
Workflow
+
Form Builder
+
Rich Editor
+
File Upload
+
Relation
+
Import / Export
+
Dashboard
+
Custom Action
+
Page Builder
比較就開始變得有趣。
因為此時工程師需要思考：
誰負責 Form？
誰負責 Table？
誰負責 Permission？
誰負責 Role？
誰負責 File？
誰負責 Audit？
誰負責 Import？
誰負責 Export？
誰負責 UI？
Django 可以透過套件解決。
FastAPI 也可以透過套件解決。
Laravel 也可以透過套件解決。
真正不同的是：
框架本身與這些元件的整合程度。
八、FastAPI 的優勢其實非常明顯
這裡也不能忽略 FastAPI。
FastAPI 生態近年也逐漸補足 Admin 的需求。
例如：
FastAPI
+
SQLAlchemy
+
SQLAdmin
可以建立相當完整的 Admin。
另外也有：
fastapi-admin
SQLModel
其他 Admin Framework
等方案。
因此：
「FastAPI 沒有 Admin。」
這個說法也是不準確的。
更正確的說法是：
FastAPI 本身不是以 Admin 為核心，而它的生態提供了多種 Admin 解決方案。
九、而 FastAPI + Vue / React 其實是一條非常乾淨的路
如果團隊本來就採用：
Frontend
Vue / React
↓
FastAPI
↓
Database
那麼這種架構其實非常合理。
尤其是：
Mobile App
SPA
Microservice
AI Service
External API
都需要同一套 API 的情況。
這時候：
FastAPI
+
Vue / React
反而可能比：
Laravel
+
Filament
+
另外一套前端
更符合團隊需求。
所以不能說：
FastAPI 做 Admin 不好。
而應該說：
FastAPI 更適合 API-first 的架構，而 Filament 更適合快速建立 Business Application / Admin / CMS。
十、權限管理才是真正值得比較的地方
企業系統最容易低估的就是 Permission。
簡單系統可能只有：
Admin
User
但大型 CMS 往往會變成：
User
↓
Role
↓
Permission
↓
Resource
↓
Action
↓
Record
例如：
Project
├── View
├── Create
├── Update
├── Delete
└── Publish
甚至：
Project
├── Manage Content
├── Manage Structure
└── Manage Publish
再進一步可能還要判斷：
使用者可以修改這個 Project 嗎？
而不是只有：
使用者可以修改 Project 嗎？
這就是 Model-level 與 Record-level Authorization 的差別。
十一、Django 在權限這方面其實很完整
Django 原生提供：
User
Group
Permission
並且 Admin 會使用這些 Permission。
另外還可以使用：
django-guardian
處理 Object-level Permission。
因此可以做到：
User A
→ 可以修改 Project 1
User B
→ 可以修改 Project 2
這代表 Django 完全有能力處理企業級權限。
所以這裡不應該寫成：
Django 權限不如 Laravel。
比較精確的說法是：
Django 的權限能力很完整，但 Laravel 的 Policy + Gate + Filament Authorization 整合，在 Laravel + Filament 的企業 Admin 場景中非常自然。
十二、Laravel + Policy + Filament 的優勢
Laravel 原生提供：
Gate
Policy
Authorization
其中 Policy 特別適合 Model / Resource 授權。
例如：
public function update(
User $user,
Project $project
): bool {
return $user->id === $project->owner_id;
}
接著 Filament Resource / Action 可以使用同一套 Authorization 邏輯。
因此形成：
Laravel Policy
↓
Filament Resource
↓
Action Authorization
↓
UI Button
也就是：
後端授權規則可以直接影響 Admin UI。
這種整合對 CMS 非常重要。
十三、Filament 也不是沒有缺點
如果文章只說 Filament 很快，卻不談它的限制，就會變成推銷文。
Filament 非常適合：
Admin
CMS
CRUD
Dashboard
Form
Table
Internal Tool
但不是所有 UI 都應該使用 Filament。
1. 極端複雜的表格互動
例如：
大量即時計算
跨欄位即時更新
拖曳排序
大量資料同步操作
跨 Resource 狀態互動
這種需求如果已經超過 Filament 的抽象範圍，就可能需要：
Custom Livewire
Custom JavaScript
Vue
React
甚至直接建立獨立前端。
2. 即時協作
例如：
多人同時編輯
即時 Presence
WebSocket
Live Collaboration
即時游標
即時狀態同步
Livewire 當然可以整合即時功能。
但如果產品本身就是：
「像 Google Docs 一樣多人即時協作。」
那麼專業的前端架構通常會更適合。
3. 超大型資料量
例如：
10 萬筆
100 萬筆
500 萬筆
這時候問題就不只是 Filament。
而是：
Database Index
Query
Pagination
Search
Caching
Virtualization
Data Loading
甚至可能需要：
Elasticsearch
OpenSearch
專用 Search Service
Filament 可以處理大型資料，但不能期待：
「把幾百萬筆資料丟進 Table，Framework 自動解決所有效能問題。」
這在任何 Framework 都不成立。
十四、因此「快速開發」不等於「什麼都不用自己做」
這是非常重要的觀念。
Filament 可以大幅降低：
CRUD UI
Form
Table
Validation
Admin
的開發成本。
但當需求超出 Framework 抽象範圍：
Complex UI
Real-time
Huge Dataset
Custom Interaction
Special Workflow
依然需要工程師介入。
所以真正好的使用方式是：
Standard Requirement
↓
Filament
Complex Requirement
↓
Custom Component / Livewire / Vue / React
而不是：
Everything
↓
Filament
十五、人才成本其實也是技術選型的一部分
這是很多技術比較文章忽略的地方。
假設公司已經有：
20 位 Python Engineer
其中：
10 位 Data Engineer
5 位 AI Engineer
5 位 Backend Engineer
這時候如果突然決定：
「我們要全面改 Laravel。」
技術上可能完全可行。
但是：
Training Cost
Hiring Cost
Migration Cost
Productivity Loss
Knowledge Transfer
Maintenance
都是真實成本。
反過來也一樣。
如果團隊已經有：
Laravel
PHP
Vue
Filament
的成熟經驗，那麼為了「大家都在用 Python」而改成 Django / FastAPI，也可能是一個非常昂貴的決策。
所以：
技術選型不能只看 Framework 能力，也要看團隊已經擁有什麼能力。
十六、三年維護成本比第一天開發速度更重要
一個專案第一天可以做到：
Python
Laravel
Node
Go
其實都不難。
真正困難的是三年後。
你需要面對：
新功能
Bug
Security
Dependency Upgrade
Database Migration
Performance
新人加入
技術債
權限需求
商業規則變更
因此真正值得問的是：
三年後誰來維護？
十七、Python 生態的優勢也可能成為成本
Python 的優點是生態非常龐大。
但另一面是：
很多套件
很多選擇
很多組合
例如：
FastAPI
+
SQLAlchemy
+
Pydantic
+
SQLAdmin
+
Auth Library
+
Permission Library
+
Frontend
+
Storage
+
Background Worker
每一個元件都可能非常優秀。
但工程師也必須自己決定：
Architecture
Integration
Version Compatibility
Error Handling
Authorization Boundary
因此：
自由度越高，架構責任通常也越高。
十八、Laravel 的優勢就是 Convention
Laravel 的哲學相對比較接近：
提供一套有意見的完整解決方案。
例如：
Routing
ORM
Migration
Validation
Authentication
Authorization
Queue
Event
Notification
Mail
Storage
Cache
Scheduler
再搭配：
Filament
Livewire
Spatie
可以快速形成企業應用。
這種模式最大的優勢不是：
「Laravel 比 Python 強。」
而是：
很多常見問題已經有明確的解法。
十九、所以兩邊其實是不同的工程哲學
可以簡化成：
FastAPI
給我自由度
讓我自己組架構
Django
給我完整 Web Framework
讓我快速建立網站與 Admin
Laravel + Filament
給我完整 Web Framework
再給我高度整合的 Business Admin UI
讓我快速建立企業系統
沒有哪個一定比較好。
只是適合的問題不同。
二十、真正合理的架構甚至不是二選一
如果公司同時需要：
CMS
Admin
AI
Recommendation
Image Processing
LLM
Data Analysis
最合理的答案可能根本不是：
Laravel OR Python
而是：
Frontend
│
▼
Laravel API
│
┌────────┴────────┐
│ │
Filament Python Service
│ │
CMS / Admin AI / ML
│ │
└────────┬────────┘
│
Database
例如：
Laravel
負責：
User
CMS
Permission
Admin
Business Logic
Order
Workflow
API
Python
負責：
AI
LLM
Recommendation
Image Processing
Data Analysis
Machine Learning
這種架構完全合理。
二十一、那到底該怎麼選？
可以用下面這張表快速判斷：
| 需求 | 建議 |
|---|---|
| AI / ML | Python |
| Data Science | Python |
| LLM / AI Service | Python |
| API-first | FastAPI |
| Microservice | FastAPI / 依需求選型 |
| 傳統 Full-stack Web | Django / Laravel |
| Django 原生 Admin | Django |
| 企業 CMS | Laravel + Filament / Django |
| 大量 CRUD | Laravel + Filament / Django |
| Admin + Form + Table | Laravel + Filament |
| CMS + Page Builder | Laravel + Filament |
| 細粒度 CMS 權限 | Laravel + Filament / Django |
| 高度客製前台 | Vue / React / Astro 等 |
| AI + CMS | Laravel + Python |
二十二、最後不要問「Python 還是 Laravel」
我認為真正成熟的技術選型問題應該是：
這個專案的核心問題是什麼？
誰會開發？
誰會維護？
團隊已經會什麼？
三年後系統會變成什麼？
哪個架構可以降低長期總成本？
而不是：
現在大家都用什麼？
結論
Python 非常強。
尤其：
AI
Machine Learning
Data Science
LLM
Automation
API Service
這些領域，Python 有非常明顯的優勢。
Django 也不是只能做簡單 CRUD。
透過 Django Admin 加上成熟套件生態，它完全可以建立相當完整的企業後台。
FastAPI 也不是沒有 Admin。
透過 SQLAdmin、fastapi-admin 或前後端分離架構，同樣可以建立企業級系統。
所以這篇文章真正想說的並不是：
Laravel 比 Python 好。
而是：
不要因為 Python 現在很熱門，就認為所有 Web 專案都應該使用 Python。
如果：
核心是 AI
→ Python 優先。
如果：
核心是 API / Microservice
→ FastAPI 非常值得考慮。
如果：
核心是 Web + Admin
→ Django 是成熟選擇。
如果：
核心是企業 CMS
+
大量 CRUD
+
Admin
+
Permission
+
Workflow
+
Form
+
Table
+
Page Builder
→ Laravel + Filament 依然是目前非常有競爭力的選擇之一。
而如果同時存在：
CMS
+
AI
那麼最合理的答案甚至可能是：
Laravel + Filament
+
Python
而不是強迫整個系統只使用一種語言。
最後，我認為真正值得記住的一句話
好的工程師不是選現在最紅的技術，而是選最適合問題、團隊與未來三年維護成本的技術。
技術選型的目標從來不是證明：
「我的語言比較強。」
而是：
用最合理的成本，把系統長期做好。
