環境變數在哪：從入門到精通，深度解析跨平台配置奧秘

Byadmin

Table of Contents

環境變數在哪？快速解答與深度探索

嘿，你是不是也曾遇過這樣的困擾？明明安裝了軟體，或者設定了開發環境，結果系統卻老是跟你說「找不到指令」？或者某個程式怎麼跑都怪怪的？這時候，很多時候問題的根源，很可能就指向了那個有點神祕、又有點重要的「環境變數」。那麼，環境變數到底在哪裡呢？別急，我們今天就來好好聊聊這個話題。

簡而言之，環境變數是作業系統提供的一種動態命名值，它會影響到正在執行中的程序（程式）的行為。這些變數儲存的位置與設定方式，會因為你使用的作業系統（Windows、Linux、macOS）以及你希望它生效的範圍（全系統、特定使用者、或僅當前會話）而有所不同喔。

  • 在 Windows 系統上： 你可以透過「系統內容」>「進階」>「環境變數」的圖形化介面來查看和修改。當然，也可以利用命令提示字元（Command Prompt）的 `set` 或 PowerShell 的 `Get-Item Env:` 來快速檢視，或是用 `setx` 指令進行設定。更深層次的變動則會牽涉到系統登錄檔（Registry）啦。
  • 在 Linux 和 macOS 系統上： 環境變數通常會配置在你的 Shell 設定檔裡頭，像是使用者家目錄下的 `.bashrc`、`.zshrc` 或 `.profile` 等。系統全域的設定則可能在 `/etc/environment` 或 `/etc/profile` 等檔案中。想快速查看，用 `env` 或 `printenv` 指令就能一目了然囉。

是不是覺得有點複雜？別擔心，這篇文章會帶你一步步拆解，從基礎概念到各個作業系統的實際操作，讓你徹底搞懂環境變數的奧秘！

環境變數，到底是什麼玩意兒？為什麼我們需要它？

首先，讓我們來搞懂「環境變數」這個詞。你可以把它想像成一個個寫著「設定值」的小紙條，作業系統或你的程式在執行時，會去翻閱這些小紙條，看看自己該怎麼做。這些設定值不是寫死在程式碼裡，而是可以彈性地依據環境來調整，這就是它「環境」的意義所在。

環境變數的定義與核心價值

從技術層面來看，環境變數就是一組鍵值對（key-value pair），例如 `PATH=/usr/local/bin:/usr/bin`，這裡的 `PATH` 就是鍵，而後面的路徑字串就是值。當你執行一個指令或程式時，它就可以讀取這些變數，來決定它的行為，像是去哪裡找程式、用什麼語言顯示介面，或是連接哪個資料庫等等。

那麼，為什麼要有它呢？

  1. 彈性配置： 想像一下，如果你開發一個程式需要連接資料庫，資料庫的位址在開發環境和正式環境中可能不同。如果把位址寫死在程式碼裡，每次部署到不同環境就要修改一次程式碼，然後重新編譯，這得多麻煩啊！有了環境變數，你只需要在不同環境中設定不同的資料庫位址變數，程式就能自動適應了。這大大提高了軟體的彈性與可維護性喔。
  2. 抽象化與安全性： 有些敏感資訊，像是 API 金鑰、密碼等等，絕對不能直接寫在程式碼裡然後上傳到版本控制系統（Git）！這時候，把這些資訊設定成環境變數，程式在執行時再去讀取，就能避免這些敏感資訊的洩漏。這也是資訊安全很重要的一環呢。
  3. 系統行為調整： 許多作業系統的內建指令或第三方軟體，也會依賴環境變數來調整自己的行為。最典型的就是 `PATH` 變數，它告訴 Shell（命令列介面）去哪些目錄下尋找你輸入的指令。如果沒有正確設定 `PATH`，你可能會發現有些指令根本無法執行呢。

系統變數 vs. 使用者變數：這兩個有什麼不一樣？

環境變數根據其生效的範圍，可以粗略地分為兩種主要類型：

  • 系統變數 (System Variables)： 這些變數是對整個作業系統上的所有使用者和所有程式都生效的。也就是說，不論哪個使用者登入，不論哪個程式啟動，都能存取到這些變數。通常，修改系統變數需要管理員權限，而且變動後可能需要重新啟動系統或服務才能完全生效。
  • 使用者變數 (User Variables)： 顧名思義，這些變數只對設定它的那個使用者有效。當該使用者登入後，其啟動的任何程式都能存取這些變數。其他使用者登入時，則看不到或存取不到這些變數。設定使用者變數通常不需要管理員權限。

在實際應用中，我們會根據變數的重要性、通用性以及安全性考量來決定它應該是系統變數還是使用者變數。例如，作業系統的核心路徑通常會是系統變數，而你個人開發工具的路徑則會是使用者變數。

Windows 系統下的環境變數在哪？手把手教你找！

在 Windows 系統中，環境變數的設定相對來說比較直覺，但也有些深層的細節值得我們探索。就讓我們一起來看看吧！

圖形化介面操作：最簡單的設定方式

對於大多數 Windows 使用者來說，透過圖形化介面（GUI）來設定或查看環境變數是最常見也最推薦的方式。步驟如下：

  1. 開啟「系統內容」：

    • 在 Windows 10/11 上，你可以在開始選單的搜尋框輸入「環境變數」，然後點選「編輯系統環境變數」。
    • 或者，在「檔案總管」中，右鍵點擊「本機」（或「我的電腦」），選擇「內容」，然後在左側或相關設定中找到「進階系統設定」。

    這會開啟一個名為「系統內容」的小視窗。

  2. 進入「環境變數」設定：

    在「系統內容」視窗中，切換到「進階」分頁，你會看到下方有一個「環境變數」按鈕。點擊它。

    這時會彈出一個「環境變數」的視窗，這裡就是你主要操作的場景囉！

  3. 認識「使用者變數」與「系統變數」：

    在這個視窗裡，你會看到上下兩個區塊：

    • 上方區塊是「使用者變數 (XXX 的使用者變數)」： 這裡列出的變數只對你目前登入的使用者帳戶生效。你可以自由新增、編輯或刪除這些變數。
    • 下方區塊是「系統變數」： 這些變數對所有使用者和所有程式都有效。修改這些變數通常需要管理員權限，而且要特別小心，因為不當的修改可能會影響系統穩定性喔！

  4. 新增、編輯與刪除：

    無論是使用者變數還是系統變數，你都可以點擊相對應的「新增」、「編輯」或「刪除」按鈕來進行操作。舉個例子，如果你想在 `PATH` 變數中加入一個新的路徑，可以選中 `PATH` 變數，點擊「編輯」，然後在彈出的視窗中新增你的路徑。記住，不同路徑之間要用分號 (`;`) 隔開喔！

  5. 確認變更：

    完成所有修改後，記得一路點擊「確定」來關閉所有視窗，這樣你的變更才會生效。很多時候，對於應用程式來說，你可能需要重新啟動命令提示字元、PowerShell 或相關程式，甚至重開機，變數才能被正確讀取到喔。

我個人經驗是，剛修改完環境變數，最常遇到的就是程式還是找不到路徑，這時候十之八九是因為你沒有重新啟動程式或是命令列視窗。別小看這個小動作，可是能省下很多找 Bug 的時間呢！

命令列/PowerShell 操作：開發者的好幫手

對於開發者或系統管理員來說，透過命令列或 PowerShell 來操作環境變數，會更加高效與彈性。

`set` 指令：查看當前會話變數

在命令提示字元（CMD）中，直接輸入 `set`，然後按下 Enter，你就會看到當前會話中所有的環境變數及其值。這個指令很方便，但要注意，它只顯示當前命令列視窗可用的變數，而且透過 `set VARIABLE=VALUE` 設定的變數也只對當前會話有效，關閉視窗後就會消失囉。

set

如果你想看特定的變數，可以這樣用：

echo %PATH%

記得在 Windows 中，變數名稱前後要用百分比符號 (`%`) 包起來。

`setx` 指令：設定持久化的變數

`setx` 指令就厲害了，它可以設定永久性的環境變數，無論是使用者變數還是系統變數。這表示即使你關閉了命令提示字元，這些變數下次開啟時也依然存在。

  • 設定使用者變數：

    setx MY_VARIABLE "我的值"

    這會將 `MY_VARIABLE` 設定為使用者變數。

  • 設定系統變數：

    setx MY_SYSTEM_VARIABLE "系統值" /M

    加上 `/M` 參數，表示將其設定為系統變數。這通常需要管理員權限喔。

  • 在 PATH 中新增路徑：

    setx PATH "%PATH%;C:\My\New\Path"

    這會將 `C:\My\New\Path` 加入到現有的 `PATH` 變數中。但這裡要特別注意，`setx` 對於 `PATH` 這類較長的變數，有時會有字串長度限制的問題，可能會截斷你的路徑。所以在處理 `PATH` 這種情況時，我個人還是比較推薦透過 GUI 或者 PowerShell 來操作，會更安全一點。

PowerShell Cmdlet：彈性與功能兼具

PowerShell 提供了更強大且一致的物件導向方式來管理環境變數。它才是 Windows 系統管理未來的趨勢啦！

  • 查看當前會話變數：

    Get-ChildItem Env:

    或簡寫成：

    gci Env:

    查看特定變數：

    $env:PATH

    在 PowerShell 中，環境變數以 `$env:` 作為前綴。

  • 設定當前會話變數：

    $env:MY_TEMP_VAR = "這只是暫時的"

    同樣的，這種設定只對當前 PowerShell 會話有效。

  • 設定持久化的變數：

    要設定持久化的環境變數，PowerShell 提供了 `[System.Environment]` 類別的方法。

    • 設定使用者變數：

      [System.Environment]::SetEnvironmentVariable("MY_USER_VAR", "我的使用者值", "User")

    • 設定系統變數：

      [System.Environment]::SetEnvironmentVariable("MY_SYSTEM_VAR", "我的系統值", "Machine")

      這也需要管理員權限喔。

    • 從 PATH 中新增路徑（更安全的方式）：

      $oldPath = [System.Environment]::GetEnvironmentVariable("PATH", "User")
      [System.Environment]::SetEnvironmentVariable("PATH", "$oldPath;C:\My\New\Path", "User")

      這樣就能避免 `setx` 可能造成的截斷問題。

  • 刪除環境變數：

    [System.Environment]::SetEnvironmentVariable("VARIABLE_TO_DELETE", $null, "User")

    將值設定為 `$null` 即可刪除。記得指定範圍 (“User” 或 “Machine”)。

註冊表 (Registry) 的角色：環境變數的深層儲藏所

其實，Windows 環境變數的設定，最終都會儲存在系統的註冊表（Registry）裡頭。它就像是 Windows 系統的大腦，所有設定資訊都收納其中。

  • 系統變數儲存在：

    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Environment

  • 使用者變數儲存在：

    HKEY_CURRENT_USER\Environment

雖然透過修改註冊表也能設定環境變數，但我強烈不建議新手直接去動註冊表！ 因為一不小心改錯了，可能會導致系統不穩定甚至無法啟動。還是乖乖用 GUI 或 PowerShell 的方法吧，它們提供了更安全的抽象層，避免你直接接觸到這些底層的設定。

Linux/macOS 系統下的環境變數在哪？Shell 的世界等你探索！

相較於 Windows 的圖形化介面，Linux 和 macOS 系統下的環境變數管理，更多的是與你的 Shell 環境（例如 Bash、Zsh 等）和各種設定檔緊密相連。這也是我覺得它比較有「程式設計感」的地方啦！

理解 Shell 環境：你的指令指揮中心

在 Linux 和 macOS 中，你與系統互動的介面通常是「終端機」（Terminal），而終端機裡面運行的就是「Shell」。最常見的 Shell 有 Bash (Bourne Again SHell) 和 Zsh (Z Shell)，macOS 預設已經從 Bash 換成 Zsh 了。

Shell 在啟動時，會讀取一系列的設定檔，這些設定檔就是環境變數的主要藏身之處。這些設定檔的內容通常是 Shell 指令，用來初始化環境，其中就包括了設定環境變數的指令。

查看環境變數：常用的指令們

想要知道當前 Shell 環境中有哪些環境變數？很簡單，有幾個指令可以用：

  • `env`： 顯示所有當前 Shell 繼承自父程序並可供子程序使用的環境變數。

    env

  • `printenv`： 功能類似 `env`，也可以顯示所有環境變數。如果你想看特定變數，可以直接在後面加上變數名稱。

    printenv PATH

  • `echo $VARIABLE_NAME`： 這是最常用來查看單一環境變數值的方式。在 Shell 中，要引用一個環境變數的值，需要在變數名稱前加上 `$` 符號。

    echo $HOME

    echo $SHELL

  • `set`： 這個指令會顯示所有 Shell 變數、環境變數以及 Shell 函數。它的輸出量會比 `env` 或 `printenv` 大很多，因為它包含了更多 Shell 內部的變數。

    set

臨時設定：只對當前會話有效

有時候，你可能只需要在當前這個終端機視窗中，讓某個變數生效，關掉視窗後就無所謂了。這時候，你可以使用 `export` 指令。

export MY_TEMP_VAR="這只是暫時的"

這條指令會將 `MY_TEMP_VAR` 設定為環境變數，並且讓所有從當前 Shell 啟動的子程序也能繼承這個變數。一旦你關閉了這個終端機視窗，這個變數就會消失，不會影響到其他終端機會話或是下次開機喔。

永久設定：多種檔案配置，搞清楚就不怕！

這才是 Linux/macOS 環境變數設定的精髓所在！不同的設定檔有不同的生效範圍和載入時機。理解它們的差異，你就能精準地控制你的環境變數。

使用者層級的設定檔

這些檔案通常位於你的家目錄 (`~` 或 `$HOME`) 下，並且以 `.` 開頭，代表是隱藏檔案。

  • `~/.profile`：

    • 生效時機： 僅在登入 Shell (login shell) 啟動時讀取。所謂登入 Shell，就是你透過文字模式（例如 SSH 遠端連線）登入系統，或是圖形介面登入後開啟的第一個終端機視窗。
    • 用途： 通常用於設定一些對所有 Shell 類型都通用的環境變數，例如 `PATH`、`EDITOR` 等。它也會去檢查並執行 `~/.bashrc` 或 `~/.zshrc`。
  • `~/.bash_profile` (Bash)：

    • 生效時機： 僅在 Bash 的登入 Shell 啟動時讀取。如果這個檔案存在，Bash 不會再去讀取 `~/.profile`。
    • 用途： 專為 Bash 登入 Shell 設計的配置。許多人習慣在這裡呼叫 `source ~/.bashrc`，確保互動式非登入 Shell 的設定也能被載入。
  • `~/.bashrc` (Bash)：

    • 生效時機： 在每次互動式非登入 Shell (interactive non-login shell) 啟動時讀取。這包含了你打開的每一個新的終端機視窗，或是從已經登入的 Shell 中再開啟一個子 Shell。
    • 用途： 主要用於設定 Shell 別名 (aliases)、函數 (functions) 和 Shell 提示字元 (prompt) 等，以及其他非環境變數的 Shell 設定。但如果你在這裡設定環境變數，通常也沒問題，因為 `~/.profile` 或 `~/.bash_profile` 會去 source 它。
  • `~/.zshrc` (Zsh)：

    • 生效時機： 這是 Zsh 的主要設定檔，在每次 Zsh 啟動時（無論是登入 Shell 還是非登入 Shell，互動式還是非互動式）都會讀取。
    • 用途： Zsh 環境變數、別名、函數、提示字元等所有個人化的設定，通常都寫在這裡。macOS 預設使用 Zsh，所以這個檔案對 macOS 使用者來說非常重要。

我的經驗是，剛開始常常搞混這些檔案。簡單來說，如果你用 Bash，通常會把通用環境變數放在 `~/.profile` 或 `~/.bash_profile`，而把 Shell 功能（像 alias）放在 `~/.bashrc`。如果用 Zsh，那幾乎所有東西都丟到 `~/.zshrc` 就對了，它功能很強大，通常會涵蓋其他 Shell 的多個設定檔功能。

系統層級的設定檔

這些檔案會影響到所有使用者。修改它們需要管理員權限 (root 權限)。

  • `/etc/environment`：

    • 生效時機： 系統啟動時被載入。
    • 用途： 用於設定系統全域的環境變數，格式通常是簡單的 `KEY=VALUE` 每一行一個。這個檔案很簡潔，只用於設定環境變數，不會執行任何 Shell 指令。
  • `/etc/profile`：

    • 生效時機： 系統上所有使用者的登入 Shell 啟動時讀取。
    • 用途： 通常會包含一些系統管理員希望對所有使用者生效的通用設定。它也可能會去呼叫 `/etc/profile.d/` 目錄下的腳本。
  • `/etc/bash.bashrc` (Debian/Ubuntu) 或 `/etc/bashrc` (CentOS/RHEL)：

    • 生效時機： 針對所有使用者，在每次 Bash 互動式非登入 Shell 啟動時讀取。
    • 用途： 設定一些全系統的 Shell 別名、函數等。
  • `/etc/profile.d/`：

    • 生效時機： 位於這個目錄下的腳本檔案（通常以 `.sh` 結尾）會被 `/etc/profile` 呼叫執行。
    • 用途： 這是一個很棒的模組化機制！每個應用程式或服務都可以把自己需要的環境變數或 Shell 設定，放在一個獨立的 `.sh` 檔案裡，方便管理和更新，而不會去修改 `/etc/profile` 這個主要檔案。

macOS 特有考量：GUI 應用程式的環境變數

對於 macOS 使用者來說，除了上述 Shell 設定檔外，還有一個特別的地方需要注意，那就是 GUI 應用程式的環境變數。因為 GUI 應用程式通常不是直接從 Shell 啟動，所以它們可能不會讀取你的 `.bashrc` 或 `.zshrc` 中的設定。

  • `launchd`： macOS 系統的服務管理程序 `launchd` 負責啟動大部分的系統服務和應用程式。它有自己管理環境變數的方式。

    • 你可以使用 `launchctl setenv VARIABLE_NAME VALUE` 來為 `launchd` 設定環境變數。但這種方式通常只在當前會話有效，或者需要特定的設定才能持久化。
    • 比較傳統的做法是透過 `/etc/launchd.conf` 或在你的登入項目中添加腳本來設定。不過，從 macOS Catalina 開始，這些方式逐漸變得複雜或不推薦。
    • 目前最可靠的方式： 對於需要特定環境變數的 GUI 應用程式，最推薦的做法還是修改其啟動腳本，或者直接在應用程式本身的設定中提供這些變數。許多開發者工具（例如 IDE）也有內建設定環境變數的功能。

老實說，在 macOS 上，讓 GUI 應用程式繼承 Shell 環境變數一直都是個小麻煩。我自己的經驗是，為了開發方便，會盡量讓所有開發工具都透過 Homebrew 安裝，並確保它們的路徑都被正確地加到 `PATH` 裡。如果真的遇到 GUI 應用程式讀不到變數，通常會從應用程式自己的文件找尋是否有建議的設定方式。

優先順序與載入機制：誰說了算？

當這麼多設定檔都可能設定環境變數時，一個變數最終會是什麼值，就取決於它們的載入順序和優先級了。

  1. Shell 啟動時的指令行參數： 如果你在啟動 Shell 或執行程序時直接傳入環境變數，它會是最高的優先級。
  2. 當前 Shell 會話中 `export` 的變數： 這些變數只在當前會話有效，但它們會覆蓋更早載入的同名變數。
  3. 使用者家目錄下的設定檔： 像是 `~/.zshrc`、`~/.bashrc`、`~/.profile` 等。它們的執行順序可能因 Shell 類型和登入方式（login vs. non-login, interactive vs. non-interactive）而異。通常，`~/.bash_profile` / `~/.profile` 會在登入 Shell 時執行，並可能再 `source ~/.bashrc`。
  4. 系統全域的設定檔： 例如 `/etc/environment`、`/etc/profile`、`/etc/bash.bashrc` 等。這些是最早被載入的，影響範圍最廣。

Login Shell vs. Non-login Shell：
Login Shell 是指你登入系統（例如透過 SSH）時啟動的第一個 Shell。它會讀取 `/etc/profile`、`~/.profile` 或 `~/.bash_profile`。
Non-login Shell 是指你在已經登入的 Shell 中再開啟一個新的終端機視窗，或者從腳本中啟動的 Shell。它通常只讀取 `~/.bashrc` 或 `~/.zshrc`。這就是為什麼有些變數在遠端 SSH 裡是 OK 的，但開一個新視窗卻又跑掉的原因！

常見的環境變數與應用情境：它們到底用在哪？

了解了環境變數在哪裡、怎麼設定，現在來看看一些我們日常生活中最常遇到、也最實用的環境變數及其應用情境吧！

`PATH`：程式執行路徑的救星

這絕對是最最最常見也最重要的環境變數之一！`PATH` 變數會告訴你的 Shell 或作業系統，當你輸入一個指令時（例如 `ls`、`git`、`node`），應該去哪些目錄下尋找這個可執行檔案。

例如，`PATH` 的值可能像這樣：

/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/Users/youruser/bin:/usr/local/go/bin

這裡的每個路徑都用冒號 (Linux/macOS) 或分號 (Windows) 隔開。當你輸入 `go` 指令時，系統會從左到右依序在這些目錄裡尋找 `go` 這個可執行檔。一旦找到，就執行它；如果找遍了所有路徑都沒找到，就會報錯「command not found」。

應用情境： 安裝新的開發工具（如 Node.js、Python、Go、Java），如果它們的執行檔不在系統預設的 `PATH` 中，你就需要把它們的安裝路徑加到 `PATH` 裡，這樣才能在任何地方直接輸入指令來執行這些工具。

`HOME` / `HOMEPATH`：你的家目錄在哪？

這個變數指向你目前使用者的家目錄。在 Linux/macOS 上是 `HOME`，通常是 `/home/yourusername` 或 `/Users/yourusername`。在 Windows 上則是 `HOMEPATH`，例如 `C:\Users\yourusername`。

應用情境： 很多程式會把你的個人設定檔、歷史記錄、或下載的資料預設存放在家目錄下。有了這個變數，程式就能很方便地找到這些使用者專屬的資源，而不用寫死路徑。

`LANG` / `LC_ALL`：語系設定，讓你的系統說你聽得懂的話

這些變數影響著系統和應用程式的語言、地區設定、日期時間格式、貨幣符號等等。

  • `LANG`：指定主要的語系。例如 `zh_TW.UTF-8` 表示台灣繁體中文，使用 UTF-8 編碼。
  • `LC_ALL`：如果設定了這個變數，它會覆蓋所有其他 `LC_*` 變數（如 `LC_CTYPE`, `LC_TIME` 等），強制系統使用單一的語系設定。

應用情境： 如果你的系統或某些程式顯示亂碼，或者日期格式不是你習慣的樣式，很可能就是這些語系變數設定不正確。調整它們可以讓你的使用體驗更在地化。

`JAVA_HOME`, `M2_HOME` 等開發工具專用變數

許多大型的開發框架或工具，為了方便管理，會要求你設定一個指向它們安裝根目錄的專用環境變數。

  • `JAVA_HOME`：指向 Java 開發套件（JDK）的安裝目錄。許多 Java 應用程式或建置工具（如 Maven、Gradle）都會依賴這個變數來找到 Java 執行環境。
  • `M2_HOME`：指向 Maven 的安裝目錄。
  • `GOPATH`：Go 語言工作區的路徑。

應用情境： 當你有多個 Java 版本、Maven 版本並存時，透過調整 `JAVA_HOME` 或 `M2_HOME`，就能輕鬆切換目前要使用的版本，而不用去改動更底層的設定。

API 金鑰與敏感資訊：環境變數的安全性考量

這是我覺得環境變數最實用也最關鍵的應用之一了。在現代應用程式開發中，我們經常需要使用各種 API 金鑰、資料庫連線密碼、第三方服務的認證資訊等敏感資料。

應用情境：
將這些敏感資訊以環境變數的形式儲存，而不是直接寫在程式碼（硬編碼）裡，有以下幾個巨大的好處：

  1. 安全性： 避免敏感資訊不小心被提交到版本控制系統（如 Git）的公開儲存庫中。一旦程式碼公開，這些金鑰就曝光了，後果不堪設想。
  2. 環境分離： 開發環境、測試環境、正式環境，它們使用的 API 金鑰可能都不同。透過環境變數，可以在不同的部署環境中設定不同的值，讓程式碼保持通用。
  3. 部署便利： 在 CI/CD（持續整合/持續部署）管線中，CI/CD 工具通常會提供安全的方式來設定環境變數（例如 GitHub Actions 的 Secrets、GitLab CI/CD 的 Variables），這樣部署時就能自動注入這些敏感資訊，無需人工干預。

不過要注意，即便是環境變數，也應避免在共享的開發機器上放置過於敏感的生產環境密鑰。最佳實踐是讓每個環境（開發、測試、生產）都有自己獨立的環境變數設定機制。

環境變數設定的經驗法則與最佳實踐：讓你的環境更穩定！

「工欲善其事，必先利其器」，搞懂環境變數後，怎麼用得好、用得巧，也是一門學問。這裡分享一些我個人覺得很實用的經驗法則和最佳實踐：

1. 安全性至上：敏感資訊永遠不要硬編碼

這點前面提過了，但真的太重要了，所以再強調一次！API 金鑰、資料庫密碼、第三方服務認證等，這些絕對、絕對、絕對不要直接寫在程式碼裡。請務必將它們儲存在環境變數中，並確保這些變數在版本控制系統之外管理。

資安專家常說：「程式碼是藝術，憑證是鑰匙。」你的程式碼可以公開，但鑰匙必須藏好。

2. 模組化你的設定：善用設定檔或專案特有變數

對於專案特定的環境變數，可以考慮使用以下方法：

  • 專案層級的 `.env` 檔案： 許多開發框架（如 Node.js 的 Dotenv、Python 的 python-dotenv）支援在專案根目錄下放置一個 `.env` 檔案，裡面定義專案所需的環境變數。這個檔案通常會被加入到 `.gitignore` 中，確保它不會被提交到版本控制。
  • Shell 腳本： 針對特定專案或工作流程，可以撰寫一個小的 Shell 腳本，在其中 `export` 所需的環境變數，然後在開始工作前 `source` 這個腳本。這樣可以將相關變數集中管理。

3. 版本控制的藝術：哪些不該被 Git 追蹤？

承接上一點，所有包含敏感資訊的設定檔（例如 `.env`）都應該被明確地排除在版本控制之外。在你的 `.gitignore` 檔案中加入這些檔案，確保它們不會被不小心提交出去。這是一個很常見的疏忽，一旦發生，處理起來非常麻煩！

4. 明確變數的生效範圍：避免不必要的干擾

在設定環境變數時，思考清楚這個變數應該在哪個範圍內生效：

  • 全系統範圍 (System-wide)： 只有那些對所有使用者和所有程式都必要的變數，才應該設定為系統變數（例如 `/etc/environment` 或 Windows 的系統變數）。
  • 使用者範圍 (User-specific)： 針對你個人開發環境的工具路徑、喜好設定等，設定為使用者變數即可（例如 `~/.bashrc`、`~/.zshrc` 或 Windows 的使用者變數）。
  • 程序範圍 (Process-specific)： 對於只在單次執行、或短期內有效的變數，直接在指令前加上變數定義，或使用 `export` 臨時設定，是最乾淨的做法。

    MY_VARIABLE="臨時值" your_command_here

    或在 Shell 中：

    export MY_VARIABLE="臨時值"

5. 變更後記得重新載入：你的系統可能還在睡覺

這是我最常犯的錯誤，也是很多人會困惑的地方！當你修改了環境變數的設定檔（例如 `.bashrc` 或 `.zshrc`），或者透過 GUI 設定了變數後，這些變更並不會立即對所有正在執行的程序生效。

  • 對於 Shell 設定檔： 你需要手動 `source` 它，例如 `source ~/.bashrc`，或者乾脆關閉當前終端機視窗，再開一個新的。
  • 對於 Windows 系統變數： 通常你需要重新啟動相關的應用程式，甚至是重新開機，才能確保所有程式都能讀取到最新的變數值。

這就像是你更新了手機系統，通常也需要重啟一樣，讓新的設定真正啟動！

故障排除：當環境變數不聽使喚時，我該怎麼辦？

即使你按照步驟設定了，有時候環境變數還是會跟你唱反調，程式找不到、設定沒生效… 這時候別慌張，我們可以按照下面的步驟來排查問題：

  1. 確認拼寫錯誤： 最常見的問題就是變數名稱或值打錯字了！仔細檢查，大小寫敏感的系統（Linux/macOS）尤其要注意。
  2. 確認生效範圍：

    • 你設定的是使用者變數還是系統變數？
    • 你是在哪個 Shell 設定檔裡改的？它真的被載入了嗎？是不是登入 Shell 和非登入 Shell 的讀取邏輯搞混了？
    • 如果你是在 GUI 裡設定 Windows 變數，有記得一路「確定」嗎？

    用 `echo $VARIABLE_NAME` (Linux/macOS) 或 `echo %VARIABLE_NAME%` (Windows CMD) / `$env:VARIABLE_NAME` (Windows PowerShell) 檢查變數的實際值。

  3. 重新載入！重新載入！重新載入！：

    • 修改 Shell 設定檔後，記得 `source` 它，或者關閉舊終端機，開啟新終端機。
    • 修改 Windows 系統變數後，重新啟動應用程式或重新開機。

    這真的是一個很常被忽略，但卻常常解決問題的步驟。

  4. 檢查 PATH 變數的順序： 如果你是為 `PATH` 增加新路徑，確認新路徑的位置。如果新舊路徑下有同名的可執行檔，系統會優先執行 `PATH` 中靠前的那個。有時候你想要的程式在新的路徑，但舊路徑下卻有個同名舊版程式，就可能會導致執行錯誤。
  5. 檢查日誌檔 (Logs)： 有些應用程式會在啟動時將其讀取的環境變數記錄到日誌檔中。如果能找到相關的日誌，或許能從中找到端倪。
  6. 尋求幫助： 如果真的自己搞不定，別害羞！把你的作業系統、Shell 類型、設定步驟和遇到的錯誤訊息清楚地描述出來，到相關的技術論壇或社群（例如 Stack Overflow、PTT 的 Soft_Job 版）發問，通常會有熱心的大神幫忙的。

常見相關問題與專業詳細解答

Q1: 環境變數跟一般程式裡的變數有什麼不同？

這是一個很好的問題，它點出了環境變數的特別之處！

一般程式裡的變數（例如你在 C++ 裡宣告 `int x = 10;` 或 Python 裡 `name = “Alice”`），它們的生命週期和作用範圍通常都局限在程式碼內部。這些變數只在該程式執行時才存在，而且無法被其他不相關的程式直接存取。它們是程式內部邏輯運算的資料儲存空間。

而環境變數則完全不同。它們是由作業系統層面所維護的一組特殊變數，具有更廣泛的「環境」性質。它們的主要差異點在於：

  • 作用範圍： 環境變數通常可以被所有從設定它的 Shell 或系統啟動的子程序（包括你執行的程式）所繼承和讀取。它的生命週期可以超越單一程式的執行，甚至可以持續到系統重啟。
  • 共享性： 不同的程式可以共享同一組環境變數。例如，`PATH` 變數就是所有命令列工具共享的。
  • 設定方式： 環境變數通常透過作業系統提供的介面（例如 Windows 的系統內容、Linux 的 Shell 設定檔）來設定，而不是直接寫在程式碼裡。
  • 目的： 環境變數主要用於設定運行環境，影響程式的行為，例如指定程式的執行路徑、語言設定、資源位置或敏感認證資訊，而不是用於程式內部的計算或資料處理。

總之，你可以把程式裡的變數想像成你家裡自己用的抽屜，只有你自己能開；而環境變數則像是貼在你家門口或社區佈告欄上的資訊，所有進入你家或社區的人都能看到，並且會依照上面的指示來行動。

Q2: 我修改了 PATH，但程式還是找不到，為什麼？

遇到這種情況，不要慌，這幾乎是每個學習環境變數的人都會碰到的「經典問題」！原因通常有以下幾種，你可以逐一排查：

  1. 未重新載入 Shell 或程式： 這是最常見的原因。當你修改了環境變數設定檔（例如 `.bashrc`、`.zshrc`），或者在 Windows GUI 裡修改了變數後，你必須告訴當前正在運行的 Shell 或相關程式「重新讀取」這些變數。

    • Linux/macOS： 關閉當前終端機視窗，重新開啟一個新的，或者在當前視窗中執行 `source ~/.bashrc` (或對應你的設定檔) 來立即生效。
    • Windows： 關閉命令提示字元或 PowerShell 視窗，重新開啟一個新的。如果你修改的是系統變數，對於已經在背景運行的程式，可能需要重啟該程式，甚至是重新啟動電腦才能完全生效。
  2. PATH 路徑拼寫錯誤或順序問題：

    • 仔細檢查你新增的路徑是否完全正確，包括大小寫（Linux/macOS 區分大小寫）。
    • 確認路徑分隔符號是否正確：Windows 使用分號 `;`，Linux/macOS 使用冒號 `:`。
    • 路徑順序： `PATH` 是從左到右依序查找。如果你新增的路徑中包含了你想要執行的程式，但前面有另一個路徑下也存在一個同名但你不想執行的程式，那麼系統就會先找到並執行前面的那個。確保你想要的路徑在 `PATH` 中有足夠高的優先級（也就是在靠左的位置）。
  3. 程式本身不在該路徑下： 確保你新增到 `PATH` 中的，是包含該程式「可執行檔」的那個目錄，而不是程式的安裝根目錄。例如，如果是 `node` 指令，你應該將 `node` 可執行檔所在的目錄（通常是 `bin` 子目錄）加到 `PATH`。
  4. 檔案權限問題： 在 Linux/macOS 上，確保你想要執行的程式具有執行權限 (`chmod +x filename`)。

建議：修改 `PATH` 後，立即在新的終端機或命令列視窗中執行 `echo $PATH` (或 `echo %PATH%`) 來驗證變數是否已正確更新。然後再嘗試執行你的程式。

Q3: 環境變數會影響到我的所有程式嗎？

這個問題的答案是「不一定，但通常會」。讓我們細說一下：

環境變數的影響範圍，取決於它是如何被設定的，以及程式是如何啟動的：

  • 繼承性： 這是環境變數的一個核心特性。當一個程序啟動另一個程序（稱為子程序）時，子程序通常會繼承父程序的所有環境變數。這就像你的孩子會繼承你的姓氏一樣。
  • 系統變數的影響： 如果你設定的是系統級別的環境變數（例如 Windows 的系統變數，或 Linux 的 `/etc/environment`），那麼所有從作業系統啟動的程序（包括所有使用者開啟的程式、甚至背景服務）都會繼承這些變數。所以，這類變數的影響範圍確實是「所有程式」。
  • 使用者變數的影響： 如果你設定的是使用者級別的環境變數（例如 Windows 的使用者變數，或 Linux/macOS 的 `~/.bashrc`），那麼只有當你這個使用者登入後，且從你的 Shell 或圖形化桌面環境啟動的程式，才會繼承這些變數。其他使用者登入後，就不會受到你變數的影響。
  • 程式啟動方式： 即使是使用者變數，如果程式不是從你的 Shell 或 GUI 環境中啟動的（例如某些背景服務、定時任務 cron job），它們可能也不會讀取到你的使用者環境變數，因為它們有自己的啟動環境。
  • 程式內部的覆蓋： 某些程式設計得很聰明，它們在啟動時會先讀取環境變數，但隨後可能又透過自己的設定檔（例如 `config.ini`、`.yaml` 檔案）或者程式碼內部的邏輯，去覆蓋或修改這些變數的值。所以在這種情況下，環境變數的影響就可能被程式自身的邏輯所限制或改變。

所以總結來說，環境變數的影響範圍會根據其設定的層級（系統/使用者）和程式的啟動方式而有所不同。越是底層、越早被設定的環境變數，其影響範圍就越廣。如果你不確定，最好在程式運行前，使用 `echo` 或 `printenv` 確認相關變數的值，以確保其正確性。

Q4: 怎麼刪除一個環境變數？

刪除環境變數和設定一樣，會因為作業系統和生效範圍的不同而有不同的方法：

在 Windows 系統上：

  • 圖形化介面 (GUI)：

    跟設定時的步驟一樣，開啟「系統內容」>「進階」>「環境變數」視窗。在「使用者變數」或「系統變數」區塊中，找到你想要刪除的變數，選中它，然後點擊「刪除」按鈕。之後記得一路點擊「確定」來儲存變更。同樣地，可能需要重啟相關程式或電腦來讓變更完全生效。

  • PowerShell：

    你可以使用 `[System.Environment]::SetEnvironmentVariable` 方法，並將變數的值設定為 `$null` 來刪除它。記住要指定變數的範圍 (`”User”` 或 `”Machine”`)。

    [System.Environment]::SetEnvironmentVariable("VARIABLE_TO_DELETE", $null, "User")

    如果你想刪除系統變數，則需要管理員權限：

    [System.Environment]::SetEnvironmentVariable("VARIABLE_TO_DELETE", $null, "Machine")

  • 命令提示字元 (CMD)：

    `setx` 指令不直接支援刪除功能。你可以透過將變數設定為空值來「清空」它，但這並不是真正的刪除。如果需要完全刪除，請使用 GUI 或 PowerShell。

在 Linux/macOS 系統上：

  • 暫時刪除 (當前會話)：

    你可以使用 `unset` 指令來在當前 Shell 會話中刪除一個環境變數。這只對當前 Shell 及其子程序生效，關閉終端機後，該變數會再次出現（如果它是在設定檔中定義的話）。

    unset VARIABLE_TO_DELETE

  • 永久刪除 (修改設定檔)：

    要永久刪除一個環境變數，你需要找出當初設定它的那個設定檔（例如 `~/.bashrc`、`~/.zshrc`、`/etc/environment` 等），用文字編輯器開啟它，然後刪除或註解掉（在行首加上 `#`）設定該變數的那一行。
    刪除或註解後，記得要重新載入設定檔（例如 `source ~/.zshrc`）或者重新開啟終端機，才能讓變更生效。

    舉例來說，如果你的 `~/.bashrc` 裡有一行是 `export MY_VARIABLE=”myvalue”`，你只需要把這行刪掉或改成 `# export MY_VARIABLE=”myvalue”` 就可以了。

總之，刪除環境變數的關鍵在於找到變數的「源頭」，也就是它在哪裡被定義的，然後去修改或移除那個定義。確認變數是否真的被刪除，就用 `echo` 或 `printenv` 來檢查喔！

Q5: 在 Docker 或 CI/CD 管線中，環境變數又在哪裡？

在現代開發流程中，Docker 容器化和 CI/CD (持續整合/持續部署) 管線扮演著關鍵角色。在這些場景中，環境變數的處理方式會更為標準化和自動化，但核心概念仍然一樣。

在 Docker 中：

Docker 容器本質上是一個獨立的、隔離的運行環境，它有自己的一套環境變數。你在宿主機（Host machine）上設定的環境變數，預設並不會自動傳遞到 Docker 容器裡面去。在 Docker 中設定環境變數的方式主要有幾種：

  1. Dockerfile 中的 `ENV` 指令：

    你可以在 Dockerfile 中使用 `ENV` 指令來定義容器內部的環境變數。這些變數在容器構建時就已經設定好，並在容器運行時一直存在。

    FROM alpine:latest
    ENV MY_DOCKER_VAR="Hello from Dockerfile"
    CMD echo $MY_DOCKER_VAR

  2. `docker run -e` 或 `–env` 參數：

    當你執行 `docker run` 指令來啟動容器時，可以使用 `-e` 或 `–env` 參數來傳遞一個或多個環境變數。這種方式設定的變數會覆蓋 Dockerfile 中定義的同名變數。

    docker run -e MY_DOCKER_VAR="Override value" my_image

  3. Docker Compose 的 `environment` 區塊：

    如果你使用 Docker Compose 來管理多個容器服務，可以在 `docker-compose.yml` 檔案中的每個服務定義下，使用 `environment` 關鍵字來設定環境變數。

    services:
    web:
    image: my_web_app
    environment:
    - DATABASE_HOST=db.example.com
    - API_KEY=${API_KEY_FROM_HOST} # 可以從宿主機環境變數讀取

  4. Docker Secrets 或 Configs (安全性較高)：

    對於敏感資訊（如密碼、API 金鑰），Docker 提供了更安全的機制，例如 Docker Secrets (用於 Swarm 模式) 或 Docker Configs，它們不是直接暴露為環境變數，而是以檔案的形式掛載到容器內，並且只在需要時才提供給應用程式。這種方式比直接使用環境變數更安全。

在 CI/CD 管線中：

CI/CD 工具（如 Jenkins, GitLab CI/CD, GitHub Actions, CircleCI, Travis CI 等）都有內建的機制來管理和注入環境變數，這對於自動化部署敏感資訊至關重要。

  1. 專案/組織級別的變數：

    大多數 CI/CD 平台都允許你在專案或組織設定中定義環境變數。這些變數可以在整個 CI/CD 管線中的任何步驟被存取。通常還會有「Secrets」或「Masked Variables」的功能，用於儲存敏感資訊，這些資訊在日誌中會被自動遮蔽，提高安全性。

  2. 管線腳本中定義：

    你可以在 CI/CD 管線的腳本（例如 `.gitlab-ci.yml`, `.github/workflows/*.yml`）中直接定義環境變數，這些變數只對該管線的特定作業或步驟生效。

    GitHub Actions 範例：

    jobs:
    build:
    runs-on: ubuntu-latest
    env:
    MY_ENV_VAR: "Hello from CI"
    SECRET_TOKEN: ${{ secrets.GITHUB_TOKEN }} # 從 secrets 中安全獲取
    steps:
    - name: Print variable
    run: echo $MY_ENV_VAR

  3. 動態生成與注入：

    在某些複雜的管線中，環境變數的值可能是動態生成的（例如一個臨時的 API 金鑰），然後在後續的步驟中被注入和使用。

總體來說，在 Docker 和 CI/CD 環境中，環境變數是實現「配置即程式碼」（Configuration as Code）和安全部署的基石。透過這些工具提供的標準化介面，開發者可以更有效率、更安全地管理應用程式的各種運行參數。

結語

環境變數，這個看似不起眼卻又無處不在的系統元素，就像作業系統的毛細血管，承載著各種關鍵的資訊流。從你每天敲打的指令，到背後默默運行的服務，再到你精心打造的應用程式，它們都在默默地依賴著這些變數來運作。

希望透過這篇文章，你對「環境變數在哪」有了更清晰的理解，也掌握了在 Windows、Linux 和 macOS 系統上查找與設定它們的實用技巧。從此以後，當你的程式又「任性」地找不到路徑時，你就能更有自信地去排查問題，而不是一頭霧水啦！

記住，好的環境變數管理，能讓你的開發和系統管理工作事半功倍，不僅提高效率，更能增強系統的穩定性和安全性喔！下次遇到它，別再覺得它神祕了，它只是在等你去好好認識它罷了！

環境變數在哪