周三下午三點零七分，你又打開終端，敲下ssh db-host-prod-3，然后瞇起眼睛在一長串翻屏輸出里找到pg_hba.conf的位置，復核這個新來的開發人員應該分配到哪個庫、該給多大的連接數限制。接著是CREATE USER xiaoming_qa CONNECTION LIMIT 15 PASSWORD '一串臨時密碼'，你順手把密碼扔到企業內部IM的私聊窗口里，心里嘀咕“又忘了記到哪里”。半小時后，同一個用戶還等著你在UAT和預發布環境重復一模一樣的操作。整個過程像在一條沒有路燈的小巷里搬箱子——每個動作都不難，但連在一起就讓人疲憊，而且事后完全找不到腳印。

好在這種日子不是非得這么過。一個名叫pg-user-api的輕量級Flask REST API把PostgreSQL的用戶開通工作包裝成干凈的HTTP端點，你只需要提前在SQLite里登記好數據庫實例，之后任何工具——CI流水線里的shell腳本、內部開發者門戶、Ansible playbook，甚至是隨手敲出的curl命令——都能跨環境創建和管理用戶，而不用再親手觸碰psql。對運維和開發團隊來說，這相當于把反復執行的命令式操作轉換成可復現、可審計的聲明式API調用。

這個項目的思路很簡單：在多環境團隊中，不同角色的數據庫用戶總會遵循幾種固定模式。比如，有些是跟著虛擬機或容器走的服務賬號，命名習慣是“主機名_端口號”的組合，像web01_8080；有些是跑在Kubernetes上的工作負載賬號，名字里帶著環境前綴和集群標識，像dv_gearservice；還有給開發、測試工程師的個人賬號，連接數限制低，而且只開放非生產環境的訪問權限；甚至有面向分析師的只讀賬號，僅限生產庫，禁止執行DDL；以及極少被創建，但一旦需要就必須拿到CREATEDB、CREATEROLE權限的DBA角色。每一種模式背后都有各不相同的連接數上限、權限粒度和命名規則，把這些模式編碼進API，人肉操作里的隨意性就被規整成一致、可重復、可追溯的調用。

整個項目的工程結構刻意保持極簡，五個Python文件加上一個requirements列表就構成了全部骨架。flask應用的主邏輯放在app.py里，所有端點都在這里注冊；auth.py負責HTTP基本認證，用了常量時間比較來防時序攻擊；database.py封裝了SQLite注冊表和審計日志的交互；notifications.py留出了通知存根，目前能對接Webex、Slack和郵件，有需要時可以直接擴展；seed_db.py是一次性的初始化腳本，跑完后SQLite里就有了數據庫注冊表和示例記錄。兩套憑證被清清楚楚地拆開：PG_API_USER/PG_API_PASS用來驗證誰有權調用API，一般是團隊內部的自動化工具或者運維腳本；而PG_ADMIN_USER/PG_ADMIN_PASS是真正在PostgreSQL里執行DDL的DBA角色憑據。調用方全程只需要知道API憑據再加上環境和數據庫名，DBA級別的用戶名密碼永遠不會出現在URL或者返回體里。

數據庫注冊用的是SQLite，因為SQLite不需要額外配置守護進程，一個文件就能同時充當清單和審計日志的載體。所有PostgreSQL實例的信息都預先登記在db_registry表里，hostname、端口、默認庫名、環境標簽等字段各安其位，端點接到請求后動態從注冊表里查出連接信息，應用代碼里沒有任何硬編碼的連接字符串。這樣一來，新加入一個數據庫環境只需要在注冊表里插入一條記錄，全部端點立刻就都能識別到它。

所有端點都設計成GET請求并配合查詢參數傳遞信息，這種設計是有意為之——curl調用最直觀，從自動化腳本里拼裝URL也毫無心智負擔。健康檢查端點無需認證，返回服務狀態；/api/v1/registry列出所有已注冊的數據庫；/api/v1/users/all拉取指定庫上全部PostgreSQL角色的清單。/api/v1/users/app用來創建虛擬機或容器場景下的服務賬號，/api/v1/users/app-k8s則對應Kubernetes工作負載賬號，/api/v1/users/devqa負責開發/測試人員的個人用戶，/api/v1/users/devlead處理開發組長級別的用戶，/api/v1/users/readonly為分析師或報表工具派發只讀訪問權限，而/user端點可以按特定的用戶名查詢或執行操作。每個端點背后實際執行的SQL都內聚在各自的路由處理函數中，并精準匹配之前梳理出的那些用戶模式，避免出現“一把梭”授權。

這套工具真正讓人興奮的地方，不在于它用了什么新奇技術，而在于它把一個被習慣性忽略的手工鏈路，用最小的抽象成本變成了可組合的基礎設施能力。當你把創建數據庫用戶從一段段不知飄散到哪里的命令歷史里拽出來，變成一條條帶認證、可追溯、可復現的HTTP請求時，跨環境的一致性、訪問控制的合規性還有那始終缺位的審計蹤跡，也就自然被修補完整了。對于正在搭建內部平臺或者想要把日常運維動作收口到統一接口的團隊來說，這個項目提供了一個可以直接落地的起點，而且因為代碼足夠短，每一位使用它的工程師都看得懂里面到底在發生什么，也隨時能順著現有的端點模式擴展出符合自己團隊實際需求的變體。