Configuration / Environments：Code 不該靠 Hard-code 才知道自己在哪裡

Learning outcomes

• 能區分 code、config、secret。
• 能建立 startup validation。
• 能避免環境 drift 與 hard-coded endpoint。
• 能理解 build-time config 與 runtime config 可能不同。

1. Hard-code 的問題

const apiUrl =
  "https://prod.example.com";

如果 test 也使用這段，就可能誤打 production。Environment difference 應有明確注入點。

2. Node environment input

const apiUrl =
  process.env.API_URL;

if (!apiUrl) {
  throw new Error(
    "API_URL is required"
  );
}

Environment variable 只是 config transport mechanism；敏感性仍依 value privilege 判斷。

3. Startup validation

function loadConfig(env) {
  const port =
    Number(env.PORT);

  if (!Number.isInteger(port)) {
    throw new Error(
      "Invalid PORT"
    );
  }

  return { port };
}

Fail fast 比等到第一個 request 才因 undefined config 崩潰更容易定位。

4. Environment matrix

dev:
  local API
  verbose logs

test:
  isolated DB
  deterministic config

prod:
  production API
  restricted secrets
  observability

重點不是每個 environment 都完全不同，而是差異要可追蹤、可驗證。

5. Build-time vs Runtime

前端 bundler 可能在 build 時把 public config 寫進 bundle；server process 則可能在 runtime 讀 env。不要把兩種 timing 混為一談。

Project checkpoint：Environment Contract

config schema:
  API_URL
  PORT
  LOG_LEVEL

startup:
  read
  validate
  normalize
  expose typed config

建立 dev/test/prod 範例，但不把 real secret commit。

Debug evidence：Production 連到測試 API

1. Config 是 build-time 還是 runtime？
2. Actual deployed artifact 裡寫了什麼？
3. Process environment 是什麼？
4. Deployment workflow 注入了哪個 scope 的 value？