凌晨两点，GitHub推送触发自动构建，Vercel面板飘红——这是开发者最熟悉的血压时刻。本文记录一次真实的前后端分离部署全过程，没有最佳实践，只有踩坑实录。

为什么选择拆两家

打开网易新闻 查看精彩图片

作者没有走传统单体部署路线，而是把前端丢给Vercel，后端丢给Render。这种"离婚式架构"正在成为小团队标配：Vercel专攻静态托管和边缘分发，Render承接动态服务，各自把长板拉到最长。

具体操作比想象中轻量。前端侧，GitHub仓库授权后，build设置和环境变量两步搞定；后端侧，Render上新建Web服务，Node.js/Express跑起来，同样塞进去环境变量。

但轻量不等于无痛。

三个凌晨的调试笔记

第一坑：构建失败。作者没透露具体报错，但"step by step debug"暗示了依赖版本或脚本配置的拉锯战。

第二坑：API连不上。前后端分属两个域名，CORS（跨域资源共享）配置成了暗礁——浏览器安全策略拦住了请求，需要后端显式声明允许来源。

第三坑：环境变量失效。本地跑通、线上崩掉，这是env变量作用域或命名前缀的 classic trap。作者逐个排查后修复，最终生产环境跑通。

整个过程没有架构图、没有性能数据，只有一个开发者的手工排查记录。

这件事的隐性成本

表面看，Vercel+Render的组合免去了服务器运维，但作者的经历暴露了真相：免费/低托管的代价是调试时间的转移。构建链路变长、跨域问题浮现、环境变量分散在两个控制台——复杂度没有消失，只是换了形态。

对于25-40岁的技术从业者，这组技术栈的吸引力在于"快速上线"，但决策前需要诚实评估：你的团队有多少个凌晨两点可以花在CORS和env调试上？

如果你正在选型，建议先用最小可行项目跑通完整链路，再决定是否押注生产环境。作者没说的那句话，我们替他说了：工具链的成熟度，不等于你的熟练度。