后端：不要直接复用默认接口
WordPress 自带的 REST API 能直接返回文章、分类、评论等数据，但默认返回的字段是面向通用场景的：包含大量小程序用不到的字段（编辑器相关、作者详细信息等），既增加传输体积，也暴露不必要的信息。
因此建议在服务端做一层面向小程序的输出接口：要么注册自定义接口，要么对既有接口的输出做裁剪与补充。需要处理的三件事：
- 字段裁剪：只保留小程序渲染真正需要的字段（标题、摘要、封面、发布时间、分类、阅读数等）；
- 字段补充：把小程序需要的派生信息在服务端算好（如格式化后的时间、分类名称数组），减少前端计算；
- 结构统一：把不同内容类型的数据结构对齐，避免前端为每种类型写一套解析逻辑。
跨域、鉴权与缓存
跨域：小程序端的请求不受浏览器同源策略限制，但若同一套接口还要供 H5 使用，就必须在服务端正确配置跨域响应头，并明确允许的来源、方法与请求头，不要图省事一律放开。
鉴权：公开内容走匿名访问即可；涉及用户数据（收藏、积分、订单）的接口必须带身份凭证。常见做法是登录后由后端签发令牌，前端在请求头中携带，服务端对每个敏感接口逐一校验，而不是依赖前端判断。
缓存：内容型接口读多写少，适合缓存。建议按内容类型设置不同的缓存时效——列表类接口短缓存保证时效，详情类接口可适当延长；同时在内容更新时主动失效相关缓存，避免用户长时间看到旧数据。
数据契约：先约定，再编码
前后端并行开发时，接口结构必须先约定并文档化。约定内容至少包括：字段名与类型、可空性、时间格式、分页参数与返回结构。实践中容易踩的坑有几个：
- 可空字段未标注：作者信息有时是对象、有时是字符串、有时为空，前端按对象取值就会报错；
- 分页结构不统一：不同接口的列表返回结构不一致，前端要写多套解析；
- 类型不一致：数字与字符串混用（如 ID 有时是数字有时是字符串），比较与索引时出错。
前端：结构规范化与容错兜底
前端不应假设后端一定返回完整、正确、符合预期的数据。建议在请求层统一做两件事：
- 结构规范化：把接口返回的数据在进入页面之前统一转换成页面期望的契约——缺失的字段补默认值，可空字段统一成一种类型，列表字段保证是数组而非
null； - 安全取值：模板中避免直接访问可能不存在的深层属性，改用返回安全默认值的方法或可选链取值，确保个别字段缺失时页面不白屏。
同时注意请求层的统一封装：统一处理加载中、失败重试与错误提示，避免每个页面各写一套；对失败请求给出可理解的提示，而不是把原始错误直接抛给用户。
小结
用 WordPress 作为小程序后端的价值在于复用成熟的内容管理能力，而工程风险集中在两处：服务端的输出裁剪与鉴权、前端的数据规范化与容错。接口结构约定清楚、异常情况有兜底，这条链路才能长期稳定运行，而不会因为某个字段偶尔为空就整页报错。