小程序前后端开发的协作，本质上是一次页面加载的完整时序：前端在特定生命周期发起请求，后端按约定格式返回数据，前端拿到数据后渲染页面，用户操作时再触发下一轮请求。理解这套时序，比记API名称更重要——知道什么时候该请求、请求回来后该做什么，页面才不会出现白屏、闪烁或数据错乱。

一次页面加载的完整时序

前端在哪个时机发请求

小程序页面有标准生命周期：onLoad（页面首次加载）、onShow（页面每次显示）、onReady（初次渲染完成）、onHide（切到后台）。列表页和详情页这类需要数据的页面，请求通常放在onLoad里发一次，因为onLoad只执行一次，适合拉取初始化数据。但如果数据会被用户在其他页面改动（比如购物车数量），就要在onShow里再请求一次，因为用户从别的页面切回来时onLoad不会再触发。

时序选错是常见bug来源。把请求放在onReady里，如果后端数据要几秒才回来，onReady早就执行完了，页面先渲染了空数据。正确做法是onLoad发请求，请求未返回时页面显示加载骨架屏，返回后再渲染真实数据。承德做交易类小程序时，这个时序尤其重要：用户付完款跳回订单列表，onShow必须重新拉订单状态，否则用户看到的还是"待付款"。

还有一个细节：页面onUnload时如果还有未完成的请求，要做取消处理。用户从列表页点进详情页又立刻返回，详情页的请求还在后台跑，回来后返回的数据要丢弃，不然旧数据会覆盖新页面。这种边界情况不处理，快速跳转时就会出现数据闪现错乱。

后端返回后前端怎么接管

后端返回的不是直接拿来渲染的HTML，而是JSON数据。前端拿到JSON后，要做三件事：判断业务状态码、提取业务数据、调用setData把数据交给视图层渲染。状态码和HTTP状态是两回事——HTTP 200只说明网络通了，业务上可能是"登录过期""商品已下架"。前端必须先看业务状态码，再决定渲染什么。

数据提取时还要做容错。后端某个字段没返回，前端不能直接读它的length然后报错。正规做法是给每个字段设默认值：商品图片没返回就用占位图，价格没返回就显示"--"。这种容错写在数据层，渲染层就不会崩。承德用户机型碎片化严重，低端机上网络慢、接口超时概率高，容错做得好不好直接影响崩溃率。

前后端接口协作的关键约定

统一数据格式与状态码

项目开始前前后端要约定一套统一响应格式：code（业务状态码）、message（提示信息）、data（业务数据）。code为0表示成功，其他数字各代表一种错误。前端所有请求都走同一个封装好的请求函数，函数内部统一判断code，业务页面只关心data。这样后端改错误码时，前端不用每个页面都改。

列表数据的格式也要约定：列表接口返回total（总数）和list（当前页数据），分页参数统一用page和pageSize。前端写分页组件时不用关心后端怎么存的，后端改数据库结构时前端也不用动。约定越清楚，联调越快。

缓存策略与请求时机

不是每次进页面都要请求后端。用户基本信息这种变动慢的数据，第一次请求后存在本地缓存里，后续打开直接读缓存，同时后台悄悄拉新数据替换。这种"先渲染缓存再后台更新"的策略，让二次打开页面秒开，不用等网络。

但订单、购物车这种强一致数据不能用缓存。用户在A设备下了单，用B设备打开，本地缓存里还是旧数据，必须强制从后端拉。承德用户多设备切换频繁，购物车不同步会直接导致漏单。什么数据用缓存、什么数据直连后端，前后端要在项目初期就列清楚，不能前端随手存、后端随手改，最后数据对不上。

异常场景怎么协作

网络超时和弱网是真实场景，前端请求要有超时时间（一般十秒），超时后给用户提示"网络不太好，点击重试"，而不是一直转圈。后端要支持幂等：同一个请求重复发，结果一样，不会重复下单。这样用户网络不好点两次提交，后端不会生成两笔订单。幂等通常靠在请求里带唯一请求ID实现，后端收到重复ID直接返回上次结果。

联调阶段还有一个协作动作：后端接口文档要和代码同步更新。后端加了个字段、改了个状态码，文档里要立刻改。前端按文档对接，文档不同步就会对不上。正规团队用接口文档工具，后端改代码时自动生成文档，前端实时看最新版。文档靠口头通知的团队，联调效率一定低。另外接口报错时后端要返回可读的错误信息，不要只返回"系统错误"，前端拿到这种信息根本没法排查问题。

前后端协作的基础原理说到底就是一句话：前端管什么时候要数据、拿到数据怎么显示，后端管数据怎么来、返回格式怎么统一。两边把时序和格式约定好，开发效率自然就上来了。理解小程序前后端开发基础原理，不是为了背概念，而是让前后端工程师在项目一开始就对齐节奏，少在联调阶段互相扯皮。