微信小程序：同一份内容，原生渲染于微信

一个 Zeso 站点只有一份数据面：内容集合、类型化数据行、一道发布闸门。现在它有两个渲染面——网页，以及一个读取同一份已发布内容、原生运行于微信的小程序。这一页如实说明已经交付的东西，因为诚实的清单比营销版本更短，而两个渲染面之间的边界正是站主需要知道的部分。

已交付：一份 JSON 文档

每个站点的线上内容都以一份 JSON 文档的形式提供，地址是 https://{your-domain}/api/miniprogram。一次请求带回整个站点：它的内容 集合、集合的类型化字段定义，以及每一条线上数据行——与发布所提升的版本 完全一致。

文档携带站点的内容版本号——就是面板上显示为 v1、v2、v3 的那个计数器， 机制详见缓存与内容版本一文。客户端在下次请求时带上该版本号，只要下一次 发布还没发生，就会收到一个空的 304 响应——没有变化时，下拉刷新不花任何 代价。这个版本检查是唯一的新鲜度机制。不存在单独的「同步到小程序」步骤， 因此也没有东西会被忘记。

富文本以纯段落块、绝不带 HTML 的形态到达。小程序渲染器从不需要解析 平台没有审核过的标记——与网页渲染器靠转义执行的同一条规则，提前一层 生效。段落在哪一个渲染面上都是段落。

它继承的规则

三条规则从网页渲染面原样继承，因为它们属于数据面，而不属于任何渲染器：

• 只有线上。 内容源是对线上数据行的公开读取。对小程序而言，暂存与草稿

数据行并不存在。

• 发布是唯一的提升。 发布提升了什么，内容源就携带什么——同一道闸门，

同一次版本号递增，没有第二条路径。

• 一份文档对应一个站点。 内容源只对你的域名提供，不携带任何其他站点的

内容。

参考渲染器

仓库里的 miniprogram-renderer/wechat/ 是一份原生微信小程序参考渲染器。 它是起点，不是成品：站主把它指向自己的域名，在微信小程序后台把该域名加入 request 合法域名白名单，然后用微信开发者工具打开项目。它拉取整份文档、把每 个类型化字段映射到原生组件，以内置默认样式渲染发布所提升的内容。

渲染器刻意做成原生——平台审核中更少的活动部件，你的内容与屏幕之间也少了一层 框架。

在依赖它之前，有一个字段映射的细节值得了解：内容源携带的字段类型与存储完全 一致。文本是文本，数字是数字，图片以 URL 字符串的形式到达——渲染器自带加载 失败占位符，所以一张坏图是数据行里待修复的内容问题，而不是渲染器崩溃。日期 字段按原样显示，不会被重新解析成平台从未承诺过的格式。

尚不存在的东西

与已交付部分同样直白地写出来：

• 尚未接入 Studio。 构建器的面板里还没有小程序面板。
• 不能一键发布到微信。 部署渲染器仍是站主手动完成的步骤。
• 尚未内置抖音版本。 抖音移植已有规范，随后跟进。
• 没有主题定制。 渲染器以内置默认样式渲染发布所提升的内容；主题令牌

保留到后续阶段。

渲染器渲染发布所提升的内容。仅此而已——而逐条列出缺口，正是为了不假装任何 东西。

网页渲染与小程序渲染，并列对照

把这张表读作同一个故事的两列：呈现一行以上的内容全部共享，因为内容、发布 闸门与版本新鲜度都是数据面的属性。从呈现一行起往下则不同，因为模板库、 request 合法域名白名单与审核流程属于渲染面，而不属于内容。