第3步 应用预检（genui check）

genui check 是接入流程里最关键的质量闸门。它在你提交审核之前，就把绝大多数平台红线在本地拦下来。这一步过不了，后面提交必被驳回。

它检查什么

genui check 对照预检清单（checklist）从六个维度扫描产物：

  1. 产物结构：入口是否为根目录 index.html、资源是否平铺、是否在 8MB 与后缀白名单内。
  2. 代码合规：是否出现外链、iframe、跳转、eval、第三方脚本 / CDN、Worker / WASM、localStorage 等禁止项。
  3. 视觉规范：是否使用 --cos-* 视觉 token、有无硬编码颜色、字号是否小于 14px。
  4. 交互规范：滑动条是否 ≤ 4、按钮是否 ≤ 2、是否 1:1 正方形响应式。
  5. 资源合规：图片 / 字体是否在白名单后缀、是否引用外部资源。
  6. 数据打点：是否正确接入 genui.sendLog 且调用前判存在性。

常见被拦项（实战高频）

  • 外链 / iframe / 跳转：想「直接打开网站」会被直接判违规。把网站做成小工具，正确做法是内置数据快照 + 本地交互，而非套壳跳转。
  • 硬编码颜色：CSS 里写 #fff、rgb(...) 会被拦，必须改用 var(--cos-color-*) 等 token。
  • 字号 < 14px：小于 --cos-text-body（14px）会被拦，全部改用 token 字号。
  • 第三方脚本 / CDN：产物必须自包含，任何指向外部 http(s) 的脚本标签（script 的 src 外链）都会被拦。
  • localStorage / eval / alert：运行时存储、动态执行、系统弹窗一律禁止。

如何运行与判读

genui check ./your-tool-dir

命令以退出码表达结果：

  • exit 0：检查通过，可以继续提交。
  • 非 0：终端会列出具体违规项，逐条修复后重跑。

实战中两个小工具都是 genui check 双卡通过（exit 0）后才进入发布环节。

经验：把 check 当「本地 lint」

不要等写完才跑一次。建议边写边跑：每完成一个模块就 genui check 一次，把合规问题消灭在迭代过程中，避免最后堆积大量违规难以定位。

小结

第三步的产出是：一个 genui check 退出码为 0 的合规产物。这是个硬性门槛，过了它，提交审核才稳。