MVP 上线前的轻量级基础设施检查清单

很多 MVP 失败并不是因为技术太少，而是因为上线前的基础设施边界没有想清楚。

一个早期项目不需要复杂的微服务、昂贵的监控平台或完整的企业级流程。但它至少需要做到几件事：用户能打开、搜索引擎能收录、表单能提交、邮件能送达、错误能被发现，并且出问题时可以快速回退。

这份清单适合三类项目：

• 独立开发者的工具站
• 面向海外用户的小型 SaaS
• 全球卖家的验证、查询、落地页或自动化工具

目标不是把架构做大，而是让项目“够稳地开始”。

1. 先确定一个可长期迁移的入口

早期可以不买主域名，也可以先使用免费子域名。但入口地址最好满足三个条件：

• 容易读给别人听
• 不依赖某台临时机器
• 将来可以迁移到正式域名

如果只是验证想法，平台默认域名和免费子域名都可以用。关键是不要把所有宣传材料、邮件链接和用户收藏都绑死在一个随时会换的测试地址上。

GhostDNS 这类免费子域名工具适合这个阶段：它让你先有一个能被记住的入口，等项目跑通后再升级到正式域名。

2. DNS 记录要少，但要可解释

MVP 的 DNS 配置越少越好。常见组合通常只需要：

• 一个指向主站的 A 或 CNAME
• 一个 www 或工具子域名
• 邮件服务需要的验证记录
• 必要时再加 API 或后台入口

不要在早期堆太多临时记录。三个月后你大概率会忘记某条记录为什么存在。

上线前至少检查：

• 主域名和 www 是否都能访问
• 不需要公开的端口是否没有暴露
• DNS TTL 是否适合上线当天调整
• Cloudflare 或其它代理层是否没有缓存错误页面

DNS 是小项目最容易被低估的部分。它不复杂，但出错时会让你以为应用坏了。

3. HTTPS 和基础安全不要以后再补

HTTPS 不是“正式上线以后再做”的事。只要你让用户输入邮箱、地址、订单号或任何个人信息，就应该先启用 HTTPS。

最小安全基线包括：

• 全站 HTTPS
• HTTP 自动跳转到 HTTPS
• 管理入口不要暴露默认路径和弱密码
• 数据库、Redis、内部应用端口不要直接暴露公网
• 生产环境变量不要提交到 Git

这些事情做起来并不重，但一旦漏掉，后期补救会更痛。

4. 邮件链路要真实测试

很多项目上线时只测试了“接口返回成功”，却没有确认邮件真的到了用户邮箱。

如果你的产品有注册、登录、验证、重置密码、订单通知或人工审核流程，邮件就是核心链路。上线前至少发一封真实邮件，检查：

• 发件人名称是否可信
• 验证链接是否使用正式 HTTPS 域名
• 邮件是否进入垃圾箱
• 退订、回复或客服入口是否清楚
• 生产环境没有使用本地测试地址

对早期项目来说，使用 Resend、Postmark、Mailgun 这类 API 邮件服务，通常比自己在 VPS 上直发邮件更可靠。

5. 全球卖家要提前处理地址质量

如果你的 MVP 面向跨境交易、物流、仓储、表单收集或 B2B 线索，地址质量不是后端细节，而是转化问题。

一个错误地址可能带来：

• 支付前犹豫
• 物流费用估算错误
• 人工客服反复确认
• 包裹退回
• 用户认为网站“不专业”

上线前至少让地址表单做到：

• 国家、州/省、市字段逻辑清楚
• 邮编和地址格式有基础校验
• 错误提示可理解
• 用户可以修正，而不是被硬拦截

GhostAddress 这类工具适合在结账或提交前做轻量验证：不需要把流程做重，但要尽早发现明显错误。

6. 日志和健康检查要先有最小版本

MVP 不需要复杂观测平台，但至少要回答三个问题：

• 应用现在活着吗？
• 最近有没有持续报错？
• 出问题后能否定位到请求、时间和版本？

最小方案可以很简单：

• /api/health 健康接口
• 容器健康检查
• Nginx 访问日志和错误日志
• 应用错误日志
• 最近一次部署 commit 记录

不要等用户截图告诉你“打不开”才开始找日志。

7. 回滚路径要比新功能更早准备

早期项目最大的风险不是出错，而是出错后只能继续往前乱修。

上线前问自己：

• 上一个可用版本是什么？
• 如果新版本构建失败，会不会影响当前服务？
• 如果数据库迁移失败，是否有备份？
• 如果缓存返回旧页面，是否知道怎么清理？
• 如果域名或证书异常，是否能分层验证？

即使只是一个静态内容站，也应该知道如何回到上一版。

8. 最小上线清单

可以把这份清单压缩成上线前 10 分钟检查：

• 域名可访问
• HTTPS 正常
• DNS 记录清楚
• 邮件真实投递通过
• 关键表单可提交
• 地址或订单字段有基础校验
• 健康接口正常
• 日志可查看
• 缓存可清理
• 回滚路径明确

这不是企业级流程，而是避免低级事故的护栏。

结论

轻量级基础设施不是“少做事”，而是只做那些能降低上线风险的事。

MVP 的重点仍然是验证需求。但如果入口不稳定、邮件不到、地址错误、日志缺失，用户给你的反馈就会被基础设施噪声污染。

先把小工具做稳，再让产品自然长大。