📖 白話：問題是什麼

系統用一組「機器指紋」認出「這是哪一台機器」，用途有兩個：①解鎖憑證綁定（原廠簽的解鎖檔只對這台有效）②授權綁機（license 綁客戶那台機器）。

問題：這個指紋在容器裡每次重啟就變一個，等於同一台機器每次開機都換一張臉。後果：

• 原廠簽的解鎖憑證，客戶重啟一次就失效，永遠解不了鎖
• license 綁機也會漂——授權可能無故失效

🔬 根因（已在 188 實測確認，非推測）

common/license/machine_fingerprint.py 的指紋來源優先序：

1. /etc/machine-id（穩定，設計主判準）
2. /var/lib/dbus/machine-id（備援）
3. 都缺 → uuid.getnode()（MAC 位址，restart 會變，原碼註解只當「本地測試備援」）

實測（188 正式 guidant-api 容器）：

• 容器內 /etc/machine-id = 存在但 0 bytes 空檔（Debian/Ubuntu base image 標準行為：build 時留空佔位，預期 runtime 由 systemd 填，但容器不跑 systemd → 永遠空）
• /var/lib/dbus/machine-id = 不存在
• _read_machine_id() 對空檔回 None（if value: 空字串為 False）→ 退回第 3 級 MAC
• 容器 MAC = Docker 隨機生成（32:6e:d4:45:04:e6），docker restart 就換一個
• 宿主機 /etc/machine-id = d478e208...（穩定存在） ← 修法的錨點

原碼 docstring 自己寫「正式部署預期跑在有 /etc/machine-id 的容器宿主上」——設計意圖對，但沒把宿主的 machine-id 帶進容器，實際落在第 3 級。

🛠 修法選項（待決策者拍板）

• 選項 A（推薦，一行）：docker-compose 加掛載 - /etc/machine-id:/etc/machine-id:ro，容器指紋跟宿主機穩定綁定。最貼近「綁這台實體機」原意，改動最小。風險：宿主若無 machine-id（極少數精簡系統）要 fallback。
• 選項 B：entrypoint 首次啟動時把指紋種子寫進持久 volume（如 /opt/guidant/pki/.machine-seed），之後讀它。不依賴宿主 machine-id，但多一層邏輯、且「換宿主機但同 volume」會被誤判同機。