在現代軟件開發中，有一種趨勢正在悄悄變得危險：

為了“靈活性”，越來越多的邏輯不再寫在代碼里，而是被轉移到了配置文件中。

聽起來很理想——只改配置，無需部署，甚至非開發人員也能參與更改。

但現實呢？

配置變成了代碼本身，邏輯藏進了 JSON、YAML 和環境變量里，復雜度不僅沒減少，反而更難維護。

配置驅動開發的“誘人承諾”

配置驅動開發最初的出發點是好的。

將功能、行為抽象成配置項，理論上可以帶來這些好處：

• 不需要改代碼就能調整邏輯；
• 更容易動態控制開關、參數；
• 提高了非技術人員的參與空間；
• 可以適配多環境、多租戶部署。

于是，YAML 文件越來越復雜，配置項越來越多，系統看起來越來越“可配置”。

問題從什么時候開始的？

從**配置不再只是“配置”**那一刻開始，一切變了味。

常見的過度場景包括：

• Feature flag 不再只是 true/false，而是控制整個業務流程；
• YAML 配置里開始寫條件判斷、依賴關系，甚至模擬“循環”；
• 數據庫中存儲一整套“規則引擎”，讀取后動態決定程序行為；
• 配置嵌套層級越來越深，甚至出現了“配置驅動配置”的反模式。

此時，“靈活性”帶來的代價變成了：

可讀性差、無法測試、調試困難、版本不可控。

更糟的是——邏輯已經不在代碼里了，而開發人員依然要負責維護這些隱藏在角落的配置邏輯。

配置過度的真實后果

調試變成了找線索

代碼可以設置斷點、單元測試、日志追蹤。

配置卻不行。

當業務邏輯被拆進配置后，開發人員常常陷入“猜測邏輯”的陷阱：

• 配置改了，但不知道生效順序；
• 線上表現異常，但找不到對應代碼；
• A 文件引用 B 配置，B 配置引用數據庫，最后才發現是 C 系統寫入了錯的數據。

這時候，“配置靈活性”變成了運維災難。

“非技術人員可配置”只是幻想

很多系統引入配置驅動的理由是：

“讓產品經理也能配置邏輯，減少開發投入。”

理想豐滿，現實骨感。

配置一旦涉及邏輯判斷、流程控制，非技術人員根本不敢動。

最終結局：

• “要改配置？你去找開發。”
• “改錯一次就怕了，還是別動了。”
• “我們還是提需求吧。”

于是，系統不僅沒變簡單，反而添加了一層理解門檻。

配置的邊界到底在哪？

配置不是洪水猛獸，關鍵在于用在哪、怎么用。

? 合理的配置用途：

• 環境變量（API 地址、密鑰、端口等）；
• 簡單特性開關（某個模塊是否啟用）；
• UI 文案、靜態資源路徑；
• 權限標識、角色映射。

? 不合理的配置用途：

• 控制流程跳轉、業務判斷；
• 決定數據庫寫入邏輯；
• 用嵌套 JSON/YAML 編寫“偽腳本”；
• 用配置拼裝函數調用順序。

一句話總結：

配置應該是“輸入參數”，而不是“邏輯決策者”。

結語：代碼才是最好的“配置方式”

開發者要警惕一個現象：

為了“解耦”或“靈活性”，不斷把邏輯抽象成配置，最后只是把原來的代碼藏到了另一個地方。

沒有類型提示、沒有測試框架、沒有 IDE 支持的配置文件，并不比代碼更好維護。

所以，在考慮“要不要用配置”的時候，問自己一句：

??“如果直接寫成代碼，是不是更清晰？”

有時候，最好的抽象，是不抽象。