增加支付逻辑

docs/DEPLOYMENT.md

@@ -47,29 +47,35 @@ docker build -f backend/Dockerfile.alpine \
 生产固定使用 PostgreSQL。数据库连接只通过 Go Deployment 的 Secret 注入，不得进入
 Web 镜像或 ConfigMap。优先使用 RDS 内网地址，并仅对白名单中的 ACK 工作负载网段放行。
 
-`DATABASE_URL` 必须使用 `sslmode=disable`。Go 和手工迁移使用的 Node 客户端都会强制
+`DATABASE_URL` 和 `DATABASE_MIGRATION_URL` 必须使用 `sslmode=disable`。Go 和手工迁移使用的 Node 客户端都会强制
 归一化为该值；即使旧 Secret 仍包含 TLS 参数，客户端也不会读取 CA 或协商 TLS。
 这表示 ACK 到 RDS 的数据库流量不使用 TLS、链路内容为明文。只应使用 RDS 内网地址，
 并通过 VPC、安全组和白名单严格限制访问；若未来需要链路加密，必须同时修改客户端策略
 和 RDS 配置后再部署。
 
-首次发布前，部署负责人按顺序手工执行：
+ACK 模板设置 `DATABASE_AUTO_MIGRATE=true`。Go API 启动时先连接
+`DATABASE_MIGRATION_URL`（`zhinian-migration-db` Secret），按版本顺序执行镜像内已
+同步的 `database/migrations/*.sql`，并用 `DATABASE_APP_ROLE` 给应用账号授权；全部成功后
+才启动 HTTP 服务。该变量未提供时，启动器会回退使用 `DATABASE_URL`，但 ACK 明确使用
+独立迁移账号。`DATABASE_APP_ROLE` 必须填写为 `zhinian-go-db` 连接串中的 PostgreSQL
+用户名，且迁移账号须具备建表、修改表和授权权限。`DATABASE_MIGRATION_URL` 与
+`DATABASE_URL` 的主机、端口和数据库名必须相同，连接用户名可以不同；启动器会检查。
+默认启动迁移超时 180 秒；对应的 startupProbe 提供约 300 秒预算。每个迁移版本的 DDL
+与版本记录在同一事务中；失败的版本会回滚，之前已成功提交的版本保留。迁移失败时 Pod
+不监听端口，查看 Go Pod 日志并修复原因后再重启。回滚镜像不会逆向撤销数据库迁移。
+遇到历史重复数据，先人工审计，不能跳过或
+自动删除计费与用量记录。
 
-1. `database/migrations/0001_initial_schema.sql`
-2. `database/migrations/0002_generation_lifecycle_fencing.sql`
-3. `database/migrations/0003_platform_runtime_settings.sql`
-4. `database/migrations/0004_seedream_billing_provider.sql`
-5. `database/migrations/0005_seedream_layer_compositions.sql`
-6. `database/migrations/0006_minimax_h3_billing_provider.sql`
-7. 应用角色授权语句（参考 `scripts/migrate-postgres.mjs`）
+每次新增迁移，在仓库根目录运行 `npm run db:bundle`，把根目录 SQL 同步成提交到 Git 的
+Go 迁移包，然后构建 Go 镜像；不能修改已应用的历史 SQL。新镜像启动时会核对版本记录，
+只执行未应用的迁移，重启不会重复建表。手工处理仍可从仓库根目录执行
+`npm run db:migrate`；其连接账号也应具备上述权限。生产不部署迁移 Job 或 Node Worker，
+Go 镜像运行时不需要 Node/npm，也不用在 ACK「启动执行」中填写命令。
 
-升级已有生产库接入 MiniMax H3 时，只需在发布新 Go 镜像前执行尚未应用的 `0006`；
-新版本 `/api/ready` 会同时检查计费服务商约束中已包含 `seedream` 和 `minimax`，未迁移的
-Pod 不会进入 Ready，避免运行后才在报价阶段返回 500。
-
-生产不部署迁移 Job。遇到历史重复数据时迁移会失败，需先人工审计，不能跳过或自动删除
-计费与用量记录。仓库不再提供可误执行的 Node Migration Job 或 Node Worker 清单；后台
-任务由 Go API 内嵌 WorkerLoop 处理。
+虽然当前 `replicas: 1`，RollingUpdate 的 `maxSurge: 1` 可能短暂同时运行新旧两个 Go
+Pod。迁移器使用 PostgreSQL 锁串行化迁移，不能以单副本假定没有并发。旧版 Pod 可能在
+新版迁移期间继续接流量，因此新增 SQL 需兼容滚动期间的新旧程序。数据库迁移不能靠
+回滚镜像自动撤销。
 
 Go 首次启动会读取 `zhinian-go-bootstrap` Secret 中的
 `ZHINIAN_BOOTSTRAP_ADMIN_PHONE` 和 `ZHINIAN_BOOTSTRAP_ADMIN_PASSWORD`，仅在不存在
@@ -82,6 +88,11 @@ Go 首次启动会读取 `zhinian-go-bootstrap` Secret 中的
 Git 的 `deploy/ack/secrets.production.yaml`，替换所有占位值。Web 不需要任何运行时
 Secret；会话密钥只属于 Go。
 
+将 `configmap.yaml` 中 `DATABASE_APP_ROLE: REPLACE_WITH_APP_DB_ROLE` 替换为应用数据库
+用户（`zhinian-go-db` 的 `APP_USER`），并确认 `zhinian-migration-db` 的连接串指向同一
+数据库；两条连接串的主机、端口和数据库名须一致。先发布 Secret/ConfigMap 再更新 Go Deployment。ACK 控制台的「启动执行」命令
+与参数保持空白，镜像原本的 `zhinian-api` 启动入口会自行迁移。
+
 仓库内静态检查：
 
 ```bash
@@ -126,6 +137,7 @@ Pod 的 `emptyDir`，Pod 重建或滚动升级同样会永久丢失上传文件
 Kubernetes Secret：
 
 - `DATABASE_URL`
+- `DATABASE_MIGRATION_URL`（独立迁移账号，来自 `zhinian-migration-db`）
 - `ZHINIAN_AUTH_SESSION_SECRET`（Secret 名 `zhinian-go-auth`，仅注入 Go）
 - `ZHINIAN_BOOTSTRAP_ADMIN_PHONE`、`ZHINIAN_BOOTSTRAP_ADMIN_PASSWORD`
 - OSS 凭据；服务商凭据也可以先放 Secret 作为数据库尚未配置时的回退值
@@ -141,7 +153,7 @@ Secret/ConfigMap 为事实来源。设置页全部 27 项配置由超级管理
 ## 探针与验收
 
 - Web `/healthz`：Nginx 静态进程存活检查。
-- Go `/api/health`：Go 进程存活检查；以 250ms 上限刷新服务商状态，失败时使用进程内缓存并仍返回存活状态。
+- Go `/api/health`：迁移完成且服务开始监听后的进程存活检查；以 250ms 上限刷新服务商状态，失败时使用进程内缓存并仍返回存活状态。
 - Go `/api/ready`：检查 PostgreSQL schema、表权限和业务函数权限。
 
 发布后执行：
@@ -176,6 +188,10 @@ cp .env.example .env.local
 ./scripts/deploy.sh
 ```
 
+ACK 和 Compose 会向 Go 进程注入环境变量。若直接在本地执行 `go run` 或 Go 二进制，
+需显式导出 `DATABASE_AUTO_MIGRATE`、`DATABASE_MIGRATION_URL`、`DATABASE_URL` 等
+数据库启动参数；仅填写 `.env.local` 不等于已向 Go 进程注入这些变量。
+
 根目录 Compose 会启动 `zhinian-web` 与 `zhinian-go-api`，挂载
 `deploy/nginx-compose.conf` 将 `/api`、`/uploads`、`/generated-results` 转发给 Go；Go
 内嵌 WorkerLoop，不再启动独立 Node Worker。ACK 生产仍使用上面的两镜像 + Ingress 拓扑，