DigitalOcean App Platform 组件化部署实战指南

1. 这不是“又一个PaaS”而是把应用拆成乐高积木来搭DigitalOcean App Platform 这个名字听起来平平无奇但如果你真把它当成另一个 Heroku 或者 Vercel 的简化版那第一关就踩了坑。我带团队用它上线过7个生产级SaaS微服务模块从最简单的静态博客到需要实时WebSocket连接的协作白板核心体会只有一句App Platform 的本质不是帮你“部署应用”而是帮你“定义组件契约”。关键词里那个“component-based apps”绝不是营销话术——它强制你用一种近乎“反直觉”的方式思考架构不问“我的后端跑在哪”而问“这个组件要暴露什么端口、接收什么环境变量、依赖哪个数据库实例、失败时怎么降级”。这背后是 DigitalOcean 对现代云原生开发最务实的妥协不强推 Kubernetes 的复杂性也不纵容“本地能跑就行”的混沌部署而是用极简的 YAML 配置在 Git 提交那一刻就固化组件边界。它解决的痛点非常具体前端工程师改完 React 组件想立刻看效果不用再求运维开个测试环境后端新人提交一个 Python API三分钟内就能拿到可访问的 HTTPS 地址供 QA 测试数据团队临时起意要做个 Grafana 看板不用申请服务器权限直接拉取已有 PostgreSQL 实例的只读连接串就能上线。适合谁不是 Kubernetes 工程师而是那些被 CI/CD 流水线卡在“最后一百米”的中小团队——你们有 Docker 基础但没专职 SRE你们用 GitHub但不想为每个服务单独配 Nginx 反向代理你们需要快速验证 MVP但又不能接受 Vercel 那种“所有东西都得塞进前端框架”的绑架式架构。我见过太多团队在“自建 K8s 集群”和“全栈托管平台”之间反复横跳最后发现 App Platform 就是那个被忽略的黄金分割点它不给你无限自由但把 90% 的重复劳动证书续期、负载均衡配置、健康检查探针打包成默认行为只留给你最关键的三个决策权组件类型、环境变量、依赖关系。这种克制恰恰是它能在 2024 年依然保持 35% 月活增长的核心原因。2. 内容整体设计与思路拆解为什么放弃“单体部署”选择“组件编排”2.1 核心设计哲学从“部署单元”到“能力单元”的范式转移传统 PaaS比如早期的 Heroku把整个代码仓库当做一个部署单元你 push 一次它 build 一次启动一个进程。App Platform 彻底打破了这个逻辑。它的最小可部署单位是component——一个具备明确输入输出契约的独立能力模块。这个设计不是为了炫技而是直击现代应用开发的三个现实约束异构技术栈共存一个典型 SaaS 应用里用户认证用 Go 写的 JWT 服务报表生成用 Python Pandas前端是 Next.js管理后台是 Vue。传统单体部署要求所有代码必须用同一套构建脚本而 App Platform 允许你为每个组件单独指定Dockerfile路径、build_command和run_command。我实测过在一个仓库里同时部署 Rust 编译的 WASM 后端和 PHP 的遗留管理接口它们共享同一个域名通过路径路由/api/*和/admin/*但构建环境完全隔离——Go 组件用golang:1.21-alpine基础镜像PHP 组件用php:8.2-apache互不干扰。资源粒度精准控制单体部署意味着所有功能共享 CPU/内存配额。而 App Platform 允许你为每个组件单独设置tier基础版/专业版/企业版。比如我们的 WebSocket 协作服务需要高并发连接就选professional2GB RAM 2 vCPU而静态资源 CDN 组件只需basic512MB RAM。更关键的是组件间网络调用默认走内网——你的 Go 服务调用 PostgreSQL 组件流量不经过公网延迟稳定在 0.8ms 以内我们用ping和curl -w curl-format.txt实测过这比任何 DNS 解析优化都实在。故障域天然隔离当某个组件崩溃时App Platform 的自动恢复机制只重启该组件不影响其他组件。我们曾故意在 Python 报表服务里写死time.sleep(300)模拟长任务阻塞结果只有/report接口返回 503而/auth/login和前端页面完全不受影响。这种隔离不是靠 Kubernetes 的 Pod 机制而是靠 App Platform 在底层为每个组件分配独立的容器运行时沙箱并强制使用health_check_path做存活探测——你必须显式声明/health接口否则它连启动都不会允许。提示App Platform 的组件不是“微服务”的同义词。微服务强调业务边界而组件强调部署契约。一个微服务可以拆成多个组件如 API 网关 认证中间件 业务逻辑也可以由多个组件组合而成如前端静态文件 SSR 渲染服务 图片处理 Worker。关键在于组件是部署时的概念不是设计时的概念。2.2 方案选型背后的硬核考量为什么不是 Vercel/Netlify很多人第一反应是“Vercel 不也能部署多组件” 但实际落地时会撞上三堵墙后端能力阉割Vercel 的 Serverless Functions 有 10 秒执行时限且无法维持长连接。而我们的实时协作白板需要 WebSocket 持久连接App Platform 的service类型组件支持无限时长运行底层用的是 Docker 容器而非 Lambda这是架构级差异。环境变量管理混乱Vercel 要求所有环境变量在项目级统一配置而 App Platform 允许你为每个组件单独设置environment字段。这意味着你可以让前端组件只看到API_BASE_URL后端组件看到DATABASE_URL和REDIS_URL数据库组件看到POSTGRES_PASSWORD——敏感信息按需分发而不是全量暴露。我们审计过这种细粒度控制让环境变量泄露风险下降了 76%基于内部渗透测试报告。基础设施耦合度Vercel 强制你用它的 Edge Network而 App Platform 允许你选择区域纽约/阿姆斯特丹/新加坡更重要的是它原生集成 DigitalOcean 的 Managed Databases、Spaces对象存储、Load Balancers。当我们需要把用户上传的图片存到 Spaces再用一个独立的 Python Worker 组件处理缩略图整个流程只需在 YAML 里写services: [web, worker]和databases: [postgres]App Platform 自动注入SPACES_ENDPOINT和SPACES_KEY环境变量——不需要一行代码去读取 secrets manager。注意App Platform 不是万能的。它不支持 StatefulSet有状态应用所以不要试图部署 Elasticsearch 或 Kafka。它的定位很清晰托管无状态、可水平扩展的 Web 应用组件。如果你的应用需要本地磁盘持久化或跨节点共享内存老老实实用 Droplet。2.3 架构图景一个真实 SaaS 的组件拓扑如何长这样我们为某客户搭建的 CRM 系统最终在 App Platform 上形成了这样的组件拓扑已脱敏┌─────────────────┐ ┌──────────────────┐ ┌─────────────────────┐ │ Frontend │ │ API Gateway │ │ Auth Service │ │ (Next.js) │ │ (Go, Envoy) │ │ (Go, JWT) │ │ tier: basic │ │ tier: professional │ │ tier: basic │ └────────┬────────┘ └────────┬─────────┘ └────────┬────────────┘ │ │ │ └────────────────────────┼───────────────────────┘ │ ┌───────▼────────┐ │ PostgreSQL │ │ (Managed DB) │ │ tier: standard │ └────────────────┘关键细节Frontend 组件构建命令是npm run build输出目录out/自动启用 CDN 缓存。API Gateway 组件用 Go 写的轻量级网关负责路由/api/v1/*到 Auth Service 和业务后端后者我们用 Droplet 托管因为需要 GPU 加速。Auth Service 组件独立部署只暴露/login和/refresh接口所有数据库操作通过DATABASE_URL环境变量连接 PostgreSQL。PostgreSQL不是组件而是 App Platform 的“附加资源”Add-on它不参与构建部署但会被自动注入到所有声明依赖它的组件中。这种拓扑的优势在于当客户要求增加短信验证码功能时我们只需新增一个sms-service组件配置它依赖POSTGRES_URL然后在 API Gateway 里加一条路由规则——完全不改动现有组件的代码和配置。这就是“组件化”带来的真正敏捷性。3. 核心细节解析与实操要点YAML 配置里的魔鬼细节3.1app.yaml的每一行都在回答一个架构问题App Platform 的灵魂是app.yaml文件。它看起来简单但每行配置都在强制你回答一个关键架构问题。以下是我们生产环境app.yaml的逐行解析已简化name: crm-prod region: nyc # region 必须是 DigitalOcean 支持的区域nyc 是纽约sfo 是旧金山ams 是阿姆斯特丹 # 选错区域会导致组件间延迟飙升——我们实测过 nyc 区域的组件调用 ams 数据库P95 延迟从 12ms 涨到 210ms services: - name: frontend github: repo: acme/crm-frontend branch: main deploy_on_push: true # deploy_on_push: true 表示每次 push 到 main 分支就自动部署 # 如果设为 false就得手动在控制台点击 Deploy适合灰度发布场景 routes: - path: / # 这里定义了根路径路由App Platform 会自动为 frontend 组件分配一个子域名 # 如 https://frontend-crm-prod.ondigitalocean.app http_port: 3000 # 必须指定应用监听的端口App Platform 不会自动探测 # 如果你的 Next.js 应用监听 3001这里写错就会导致 502 Bad Gateway environment: - key: API_BASE_URL value: https://api.crm-prod.ondigitalocean.app # 环境变量值可以是字符串也可以是引用其他组件的 URL # 但注意这里不能写 ${API_SERVICE_URL} 这种模板语法App Platform 不支持变量插值 health_check_path: /health # 必须提供健康检查路径App Platform 每 10 秒 GET 一次 # 如果返回非 2xx 状态码它会重启容器。我们曾经因为忘记在 Next.js 里加 /health 路由导致组件反复重启 - name: api-gateway github: repo: acme/crm-gateway branch: main routes: - path: /api - path: /auth http_port: 8080 environment: - key: AUTH_SERVICE_URL value: http://auth.crm-prod.ondigitalocean.app # 注意这里用的是 http://不是 https:// # 因为组件间调用走内网强制用 HTTP 更高效App Platform 会自动处理 TLS 终止 databases: - name: postgresql engine: pg version: 15 size: db-s-2vcpu-4gb # size 必须是 DigitalOcean Managed Databases 的规格名 # db-s-2vcpu-4gb 表示 2 核 CPU 4GB 内存价格 $40/月 # 错误示例size: 4gb 会报错必须用完整规格名 static_sites: - name: docs github: repo: acme/crm-docs branch: gh-pages build_command: jekyll build output_dir: _site # static_sites 类型组件专为静态文件优化自动启用 Brotli 压缩和边缘缓存实操心得app.yaml的缩进是 YAML 语法的关键。我们团队曾因environment:下面的- key:多了一个空格导致整个部署失败错误日志只显示 “invalid yaml format”排查了 47 分钟才定位到空格问题。建议用 VS Code 的 YAML 插件开启 “editor.detectIndentation”: false手动设为 2 空格缩进。3.2 环境变量的三种注入方式安全与便利的平衡术App Platform 提供三种环境变量注入方式适用场景截然不同注入方式配置位置适用场景安全性示例明文写入app.yamlenvironment字段下非敏感配置如NODE_ENVproduction、API_BASE_URL⚠️ 低value: https://api.example.com引用 DigitalOcean Secretssecrets字段密码、API Keys 等敏感信息✅ 高value: ${DB_PASSWORD}需先在 DO 控制台创建 secret自动注入附加资源无需配置数据库连接串、对象存储凭证✅ 高POSTGRES_URL、SPACES_KEY会自动注入到所有依赖该资源的组件关键细节Secrets 必须在 DigitalOcean 控制台预先创建命名规则是secret_name然后在app.yaml中用${secret_name}引用。自动注入的变量名是固定的PostgreSQL 一定是DATABASE_URLMySQL 是MYSQL_URLSpaces 是SPACES_KEY和SPACES_SECRET。你不能自定义这些名字这是 App Platform 的契约。我们曾踩坑在app.yaml里写了value: ${POSTGRES_URL}但实际应该用DATABASE_URL。结果应用启动时报错database url not found因为 App Platform 根本没注入这个变量。提示对于需要加密的敏感信息如 JWT 秘钥我们采用“双层加密”策略第一层用 DigitalOcean Secrets 存储加密后的密钥第二层在应用启动时用环境变量ENCRYPTION_KEY也存于 Secrets解密。这样即使 Secrets 被意外泄露攻击者仍需破解 AES-256。3.3 构建过程的隐性成本Dockerfile 与 Buildpacks 的抉择App Platform 支持两种构建方式Dockerfile 构建和Buildpacks 构建。这不是一个“选哪个更好”的问题而是“选错就无法上线”的生死线。Dockerfile 构建你需要在代码仓库根目录放一个DockerfileApp Platform 会执行docker build -t app .。优势是完全可控劣势是构建时间长平均 4 分钟、镜像体积大我们的 Next.js 镜像达 1.2GB。Buildpacks 构建App Platform 自动识别语言Node.js/Python/Go 等用 Cloud Native Buildpacks 构建。优势是快平均 90 秒、镜像小Next.js 仅 280MB劣势是定制性差。我们的实操结论前端组件Next.js/Vue一律用 Buildpacks因为next build产物是纯静态文件Buildpacks 的nginx运行时足够。后端组件Go/Python一律用 Dockerfile因为需要精确控制基础镜像如golang:1.21-alpine、安装系统依赖如libpq-dev、设置非标准工作目录。Dockerfile 黄金法则# 第一阶段构建 FROM golang:1.21-alpine AS builder WORKDIR /app COPY go.mod go.sum ./ RUN go mod download COPY . . RUN CGO_ENABLED0 GOOSlinux go build -a -installsuffix cgo -o main . # 第二阶段运行极简镜像 FROM alpine:latest RUN apk --no-cache add ca-certificates WORKDIR /root/ COPY --frombuilder /app/main . CMD [./main]必须用多阶段构建否则镜像会包含 Go 编译器体积暴增。CGO_ENABLED0确保生成纯静态二进制避免 Alpine 镜像缺少 glibc 的兼容性问题。alpine:latest是最小化运行时比debian:slim小 60%。注意App Platform 的构建环境是 Linux AMD64不支持 ARM 架构。如果你在 M1 Mac 上本地测试 Dockerfile务必加上--platform linux/amd64参数否则本地能跑线上构建失败。4. 实操过程与核心环节实现从零到生产环境的七步法4.1 第一步初始化项目与区域选择决定 80% 的后续体验这不是一个“点几下鼠标”的步骤而是需要查证的决策登录 DigitalOcean 控制台进入 App Platform 页面点击 “Create App”。选择源代码仓库支持 GitHub、GitLab、Bitbucket。我们只用 GitHub因为它的 OAuth 权限粒度最细可以只授权特定仓库而非全部。最关键的一步选择 Region。打开 DigitalOcean 官方区域延迟测试页 用你目标用户的地理位置做测试。例如你的客户 70% 在东南亚那就选sgp新加坡如果主要在欧洲选ams阿姆斯特丹。不要选离你最近的区域而要选离你的用户最近的区域。我们曾因选错区域导致新加坡用户访问美国区域部署的组件首屏加载时间从 1.2s 涨到 4.7s。命名规范App 名称会成为子域名的一部分如my-app.ondigitalocean.app所以必须全局唯一、小写字母数字短横线。我们团队约定[产品名]-[环境]-[团队缩写]如crm-prod-acme。实操记录第一次创建时我们选了nyc区域后来发现 60% 的客户在德国。迁移方案不是“换区域”而是新建一个crm-prod-acme-amsApp用 Cloudflare 的 Load Balancing 把*.acme.com的流量按地理位置路由到两个 App。App Platform 本身不支持跨区域迁移这是它的设计限制也是你必须接受的现实。4.2 第二步编写app.yaml并配置第一个组件前端以 Next.js 前端为例这是我们的最小可行app.yamlname: crm-prod-acme region: sgp services: - name: frontend github: repo: acme/crm-frontend branch: main deploy_on_push: true routes: - path: / http_port: 3000 build_command: npm run build output_dir: out environment: - key: NODE_ENV value: production health_check_path: /health关键操作细节output_dir: outNext.js 默认构建输出到out/目录App Platform 会把这个目录作为静态文件根目录。health_check_path: /health必须在pages/health.tsx里创建一个简单页面返回200 OK。内容可以是divOK/div但路径必须存在。不要在next.config.js里配置assetPrefixApp Platform 会自动处理静态资源路径。部署后你会得到一个类似https://frontend-crm-prod-acme.ondigitalocean.app的 URL。首次部署耗时约 3-5 分钟构建 部署后续更新通常在 90 秒内完成。实测对比我们用同样的 Next.js 代码在 Vercel 部署耗时 72 秒在 App Platform 耗时 89 秒差距不大。但 App Platform 的构建日志更透明——它会完整显示npm install、npm run build的每一行输出而 Vercel 日志是折叠的出错时排查效率低 40%。4.3 第三步添加后端组件并建立组件间通信真正的组件化起点现在添加一个 Go 编写的 API 组件# 在 services 数组里追加 - name: api github: repo: acme/crm-api branch: main routes: - path: /api http_port: 8080 environment: - key: DATABASE_URL value: ${DB_URL} health_check_path: /health组件间通信的实操要点域名规则每个组件的内部域名是[component-name]-[app-name].ondigitalocean.app。所以frontend组件访问api组件URL 是http://api-crm-prod-acme.ondigitalocean.app/api/users。协议选择必须用http://不是https://。App Platform 的内部网络不走 TLS用 HTTPS 会连接超时。环境变量注入DATABASE_URL的值来自下一步添加的 PostgreSQL 数据库App Platform 会自动注入。Go 代码中的调用示例// 在 api 组件的 main.go 里 func getUsers(w http.ResponseWriter, r *http.Request) { // 直接使用环境变量无需额外配置 dbURL : os.Getenv(DATABASE_URL) if dbURL { http.Error(w, DATABASE_URL not set, http.StatusInternalServerError) return } // ... 连接数据库逻辑 }注意App Platform 会为每个组件分配独立的 DNS 解析所以http.Get(http://api-crm-prod-acme.ondigitalocean.app)是有效的。但不要用localhost或127.0.0.1因为组件运行在不同容器里。4.4 第四步集成 Managed Database告别自己维护 PostgreSQL点击 App Platform 控制台的 “Add Component” → “Database”选择Engine: PostgreSQLVersion: 15Size:db-s-2vcpu-4gb起步配置按需升级Name:postgresql这个名字会成为环境变量前缀关键配置项Private Network Only: 必须勾选这确保数据库只接受来自同区域 App Platform 组件的连接公网完全不可见。Allow connections from: 选择你的 App 名称如crm-prod-acmeApp Platform 会自动配置防火墙规则。数据库连接串格式 App Platform 注入的DATABASE_URL长这样postgres://doadmin:xxxxxxxxxxxxxxxxpostgresql-crm-prod-acme-do-user-1234567-0.a.db.ondigitalocean.com:25060/defaultdb?sslmoderequire用户名doadmin是固定的。密码是随机生成的 32 位字符串。主机名包含区域标识a.db.ondigitalocean.com中的a表示sgp区域。连接验证 在api组件的/health接口里加入数据库连通性检查func healthCheck(w http.ResponseWriter, r *http.Request) { db, err : sql.Open(postgres, os.Getenv(DATABASE_URL)) if err ! nil { http.Error(w, DB connection failed, http.StatusInternalServerError) return } err db.Ping() if err ! nil { http.Error(w, DB ping failed, http.StatusInternalServerError) return } w.WriteHeader(http.StatusOK) w.Write([]byte(OK)) }实操心得Managed Database 的首次初始化需要 3-5 分钟。在这期间api组件会因健康检查失败而反复重启。这是正常现象等待数据库 Ready 后组件会自动恢复。不要手动重启组件否则会延长等待时间。4.5 第五步配置自定义域名与 HTTPS让客户信任你App Platform 默认域名*.ondigitalocean.app是开发用的生产必须绑定自有域名。步骤如下在你的 DNS 提供商如 Cloudflare、Namecheap添加 CNAME 记录Name:app如果你想用app.acme.comValue:frontend-crm-prod-acme.ondigitalocean.appTTL: Auto在 App Platform 控制台进入 App 设置 → Domains → Add Domain输入app.acme.com。App Platform 会自动生成 Lets Encrypt 证书通常 2-5 分钟完成。关键注意事项CNAME 是必须的A 记录不支持因为 App Platform 的 IP 地址是动态的。根域名限制不能直接绑定acme.com裸域名必须用子域名如app.acme.com或www.acme.com。这是 Lets Encrypt 的限制不是 App Platform 的缺陷。HTTPS 强制重定向App Platform 默认启用所有 HTTP 请求自动 301 重定向到 HTTPS无需额外配置。提示如果你用 Cloudflare可以把 DNS 代理橙色云朵打开利用 Cloudflare 的 WAF 和 DDoS 防护。但要注意Cloudflare 的代理模式会让X-Forwarded-For头变成 Cloudflare 的 IP你需要在应用里解析这个头来获取真实用户 IP。App Platform 的文档里有详细说明。4.6 第六步设置环境变量与 Secrets安全防线的最后一步现在为api组件添加 JWT 秘钥在 DigitalOcean 控制台进入 “Account” → “API Tokens Keys” → “Secrets”点击 “Create Secret”。Name:JWT_SECRETValue: 生成一个 64 字符的随机字符串用openssl rand -hex 32。点击 “Create”。然后修改app.yaml- name: api # ... 其他配置 environment: - key: DATABASE_URL value: ${DB_URL} - key: JWT_SECRET value: ${JWT_SECRET}Secrets 的安全实践轮换策略我们每 90 天轮换一次JWT_SECRET流程是1) 新建JWT_SECRET_V22) 更新app.yaml引用新 secret3) 部署4) 确认无误后删除旧 secret。权限最小化JWT_SECRET只注入给api组件frontend组件完全看不到它。审计日志DigitalOcean 会记录每次 secret 的创建、读取、删除操作可在 “Audit Logs” 里查看。注意Secrets 的值在 App Platform 的构建日志里是隐藏的显示为***但如果你在应用代码里fmt.Println(os.Getenv(JWT_SECRET))它会明文打印出来。所以永远不要在日志里打印敏感环境变量。4.7 第七步监控与日志看得见才能管得住App Platform 提供基础监控但需要主动配置Metrics在组件详情页可以看到 CPU、Memory、Network In/Out 的实时图表。阈值告警需要升级到 Professional 计划$20/月。Logs点击 “Logs” 标签页可实时查看 stdout/stderr。支持按组件、时间范围过滤。Log Drain可配置将日志发送到 Datadog、Papertrail 或自建 ELK。我们用 Papertrail配置只需在app.yaml加log_drains: - name: papertrail endpoint: syslogtls://logs.papertrailapp.com:12345 token: your-papertrail-token日志最佳实践结构化日志Go 应用用zerologNode.js 用pino输出 JSON 格式日志便于 Papertrail 解析字段。错误分级error级别日志必须包含error_code和user_id如果已知方便追踪。采样率对高频日志如/health检查设置采样避免日志爆炸。实操记录我们曾因未配置日志采样/health接口每秒产生 200 条日志一个月日志费用超 $300。后来在应用层加了if rand.Intn(100) 1 { return }日志量下降 99%成本回到 $5/月。5. 常见问题与排查技巧实录那些文档里不会写的坑5.1 502 Bad Gateway最常见原因最多现象访问组件 URL 返回 502但组件状态显示 “Running”。排查路径检查http_port登录组件日志搜索listening on port。如果日志显示server listening on :8080但app.yaml里写的是http_port: 3000立刻修正。检查健康检查日志里是否有GET /health的请求如果没有说明 App Platform 根本没发起健康检查可能是因为health_check_path路径不存在或返回非 2xx。检查端口绑定Go 应用必须绑定0.0.0.0:8080不是127.0.0.1:8080。后者只监听本地回环App Platform 的健康检查无法访问。检查防火墙如果应用用了自定义防火墙如ufw确保开放了http_port。App Platform 的容器环境默认没有防火墙但如果你的 Dockerfile 里装了ufw就会出问题。独家技巧在Dockerfile的最后加一行RUN echo PORT CHECK: $(netstat -tuln)构建日志里就能看到应用到底监听了哪个端口。5.2 构建失败npm install卡住或超时现象构建日志停在npm install10 分钟后超时失败。根本原因App Platform 的构建环境网络出口是 DigitalOcean 的共享 IP某些 npm registry如私有 Nexus会限流。解决方案换 registry在package.json同级加.npmrcregistryhttps://registry.npmjs.org/ timeout60000用 yarnyarn 的缓存机制更鲁棒在app.yaml里加build_command: yarn install yarn build预构建把node_modules打包进 Docker 镜像但会增大镜像体积不推荐。实测数据我们切换到 yarn 后构建失败率从 12% 降到 0.3%。yarn 的--frozen-lockfile参数能确保依赖版本严格一致避免npm install的不确定性。5.3 环境变量不生效process.env.XXX是 undefined现象代码里console.log(process.env.DB_URL)输出undefined。排查清单✅app.yaml里environment的缩进是否正确必须是 2 空格且- key:和- value:对齐。✅ 环境变量名是否拼写错误DB_URL和DATABASE_URL是不同的变量。✅ 是否在正确的组件里配置DB_URL只注入给声明了它的组件frontend组件看不到。✅ 是否用了 Secrets 但没在控制台创建${DB_PASSWORD}引用的 secret 必须存在否则变量值为空字符串。独家技巧在应用启动时加一段调试代码console.log(ALL ENV KEYS:, Object.keys(process.env));部署后看日志立刻知道哪些变量被注入了。5.4 数据库连接拒绝connection refused现象api组件日志显示dial tcp: lookup postgresql-crm-prod-acme-do-user-1234567-0.a.db.ondigitalocean.com: no such host。原因与解法DNS 解析失败App Platform 的组件和数据库必须在同一区域。检查app.yaml的region和数据库创建时的区域是否一致。数据库未就绪Managed Database 初始化需要 3-5 分钟期间 DNS 解析会失败