什麼是 Env 以及什麼時候該用 Env？

前言

這一篇算是簡單聊一下什麼是 Env 以及什麼時候該用 Env，如果你對於 Env 沒有概念的話，或許這一篇會對你有一定程度的幫助了解 Env。

什麼是 Env

首先我們先來科普一下什麼是 Env，Env 全名是 Environment 中文又稱環境變數，不論是前端或者後端開發上都是非常常見的東西。

那麼 Env 主要是拿來做什麼呢？通常是拿來存放一些比較敏感的資訊，例如常見的…

• key(金鑰)
• secret(密碼)
• token(權杖)
  …等等。

因為我們的程式碼裡面絕對不能出現任何敏感資訊，因此我們會把這些敏感資訊放在 Env 裡面，然後在程式碼中使用 Env 來取得這些敏感資訊。

通常 Env 的檔案會叫做 .env，而你有可能會看到以下類型的 .env 檔案

• .env
• .env.development
• .env.production
• .env.test

這些都是不同的 Env 檔案，可以讓你在不同的環境下取用不同的 Env，例如在開發環境下使用 .env.development，而在正式環境下使用 .env.production。

通常來講我們不會把 .env 加入到 Git 版本控制內，如前面所說 .env 檔案主要是放置敏感資訊，因此 .env 通常會被加入到 .gitignore，這樣子才不會不小心把敏感資訊上傳到遠端儲存庫上。

Note
假設你真的不小心把 .env 上傳到遠端儲存庫了，那麼我會建議你立刻去刪除你的遠端儲存庫，並把 .env 內的資訊更換掉，因為當你上傳那一刻你的敏感資訊就有可能已經被取得了。（不論儲存庫是否為私人儲存庫）

而 .env 的撰寫格式大多都是以下這樣

KEY=VALUE

除此之外，通常有一種 .env 檔案我們並不會加入到 .gitignore，那就是 .env.example，而這個檔案只會有單純的 key 而不會有 value

KEY=

這個檔案的目的主要是方便其他開發者知道這個專案會需要填寫哪些 Env，而這些 Env 的 key 通常都會有一些說明，你可以參考我先前開源的這一份「妙麗·格蘭傑」專案。

怎麼使用 Env

通常來講，我們會先建立一個 .env.example 檔案，然後把這個檔案複製一份並命名為 .env，接著內容可能是這樣

KEY=IsRayNotArray

然後我們會使用 Dotenv 這個套件來讀取 Env，而 Dotenv 這個套件的使用方式非常簡單，只需要在你的程式碼中引入這個套件，然後呼叫 config() 方法即可。

require('dotenv').config()

Note
如果想切換不同的 Env 檔案，你可以在呼叫 config() 方法時傳入一個參數，例如：config({ path: '.env.development' })，這樣子就可以讀取 .env.development 這個檔案了。

接著你就可以使用 process.env 來取得你的 Env 內容，例如：

console.log(process.env.KEY)

當然上方是以 Node.js 為例，如果你是使用 PHP 的話，你可以使用 getenv() 來取得 Env 內容，例如：

echo getenv('KEY');

除此之外，通常來講主機商的後台環境中，都會有一個 Environment 區塊給你填寫你的 Env。

以上就只是稍微小小的介紹 Env 的使用方式而已。

什麼時候該用 Env

那麼接下來問題來了

『什麼時候該用 Env？』

我想這應該會是滿大的疑問點，首先剛剛有提到使用 Env 最常見的場景就是存放敏感資訊，例如：金鑰、密碼、Token 等等，但是其實我們有時候不單只會把敏感資訊放在 Env 裡面，我們也會把一些常用的設定放在 Env 裡面，例如：網站的名稱、網站的網址、網站的 Logo 等等這些都有可能，完全取決於你的需求以及程式碼的架構。

例如…妙麗·格蘭傑 專案中我就將 OpenAI(一款人工智慧 API) 的 Model 放在 Env 中，這樣子當我想要切換模型時，就只需要更改 Env 的值即可，而不需要去修改程式碼。

因為 Env 可以使用的場景非常的多樣，所以你也可以把 Env 看成一個網站的設定檔。

Env 的注意事項

那麼接下來我們來講更細的部分，也就是前端與後端開發上的 Env 使用差別與注意事項。

首先以比較簡單的後端來講，當系統部署於雲端時，你可以在後台的 Environment 區塊中填寫你的 Env，這樣子你的 Env 就會被儲存在雲端的伺服器上，而你的程式碼就可以直接使用 process.env 來取得 Env 內容，以 render.com 畫面為例：

這些 Env 內容會在程式碼運行時，自動帶入到你的程式碼中，本質上與你在本地開發是相同的，而後端程式碼本身是運行在伺服器上的，所以你的 Env 非常的安全，請注意我這邊提到了「非常的安全」這件事，稍後我會再來講為什麼。

在前端開發上，也很常使用 env 的技巧，以 Vite 為利，我們也是一樣建立 .env 檔案，接著在程式碼中撰寫：

console.log(import.meta.env.VITE_KEY);

透過這種方式就可以讓我們輕鬆的在 Vite 裡面使用 Env，但是這邊要注意一件事情，在前端中的 env 並不會放置敏感資訊，因為前端的程式碼是直接在瀏覽器上執行的，所以你的 Env 內容其實是可以被看到的。

這是什麼意思呢？假設我使用了 npm create vue@3 建立了一個專案，接著我在專案中建立了一個 .env 檔案，內容如下：

VITE_API_URL=https://api.example.com

並在 App.vue 中撰寫：

<script setup>
fetch(import.meta.env.VITE_API_URL)
  .then(response => response.json())
  .then(json => console.log(json))
</script>

<template>
  <div>
    這是一句話
  </div>
</template>

<style scoped>
</style>

接著立刻輸入 npm run build (將程式碼編譯)，編譯完成後我們進入到 dist 資料夾中找到 index-xxxx.js 檔案

然後我們在裡面搜尋 https://api.example.com，可以發現我們的 Env 內容已經被直接暴露在程式碼中

因此其實前端的 Env 並不適合放一些敏感資訊，比較適合作為一些常用的設定管理，例如：API Url、網站標題等，比較重複性高，未來若要調整可以一次調整的設定，而這也是為什麼我在前面說「後端的 Env 非常的安全」，因為後端的程式碼是運行在伺服器上，而前端的程式碼是直接在瀏覽器上執行的，所以使用者只要將你的程式碼下載下來，就可以直接看到你的 Env 內容。

最後我們來總結一下 Env 的幾個重點

• .env 不可以加入到版本控制內，最多只能加入 .env.example 檔案(value 請務必清空)，並且在 README 中說明如何建立 .env 檔案
• 不可以將敏感資訊加入到版本控制內，例如：資料庫密碼、金鑰等，請務必確保 .gitignore 內有將 .env 檔案忽略
• 前端的 Env 不適合放置敏感資訊，因為前端的程式碼是直接在瀏覽器上執行的，所以你的 Env 內容其實是可以被看到的

以上差不多就是你在使用 Env 時應該要注意的事情。

最後這邊讓我稍微業配一下 README.md 的撰寫方式，因為我覺得這是一個很重要的部分，如果你的 README.md 沒有寫好，那麼你的專案就很難被人看懂及還原，所以我推薦你可以參考我先前分享的 README Template。