在現(xiàn)代軟件開發(fā)中，有一種趨勢正在悄悄變得危險：

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

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

但現(xiàn)實呢？

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

配置驅(qū)動開發(fā)的“誘人承諾”

配置驅(qū)動開發(fā)最初的出發(fā)點是好的。

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

• 不需要改代碼就能調(diào)整邏輯；
• 更容易動態(tài)控制開關(guān)、參數(shù)；
• 提高了非技術(shù)人員的參與空間；
• 可以適配多環(huán)境、多租戶部署。

于是，YAML 文件越來越復(fù)雜，配置項越來越多，系統(tǒng)看起來越來越“可配置”。

問題從什么時候開始的？

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

常見的過度場景包括：

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

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

可讀性差、無法測試、調(diào)試困難、版本不可控。

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

配置過度的真實后果

調(diào)試變成了找線索

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

配置卻不行。

當業(yè)務(wù)邏輯被拆進配置后，開發(fā)人員常常陷入“猜測邏輯”的陷阱：

• 配置改了，但不知道生效順序；
• 線上表現(xiàn)異常，但找不到對應(yīng)代碼；
• A 文件引用 B 配置，B 配置引用數(shù)據(jù)庫，最后才發(fā)現(xiàn)是 C 系統(tǒng)寫入了錯的數(shù)據(jù)。

這時候，“配置靈活性”變成了運維災(zāi)難。

“非技術(shù)人員可配置”只是幻想

很多系統(tǒng)引入配置驅(qū)動的理由是：

“讓產(chǎn)品經(jīng)理也能配置邏輯，減少開發(fā)投入?！?/span>

理想豐滿，現(xiàn)實骨感。

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

最終結(jié)局：

• “要改配置？你去找開發(fā)?！?/span>
• “改錯一次就怕了，還是別動了?！?/span>
• “我們還是提需求吧?！?/span>

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

配置的邊界到底在哪？

配置不是洪水猛獸，關(guān)鍵在于用在哪、怎么用。

? 合理的配置用途：

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

? 不合理的配置用途：

• 控制流程跳轉(zhuǎn)、業(yè)務(wù)判斷；
• 決定數(shù)據(jù)庫寫入邏輯；
• 用嵌套 JSON/YAML 編寫“偽腳本”；
• 用配置拼裝函數(shù)調(diào)用順序。

一句話總結(jié)：

配置應(yīng)該是“輸入?yún)?shù)”，而不是“邏輯決策者”。

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

開發(fā)者要警惕一個現(xiàn)象：

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

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

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

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

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