FastAPI作者用95張表手寫SQL

「95張表，9個業務域，零ORM。」

這是Rohan Kumar在技術選型復盤里扔出的數字。三個月前他啟動一個AI Agent項目時，沒人推薦他這么干。三個月后他承認：有些坑，踩過才知道有多深。

從Fastify到FastAPI：一場"熟悉的陌生感"實驗

Rohan的底色是JavaScript。React寫了多年，后端用過Express和Fastify。當他決定切Python做AI項目時，第一個問題不是"用什么"，而是"別讓我太難受"。

FastAPI的語法讓他愣了一下——裝飾器路由、async/await、類型提示居然真的生效。這不像學新框架，倒像把Fastify的代碼用Python重寫了一遍。技術決策里，"熟悉感"往往被低估。Rohan沒否認這點：「I'd be lying if I said it wasn't a factor」，但技術理由同樣站得住腳。

他的系統要同時處理三件事：n8n的并發webhook回調、React儀表盤的實時輪詢、PostgreSQL的持久化asyncpg連接。全是異步I/O，而FastAPI從出生就圍著這個模式轉。Django后來補了異步支持，但用起來像 retrofit（后裝補丁），不是原生設計。

代價在三個月后才顯形。

沒有Django的免費管理后臺，他花數周從頭寫React儀表盤。沒有內置遷移系統，他用原始SQL文件通過SSH管道進Docker，再喂給psql。復雜語句的shell引號在SSH→Docker→psql三層傳遞中被反復轉義，「mangles complex statements」——他原話。

插件生態更薄。Django 20年前就有的功能，他得自己造輪子。

95張表與手寫SQL：一場控制狂的豪賭

Rohan主動跳過了ORM。95張表分布在9個業務域，他想看清每一條SQL長什么樣。沒有魔法，沒有N+1查詢的驚喜，沒有遷移框架生成他讀不懂的語句。

這個決定的底氣來自數據結構的本質。交易關聯銀行賬戶，郵件分類引用消息實體，知識事實從多源交叉驗證，調度任務指向Agent再指向模型——關系嵌套關系，事務套著事務。MongoDB的方案是反規范化，文檔里嵌文檔，一致性自己手工維護。PostgreSQL的ACID在這里不是賣點，是剛需。

但PostgreSQL還藏了一手牌。

LISTEN/NOTIFY機制替他干掉了消息隊列。郵件分類完成的瞬間，觸發器發射通知，brain服務通過asyncpg毫秒級捕獲并響應。沒有Kafka，沒有RabbitMQ，用的是Postgres 15年前就內置的功能。

CREATE OR REPLACE FUNCTION notify_email_classified()...

這行代碼省掉的不僅是基礎設施，是運維心智負擔。

選型沒有標準答案，只有被低估的上下文

Rohan的坦誠在技術博客里少見。他區分了兩種決策：informed decisions（知情選擇）和"I already know this tool, and I need to move fast"（熟悉工具優先）。兩者都合理，但代價曲線不同。

他給后來者的建議很具體：如果你的項目是傳統web應用——用戶賬戶、管理后臺、表單提交——直接用Django。FastAPI的舒適區是API層，協調多個服務之間的數據流，這正是他的處境。

這個判斷和三個月前的選擇形成微妙張力。他沒說后悔，但「bitten me more than once」的表述已經夠重。

技術選型的殘酷在于：你只能在事后知道哪些"合理"其實是"僥幸"。

Rohan的幸運在于，他的數據模型確實關系密集，PostgreSQL的LISTEN/NOTIFY恰好覆蓋了他的實時需求。如果業務突然需要復雜全文檢索或地理空間查詢，那95張表的手寫SQL維護成本會呈指數級上升。

他沒提測試覆蓋率，沒提團隊規模，沒提當協作者打開代碼庫時的 onboarding 成本。這些沉默本身也是信息。

文章結尾，Rohan留了一個未完成的思考：「Both are valid, but they lead to different trade-offs down the line」——兩種選擇都成立，但代價會在未來某個節點兌現。

你上一次技術選型時，"熟悉感"占了多少權重？三個月后，這個比例讓你安心還是心虛？