很多公司做官网时，都会顺带提一句：后台也一起做吧。听起来是顺手的事，实际做起来常常变成两套需求互相打架。
官网要好看、要快、要能被搜索引擎收录；管理后台要能改内容、能看数据、能分权限。两者共用一套数据，却服务完全不同的使用者。规划没做好，最常见的结果是：官网先上线，后台改一个字段，前端全崩；或者后台做完了，官网发现内容结构根本对不上。
这篇按实际项目顺序，把网站开发里官网加后台的规划讲清楚。
先分清两条线：展示逻辑和编辑逻辑
官网是展示逻辑，后台是编辑逻辑。这两条线要分开设计，但共用一份数据模型。
具体做法是先定内容模型，再定页面。比如企业官网常见的栏目：新闻、产品、案例、招聘。每个栏目有哪些字段、哪些必填、图片尺寸多大、是否支持多语言，这些在画页面前就要定下来。
避坑点：不要让后台直接对应页面模块。很多项目后台做成「首页第一屏文案」「首页第二屏图片」，结果官网一改版，后台全部作废。正确的做法是后台管内容，页面管呈现，中间靠字段映射。
另一个坑是权限。后台至少要有管理员、编辑、只读三种角色。这个在企业网站项目里经常被忽略，上线后才发现实习生能删数据。
排期上，后台应该先于官网完成数据层
比较稳的顺序是：数据模型 → 后台接口 → 后台界面 → 官网页面。
官网页面依赖真实数据，如果后台还没跑通，前端只能拿假数据做，联调阶段会集中爆问题。先让后台能录入、能修改、能返回正确结构，官网再对接，返工量会小很多。
举个具体场景：一家做设备租赁的公司，官网要展示设备列表和在线预约，后台要管理设备信息、预约记录和状态流转。如果先做官网，预约表单的字段和后台的记录结构很容易对不上，比如官网收了「期望租期」，后台只存了「开始日期」。这类问题在联调时才发现，改起来要动数据库。
所以排期上给后台留出至少三分之一的前置时间，不要把它当成官网的附属品。
接口先约定，别等页面画完再谈
官网和后台之间是接口关系。接口的字段名、类型、分页方式、错误码，最好在开发前写成一份简单文档。
不需要多正式，一页表格就够：接口路径、入参、返回示例、异常情况。这份东西能省掉大量口头沟通。
避坑点：图片上传。官网和后台都要处理图片，但要求不同。官网要压缩、要 CDN、要懒加载；后台要原图、要能裁剪、要能排序。上传逻辑最好统一在一个服务里，不要两边各写一套。
还有搜索和筛选。后台的筛选条件往往比官网复杂，如果接口设计时只考虑官网，后台就得再加一套查询。提前把筛选参数设计成可组合的，后面省事。
安全和管理员入口要单独考虑
后台是攻击面最大的地方。网站开发里经常被跳过的一步，是后台的安全测试。
至少要做的几件事：后台登录加验证码和登录失败限制；管理员密码强制复杂度；接口做权限校验，不能只靠前端隐藏菜单；操作日志留痕。
如果是小程序开发或App开发项目，后台往往还要对接多个客户端，权限模型会更复杂。这时候建议把后台拆成「内容管理」和「业务管理」两块，前者给运营，后者给业务人员，减少误操作。
避坑点：不要用官网的同一套账号体系管后台。前台用户和管理员必须是两套表、两套登录逻辑。
验收标准要提前写，不要上线前才想
官网的验收看加载速度、移动端适配、SEO 基础项（标题、描述、结构化数据）。后台的验收看三件事：能不能完整录入、能不能正确展示到官网、权限对不对。
建议列一张验收清单，每条对应一个可操作的检查动作。比如「新增一条新闻，官网列表页 1 分钟内出现」「编辑角色无法删除数据」「图片上传后官网显示不超过 300KB」。
清单在项目开始时就和开发对齐，比上线前临时提要求有效得多。
什么情况适合找 MIC Studio
如果团队里没有专职后端，或者官网和后台要同时赶一个时间点，外包一部分是合理的。MIC Studio 做企业网站和后台一体化开发时，通常会先帮客户把内容模型和接口约定理一遍，再进入开发。
适合找我们的情况：官网需要改版同时后台要重构；预约、报名这类带业务流的官网；后台要对接小程序或 App 的多端项目。如果只是改几行文案，没必要走完整项目流程。
三条可执行建议
第一，动手前先写一页内容模型，把栏目、字段、必填项定下来，官网和后台都按这份走。
第二，排期上让后台的数据层先跑通，官网再对接真实接口，减少联调返工。
第三，上线前做一次后台安全检查和权限测试，别等出事再补。