这几年只要聊网站开发，几乎都会被推荐"前后端分离"。它确实解决了不少问题，但对一个只有二十个页面的企业官网来说，这套架构可能带来的麻烦比好处多。
两种模式到底差在哪
传统模式下，服务器把数据和页面拼好，一次性发到浏览器，用户拿到的是完整 HTML。分离模式下，服务器只提供数据接口，浏览器拿到数据后自己拼出页面。
差别带来的结果很不一样：
- 传统模式：首屏快、利于收录、部署简单，但如果以后要做 App 或小程序，接口得重写
- 分离模式：一套接口可以给网站、小程序、App 共用，前端可以独立迭代，但首屏依赖 JavaScript，部署多了一套环境
值得做的情况
符合下面任意一条，分离模式就划算：
- 同一个后端要服务多个端：官网、小程序、内部系统共用一套数据和业务逻辑
- 页面交互很重：大量局部刷新、实时数据、复杂状态，传统模板写起来会很别扭
- 前后端团队分开：两边并行开发，接口约定清楚后互不阻塞
- 前端要频繁改版：视觉和交互三两个月动一次，后端不动
不值得做的情况
反过来说，如果只是做这些内容，分离带来的收益覆盖不了它的成本：
- 标准的企业展示站，内容为主，交互很少
- 团队只有一个全栈开发，或者连专职前端都没有
- 网站做完一两年不会大改
- 主要流量来自搜索，对收录速度和稳定性要求高
这种情况下做分离，等于多养一套运行环境、多一层出错可能，而好处基本用不上。
如果做了，要注意什么
决定了走分离，几件事必须提前安排：
- 接口文档先行：前后端按同一份约定开发，推荐用 Swagger 或类似工具自动生成
- 解决首屏渲染：企业站一定要上服务端渲染或预渲染，否则收录和首屏速度都会受影响
- 统一错误处理：接口报错、超时、登录过期，前端都要有明确表现，不能白屏
- 接口版本管理：路径里带版本号，比如
/api/v1/products，以后升级不会牵连旧端 - 跨域与安全：配置好允许的来源，接口要有身份校验和频率限制
一个折中方案
还有一条路值得考虑：页面主体用服务端渲染保证速度和收录，复杂模块用前端组件局部增强。比如列表和详情是服务端输出的，而筛选器、计算器这类交互模块用框架实现。
这种混合方式在不少项目里效果不错，既保住了搜索引擎友好，又没牺牲交互体验。
架构没有先进落后之分，只有匹配不匹配。选错了，先进的东西会变成持续的成本。
—— 一位做过多次架构迁移的技术总监