Deno 的部署和运维有哪些最佳实践？

核心实践概览

Deno 生产部署的关键在于：容器化打包、权限最小化、健康检查三板斧，以及选择合适的部署平台。面试中考察的重点不是你会写多少 Dockerfile，而是你能否说清每个配置背后的取舍。

容器化部署怎么选？

Deno 官方提供 denoland/deno 镜像，生产环境推荐多阶段构建：先用 deno compile 将 TypeScript 编译为单文件二进制，再用精简基础镜像（如 debian:slim）运行。这样做的好处是最终镜像小、启动快、不暴露源码。

注意：Deno 2.x 已发布，不要再写 denoland/deno:1.38.0 这种过时版本。编译命令也有所变化，建议查阅最新文档。

容器内务必以非 root 用户运行，Dockerfile 末尾加 USER deno 是基本操作。

权限控制为什么重要？

Deno 和 Node.js 最大的架构差异就是默认安全。生产环境中坚决不用 -A（全量授权），而是按需授予：

• 网络访问用 --allow-net=api.example.com 限定域名
• 文件读取用 --allow-read=/app/data 限定路径
• 环境变量用 --allow-env=PORT,DB_URL 限定变量名

面试中如果只答出 --allow-net 这种粗粒度权限，说明你没在生产环境用过 Deno。

部署平台如何选择？

三种主流方案：

• Deno Deploy：官方边缘计算平台，零配置部署，适合轻量 API 和 SSR 应用。2026 年 2 月已 GA，Classic 版将在 7 月下线，需要迁移到新平台。
• 容器化自建：Docker + K8s，适合需要精细控制或有复杂依赖的场景。配置资源限制（requests/limits）、存活探针和就绪探针是基本要求。
• PaaS 托管：Railway、Vercel 等平台，适合快速上线，但定制空间有限。

选型依据：流量规模、延迟要求、团队运维能力。不要为了用 Deno Deploy 而用，数据库连接密集型场景自建集群更稳。

健康检查和监控怎么做？

健康检查端点是生产标配：

• /health 返回进程存活状态，用于 K8s livenessProbe
• /ready 返回服务就绪状态（依赖是否连上），用于 readinessProbe

监控方面，结构化日志（JSON 格式）比 console.log 更有利于日志平台解析。Deno 2.x 支持 Deno.memoryUsage() 获取内存指标，配合定时上报可以排查内存泄漏。

CI/CD 有什么坑？

Deno 项目的 CI 流程比 Node.js 简单——不需要 npm install，deno cache 一步搞定依赖。但要注意：

• deno lint 和 deno fmt --check 必须加，Deno 内置了这些工具没有理由不用
• Docker 构建时先 COPY deno.json 再 deno cache，利用层缓存加速构建
• 镜像 tag 用 git SHA 而不是 latest，否则回滚时找不到版本

追问方向

• Deno Deploy 和 Cloudflare Workers 在架构上有什么区别？（冷启动、运行时限制、KV 存储）
• deno compile 编译出的二进制在 Alpine 镜像里能直接跑吗？（不能，Alpine 用 musl，需要静态编译或用 glibc 镜像）
• Deno 的权限系统在容器内被绕过怎么办？（容器本身是安全边界，Deno 权限是应用层防护，两者互补）