使用@NestJS/Config 而不是使用 dotenv 來檢索 envvar 有什么優點（或缺點）嗎？在這兩種情況下，我都可以創建一個負責所有 envvars 的類，但我應該這樣做嗎？
我知道@NestJS/Config 在幕后使用 dotenv，但是有什么理由讓一個人選擇一個而不是另一個？
uj5u.com熱心網友回復：
我的理解是使用@nestjs/config很容易讓您將配置/環境變數作為專案中的模塊進行管理。所以它可以很容易地在不同的地方交換：
例如，如果您需要一組不同的配置進行測驗，則不必實際修改 process.env.xxx 或使用不同的 .env 檔案。
但是，如果您這樣做，則需要所有/大多數其他服務也使用此模式。如果您將所有其他服務都設為純函式匯出，那將不會有太大幫助。
uj5u.com熱心網友回復：
兩大優勢是能夠使用 Joi 或類驗證器或其他任何您想要的模式驗證器來確保您的 env 值在開始時是正確的，然后再嘗試在運行時訪問它們并出現錯誤。較早的反饋回圈意味著以后的故障更少。另一個很大的優勢是使用 DI 意味著它更容易（通常）在測驗用例中模擬 env 變數值，而不必分配給process.env它自己。速度也略有提升，因為 Nest 會快取該值，因此如果您再次讀取它，則無需從 讀取process.env，但除此之外沒有太多可提及的。如果您不想使用它，請不要覺得必須使用它。還有一個缺點是不能使用ConfigService內部裝飾器
轉載請註明出處，本文鏈接：https://www.uj5u.com/yidong/403077.html
標籤：
下一篇：在不同的位置等待產生不同的結果