上传成功，审核通过，用户点开——一片空白。修好之后，出现了更奇怪的现象：页面能打开了，底栏按钮也能跳转，但页面里的任何按钮点了都没有反应。这是我们第一次走完"改了代码还得等审核"的那条路。
微信里跳出来三张手机截图。第一张是扫码之后的白屏；第二张是某个页面卡在加载中途；第三张能看清底部的三个按钮，但页面内容区是空的。
配的文字很短：「扫描之后呈现的是这样，不能互动，如何解决。」
这就是人机协作里最常见、也最珍贵的输入：一线现场。代码、日志、控制台，这些东西机器都能读到；但"用户的手机上究竟显示了什么"，只有人把它带回来。那三张截图之后所有的排查，都是从这句话开始的。
"扫描之后呈现的是这样，不能互动，如何解决。" —— Lab 负责人发来的第一句现场描述（这句话后来成了全案的钥匙）
面对"真机上一片空白"，工程视角的第一反应往往不是"代码写错了"，而是"资源没到位"。
小程序在打包上传时有一套体积与加载优化机制：有的开关会让组件"按需注入"，有的会在上传时剔除"看起来没被用到"的文件。这套机制在开发工具里通常不会暴露问题，但在真机上，一旦配置与代码的实际引用关系对不上，就可能出现"工具里好好的、真机一片空白"这种最典型的症状。
结果：审核通过了，问题没有解决。空白依旧，只是换了一副面孔。这一轮我们承认是走错了方向——但它是必要的：它把"构建配置"这一整类嫌疑从名单上划掉了。
第二版上线之后，现象变了。以前是「什么都没有」，现在变成了一组更奇怪的组合：
| 部位 | 表现 | 说明 |
|---|---|---|
| 底部三个导航按钮 | 能跳转 ✅ | 切换页面正常，说明小程序框架本身是活的 |
| 页面里的"今日打卡"按钮 | 点击无反应 ❌ | 按钮画得出来，但事件没有被执行 |
| 底部导航可进、微课列表可显示 | 能渲染 ✅ | 数据与样式都没问题 |
| 点进微课内页 | 一片空白 ❌ | 页面渲染完成之后像是"停住了" |
到这里，「不能互动」这四个字终于有了精确的形状：能看的都能看，能点的都不能点。
我们没有继续猜，而是去找差异——因为差异里一定藏着原因。
底栏是框架层接管的能力。它由小程序容器负责，不需要页面的脚本参与，所以它一直好着。
页面里的按钮靠页面自己的脚本绑定事件来响应。如果这个脚本没有跑完、或者被卡住了，按钮就只是"一张图"。
于是结论浮出来了：这不是"某个按钮坏了"，而是"整个页面的脚本线程被占住了"。
这是本次排障里最关键的一步，也是我们上一次处理公众号关键词问题时用过的同一种方法——用一次对照，把"哪里坏"变成"哪一类坏"。范围一旦从"系统里的一切"收缩到"某一类东西"，剩下的就只是时间和耐心。
拿到"线程被占住"这个方向之后，剩下的工作变成了逐行读代码、逐一比对调用方式。真因非常小，小到一句话就能说完：
这正是那个诡异现象的来源：页面能画出来（渲染已完成），但页面上的一切都点不动（脚本线程被占满）。
修复只需要一个字符级别的改动——让函数的签名与调用方式对上。新版本提审、通过、发布。上线后逐项实测：打卡成功、连续记录正常累计、微课列表渲染完整。
这一轮里有一个分工上的事实，值得单独记下来。它不是设计出来的，是被现实逼出来的：
中间还发生了几件小事，也都记下来，因为它们是一线操作的真实摩擦：
这些都不是缺陷，是流程的分层。它们提醒我们一件事：给这个场景写的操作手册，要写给"手上只有一部手机的人"，而不是写给"坐在开发工具前的人"。这条纪律，我们决定写进后续所有平台的操作说明里。
| 现象 | 先查这里 | 判定与动作 |
|---|---|---|
| 扫码 / 打开是空白页 | 构建类开关（按需注入、剔除未使用文件等） | 逐个关闭后重新上传，观察是否恢复 |
| 开发工具正常、真机空白 | 同上 + 是否依赖了工具环境下才有的能力 | 以真机为准，不要用工具环境下结论 |
| 页面能看、点任何按钮都没反应 | 页面脚本是否空转或卡在长循环里 | 二分法定位到具体页面，再逐个比对函数签名与调用 |
| 底栏能跳、页内内容不能点 | 框架正常 ⇒ 问题在页面逻辑层 | 直接聚焦该页面的脚本，不必再查框架 |
| 只有一个页面异常、其他正常 | 该页面独有的初始化逻辑 | 优先看时间、循环、递归这三类函数 |
| 修复后要上线 | 提审 → 审核 → 发布 → 真机验证 | 留出审核时间，不要卡在节点前才动手 |
方法论一句话：先分流"哪一层"（框架层 / 逻辑层 / 构建层），再定位"哪一行"。分层之后，问题就从"整个小程序"缩小到了"一个页面的一个函数"。
修好之后我们重新走了一遍完整链路：扫码 → 进入小程序 → 打卡 → 记录累计 → 打开微课列表 → 按卡片指引去公众号回复关键词看视频。每一环都通了。
回头来看，小程序是这个生态里最难合龙的一段，原因有两个，都跟技术难度无关：
网站改完刷新就能看到，公众号改完等几分钟也能看到。小程序改了代码要提审、等审核、再发布——一次修复的成本，是别处的很多倍。
没有哪台服务器能替我们回答"用户扫码之后看到了什么"。所以每一次修复，都必须回到真机上重新走一遍。
这次我们什么都没损失——没有丢数据，没有出错。它只是有一个白屏，和一群点不动的按钮。
但我们把它当成一件大事来追，因为用户对系统的信任，是靠"每一次点下去都有反应"累积起来的。一个页面点不动，他不会想你哪里写错了，他只会想：这个东西可能还不太行。
把那行函数改对，只需要一分钟。让它走到用户面前，要等一个审核周期。这就是"做产品"和"写代码"之间的距离。