审核对象：《miniprogram-v2 × 白标化 DSL 对接设计》（送审稿）｜结论：修改后通过

阶段性审核结论

总评：修改后通过。当前稿不应直接批准进入存量替换和生产出包；可以开展隔离原型。

方向基本正确：构建期租户注入、有限白名单组件、禁止逻辑注入，适合单租户复制模式。但当前稿把几个关键工程能力写成了口号：

• “try-catch 隔离”不等于组件故障边界。
• “首页 JSON 置空”不等于生产回滚。
• “入口开关”不等于模块关闭。
• “site-texts 治理日志”不等于 DSL 全链路审计。
• “首页试点可用”不等于“92 页白标化完成”。

最大风险不是 DSL 太复杂，而是租户边界、发布边界、失败边界没有闭合。

以下严重级定义：

• P0：上线阻断——可能造成错租户、越权、主流程不可用、回滚失效或审核阻断。
• P1：试点／扩面阻断——原型可以做，但必须在对应里程碑前解决。
• P2：工程完善项——不单独阻断原型，但要纳入交付。

一、DSL 渲染器：暂未踩红线，但目前约束不够

白名单 wx:if 分支本身没有问题，首版甚至比动态注册机制更容易审计。组件自包含取数也不是原罪。

真正的 DSL 泥潭，不取决于组件数量，而取决于 DSL 是否开始承载程序语义。 一旦增加任意接口地址、表达式、条件判断、循环、跨组件依赖、通用事件编排，就会从“页面装配”变成“自造低代码运行时”。

1. 白名单没有形成可执行契约

严重级：P1

问题：

目前同时存在“14 类”“15 类”“首版实现 6—8 类”三种口径。允许某个 type，不代表当前安装包真的能渲染它。weather-strip 也不能由前端单方面加进依赖件白名单。

建议：

建立版本化组件注册表，至少包含：

type / 组件契约版本 / props schema / 允许的 source / 允许的 action / 对应模块 / fallback 策略 / 当前是否实现

发布校验必须同时满足：

1. 甲方批准的白名单允许；
2. 当前构建已实现并静态注册；
3. DSL 使用的契约版本兼容。

批准 15 类、只实现 8 类可以；本次页面引用未实现的第 9 类不可以。不能靠运行时 fallback 掩盖缺件出包。

2. “组件树”与输入协议不一致，DSL 边界未封死

严重级：P1

问题：

示例只有 components:[{type,props,id?}]，没有说明子节点在哪里；却又提出树深和循环检测。layout、事件、跳转及跨组件通信也没有定义。

后续实现者极容易用“临时扩个字段”补出一门脚本语言。

建议：

首版二选一：

• 首页只需纵向装配：明确采用平铺区块列表，先不做通用组件树；
• 确实需要嵌套：定义唯一的 children 位置、允许嵌套的容器类型及深度计算方法。

同时写死禁区：

• 不允许表达式、脚本、任意 URL、动态服务名、任意事件处理器；
• 跳转只能使用批准的 routeId + 参数 schema；
• 不允许跨组件取值和数据依赖编排；
• 页面业务流程保留在代码中，不塞进 DSL；
• 节点 ID 在页面内唯一且稳定。

如果不支持节点引用，普通 JSON 树本身不会产生引用环；循环检测必须说明检测的是哪种引用关系，不能只列名词。

3. 组件自包含取数缺少资源治理

严重级：P1

问题：

30 个组件可能发出 30 次请求，重复请求、登录态竞态、旧请求覆盖新状态、组件卸载后回写都没有约束。“树深 ≤3、组件数 ≤30”不能保证性能。

建议：

组件可以自包含展示和取数，但必须统一经过数据访问层。sources.js 应定义：

• source → 固定 service 方法；
• 请求参数 schema、返回 DTO；
• 身份要求和模块依赖；
• 超时、重试上限、缓存与请求去重；
• 并发预算、分页上限、卸载／过期请求处理；
• 缓存按环境、租户、用户身份正确隔离。

DSL 不得覆盖请求域名或注入任意查询条件。页面验收增加首屏请求数、关键内容可见时间、setData 数据量、包体增量预算。

4. try-catch + 占位不是可靠故障隔离

严重级：关键链路 P0；普通展示组件 P1

问题：

同步 try-catch 不能统一捕获异步请求、组件生命周期、事件回调及所有渲染异常。微信小程序也不能直接套用其他框架的错误边界假设。

统一 flat fallback 还有业务风险：支付、授权、提交入口坏了，不能显示一个占位块就算降级成功。

建议：

拆成明确机制：

• 渲染前输入校验；
• 异步调用统一捕获；
• 组件显式上报 ready / empty / error；
• 页面基于必需组件集合判定成功，不被非关键天气组件拖成整页失败；
• 非关键组件：隐藏或占位；
• 关键组件：禁用操作、明确错误、提供安全返回／重试；
• 页面不可用：切换本包内已验证的静态页。

全局异常处理用于观测，不承担局部恢复。M1 必须做故障注入，而不是只测正常 JSON。

二、迁移策略：共存正确，当前回滚设计不成立

5. “JSON 置空”不是生产回滚开关

严重级：P0

问题：

JSON 是构建打包进去的，线上用户不会因为仓库文件被置空就切回静态首页。重新构建、上传、审核／发布需要时间。用户端还可能存在不同版本。

此外，“缺文件、空文件、损坏文件、主动关闭”被混成了一种状态。

建议：

改成显式状态，例如：

home.renderMode = static | dsl

区分三层能力：

1. 包内故障降级：校验失败时自动使用已打包静态页；
2. 构建期开关：决定下一安装包使用哪个实现；
3. 生产止损机制：若需要即时关闭，单独设计仅切换已编译实现的受控配置，约束缓存、离线默认值、权限及日志，并核对平台规则。

另写平台发布回退操作手册，明确适用条件和限制。不要把配置文件修改包装成即时生产回滚。

6. 替换后立即删除旧页，与保留回退互相矛盾

严重级：P0

问题：

删除旧实现后，页面级 fallback 可能不存在；老分享链接、二维码、消息入口、收藏路径可能失效。页面重命名还可能影响 app.json、分包和 tabBar。

建议：

• 试点期间保留静态实现，且确保它实际进入产物；
• 不轻易改变既有页面路径和参数协议；
• 新旧实现通过同一路由适配切换；
• 为 92 页建立路径、参数、外部入口、依赖和替代关系清单；
• 达到观察窗口及明确删除条件后，才清理旧实现。

“替换通过”与“允许删除”应是两个审批点。

7. 冻结期做全局标尺收敛，不属于非侵入工作

严重级：P0（若进入冻结发布分支）

问题：

修改共享 WXSS、字号、颜色或公共组件，即使没有替换页面，也会影响现有 92 页。宣称“渲染器 bug 不影响静态页”同样依赖隔离措施，不是天然成立。

建议：

冻结期只允许：

• 隔离分支中的脚本、原型和测试；
• 未被发布页面引用的新组件与样式；
• 不改变线上产物的配置验证工作。

全局样式收敛移到发布后独立批次。新主题先限制作用范围；禁止在试点时顺带修改所有共享组件。

8. 默认租户与回退页可能造成跨租户泄漏

严重级：P0

问题：

default.config.js = kailash 现状基线 与“零硬编码品牌”冲突。新租户缺配置时，可能静默显示神山品牌、域名、商户或推荐内容。静态 fallback 也可能残留原租户值。

建议：

• 神山现状基线作为独立测试 fixture，不作通用生产默认值；
• 生产必填身份、域名和品牌缺失时直接失败，不能退回神山配置；
• 默认值只允许明确的租户无关技术值；
• 静态回退页与 DSL 页使用同一租户配置体系；
• 用两个明显不同的租户连续构建，检查产物、缓存和日志是否残留前一租户值。

品牌色扫描要有语义分类，不要把正常状态色也机械替换成品牌色。

三、四段校验：都有提到，但没有形成闭环

9. 发布前校验太窄，且没有成为强制关卡

严重级：P0

问题：

目前只写 DSL 的 schema／白名单／资源／循环，没有说明是否验证生成产物、模块一致性、路由、组件注册和租户身份。脚本存在，也不代表 CI 必然执行。

建议：

强制构建链路：

tenant 校验 → 临时目录生成 → 产物交叉校验 → DSL 校验 → 编译／自动测试 → 出包 → 产物清单

增加检查：

• tenant、DSL、组件注册表的版本兼容；
• source、action、路由、模块开关之间一致；
• usingComponents、页面／分包注册完整；
• 编译可用的本地资源及允许的远程资源地址；
• 图片、富文本链接等 URL 的协议与域名规则；
• 包体、分包及目标基础库兼容性；
• 生成身份与实际上传目标一致。

资源“存在”不等于资源“可信、合规、可访问”。生产已知配置错误应阻断发布，运行时降级处理的是剩余故障。

10. 审计落在 site-texts，位置错了

严重级：P1

问题：

内容治理日志只能说明文案如何变更，不能证明哪个租户用了哪个 DSL、谁发布了什么包、为何触发降级。

建议：

分开三类记录：

1. 配置审计：操作者、变更、审批、tenant／DSL 版本与哈希；
2. 构建发布审计：代码提交、构建编号、目标 appid、产物摘要、验证结果；
3. 运行事件：包版本、页面、组件 ID／type、source 标识、错误码、降级结果。

建立关联 ID。禁止直接上传 token、完整用户数据或敏感 props；明确采样、限流、保留期。审计链路故障不得拖垮页面。

11. 降级缺少可验证的分级策略

严重级：P1

问题：

“组件三态、页面超时、flat fallback”没有定义失败优先级、重试行为、是否循环降级，以及如何避免误导用户。

建议：

补一张故障矩阵，至少覆盖：

• 未知 type／非法 props；
• source 超时／无权限／返回结构错误；
• 图片失败；
• 单组件异常；
• 必需组件失败；
• DSL 缺失或损坏；
• fallback 本身失败。

每项写明：发布是否阻断、运行表现、重试上限、日志、最终安全状态。fallback 不再依赖出错的 DSL 链路。

四、tenant 与微信平台：遗漏的是交付边界，不只是字段

12. modules 只控制入口，关闭不彻底

严重级：P0

问题：

用户可以通过分享路径、二维码、历史页面或自定义 tabBar 之外的入口进入页面。隐藏首页宫格不等于模块关闭。

建议：

模块映射表必须覆盖：

模块键 → 页面／路由 → 导航入口 → DSL 组件 → source → 后端接口／权限

前端做入口控制和页面加载守卫；后端独立校验模块启用状态与权限。若按模块裁剪包内页面，必须同时生成并校验路由、分包、tabBar 和分享链接策略。

13. roles、classification、seed、compliance 没有消费契约

严重级：P0（权限、合规和关键引用）；其余 P1

问题：

tenant 是唯一声明源，不代表所有字段都应直接注入前端，也不代表前端可以忽略它们。

建议： 补齐职责表：

角色和模块关闭时应禁用什么，登录态变化时如何刷新，必须定义。不要把角色分配数据或种子用户凭据打进小程序。

14. appid 注入不等于微信平台接入完成

严重级：P0

问题：

写入 site.js 不会自动完成微信后台域名配置、登录身份匹配、隐私配置、类目资质或支付接入。“构建时注入，所以微信合规”这一判断不成立。

建议：

初始化交付增加平台核对单：

• 项目配置、构建配置、miniprogram-ci 上传目标 appid 一致；
• 后端登录服务使用该小程序对应凭据，用户身份隔离正确；
• 按实际能力核对请求、上传、下载、socket 及业务域名；
• 按实际接口核对隐私保护指引、声明与授权流程；
• 类目、资质、审核说明及必要的审核账号；
• 如启用支付、订阅消息等，核对租户专属关联与标识。

AppSecret、上传私钥、支付密钥只能留在受控服务端／CI，不得进入前端配置或日志。appid 本身不是秘密，但错配是生产事故。

15. 与初始化脚本只有“接收注入”的描述，没有接口合同

严重级：P0

问题：

件三要求幂等、回滚；当前 inject.mjs 没说明输入输出、退出码、覆盖策略、失败清理和验证责任。脚本重跑可能保留上一个租户的生成文件。

建议：

补齐：

• 输入 schema 版本、工程版本、环境和输出目录；
• 完整生成产物清单与安全字段白名单；
• 临时目录生成、校验成功后整体替换；
• 清理过期生成文件，禁止带残留增量复制；
• 确定性生成、哈希、退出码、失败诊断；
• 生成失败不触碰上一份有效产物；
• 前端产物与后端 seed／接口版本的兼容关系；
• 明确本脚本只回退自身产物，不冒充整个初始化流水线回滚。

件三原定 9 项前置校验、9 项产物、4 项验证，应逐项标明“本工程负责／上游负责／交付凭证”，不能只引用“段二·8”。

16. 输入 schema 已出现漂移

严重级：P1

问题：

背景 brand 包含 slogan，设计反复写 splash；identity/domains 映射到 config/site.js，目录树却没有这个文件。也没有说明 brand 名称来自哪里。

建议：

以甲方正式 schema 为准，提交逐字段映射：

源字段 → 是否必填 → 默认策略 → 生成位置 → 消费方 → 验证规则

splash 如未定义，应走 schema 变更，不能默认为已有能力。slogan 等已定义字段不能静默丢失。工程扩展参数必须有独立命名空间和版本。

五、完成标准：当前设计还不能证明“第 4 步完成”

17. “92 页不动”和“全量 DSL 化”都不是可信交付口径

严重级：P1

问题：

未改造页面仍可能写死品牌、分类、内容 ID、域名和角色。反过来，登录、支付、地图等业务页也不应为了“全量”硬塞进通用 DSL。

商户页独立实现可以，但不能成为白标化豁免区。

建议：

把两个目标分开验收：

1. 白标化覆盖率：全部页面及前后端接入关系消除不受控的租户绑定；
2. DSL 覆盖率：适合配置装配的页面采用 DSL，强业务页保留代码实现。

92 页逐页归类：

• DSL 装配页；
• 白标化代码页；
• 保留／下线页。

每页记录品牌、模块、角色、路由、数据引用、合规检查及测试结果。将“存量页=DSL 页的组件集合”改成可核验的范围说明。

18. 出包流水线放到 M4，风险发现太晚

严重级：P1

问题：

到全量迁移后才接真实出包，可能才发现 appid、路径注册、分包、包体、依赖件版本不兼容。

建议： 改里程碑，不要等 M4 才验证集成：

性能阈值在 M1 前基于现有首页测量后冻结，不能验收时再解释“差不多”。

最终判断

对五个审核要点的直接回答：

1. DSL 泥潭：暂未踩线，但白名单不足以兜底。 必须补齐组件、source、action、版本和数据访问契约，禁止 DSL 承担业务流程编排。
2. 迁移：共存方向正确，删除和回滚方案不合格。 当前存在真实上线事故风险，尤其是本地 JSON 伪回滚、冻结期全局样式改动及跨租户默认值。
3. 四段校验：名义齐全，工程未闭环。 发布门禁不完整、运行时隔离表述失真、降级缺策略、审计落错位置。
4. 对接面：有重大遗漏。 roles、seed、classification、compliance、微信平台配置及初始化脚本责任边界都必须补。
5. 第 4 步完成：目前不能认定。 本稿能支撑首页原型立项，不能支撑“可复制白标系统已完成”的验收。

结论：修改后通过。保留现有技术路线，不必重做；但先补契约、构建闭环和止损能力，再动 92 页。不要用“先做首页，其他后补”把这些基础问题推迟到上线前。