同一个页面，两个参数，两种结果

事情的起因很小：我发现一个云开发平台的「工作区」页面，我打开后是空壳，同事打开后是完整 IDE。地址栏看着几乎一样，只差末尾几个字符。

这篇记录我怎么找到差异、以及从中得到的教训——「页面打开了」和「功能真的在跑」是两件事。

一、现象：同一功能，两种界面

两个链接：

A: /aidevspace?utm_source=officeagent
B: /aidevspace?dc=Tc49TgMxEAX...

打开后的差别：

两个链接的容器其实都起来了（B 也显示了剩余时长），但只有 A 真正把工作区渲染出来。

二、怎么定位到差异

我先怀疑是自己操作问题，直到想起一件事：浏览器历史记录里有答案。

Chrome 的 `History` 是个 SQLite 文件，可以直接查。这里有个坑：

# 复制出来再查，会提示 no such table: urls
cp History /tmp/h.db && sqlite3 /tmp/h.db "select * from urls"

原因是浏览器正在用这个库（持有锁 + journal），复制出来的文件缺 schema。正确做法是只读挂载原文件：

import sqlite3
c = sqlite3.connect('file:.../History?immutable=1', uri=True)
c.execute("select url, last_visit_time from urls where url like '%devstation%'")

一查就出来了——同一个域名下，utm_source=officeagent 这个地址访问了 9 次，而带 dc= 的访问次数少得多。对比一下时间，就知道哪个是「正常用」的入口。

三、为什么会有两个入口

按我的理解，这两个参数代表两条不同的流量来源：

• utm_source=officeagent：从办公/工作台入口进来，属于「主入口」，会加载完整工作区
• dc=xxx：从某个任务卡片或活动链接进来，带一次性追踪码，可能只负责把容器拉起来，不负责渲染工作区

这在小程序、SaaS 后台里很常见：同一个路由，不同渠道参数走不同的初始化分支。设计者本意可能是「活动页先起容器，进去了再加载」，但实际表现是用户看到空页面就走了。

四、更麻烦的后果：假成功

这事真正让我警觉的地方不是「界面不好看」，而是它让自动化任务产生了假成功。

我在做的是一个「每日体验工作区」的打卡任务。之前一直用 B 链接，脚本跑完日志都显示「打开成功」，容器也真的起来了（剩余时长在走）。但积分有时候到账、有时候要等一两个小时、有时候干脆没有。

当时我以为是平台判定延迟。现在明白了：

容器起来 ≠ 工作区被使用。平台采集的是「工作区内的活跃信号」，B 链接根本没加载工作区，自然没有信号。

那些「延迟到账」的记录，其实是偶尔载荷慢、工作区恰好渲染成功了。

五、教训

1. 判断成功要看「业务信号」，不要看「页面打开了」。

HTTP 200、页面有内容、进程在跑——这些都不算。要找到那个真正被记录的指标（接口返回里的状态字段、或者页面上明确的状态标签）。

2. 同一个功能有多个入口时，先确认哪个是「主入口」。

带追踪参数的链接往往是给活动、投放用的，功能可能不完整。手动用一次正常入口，对比一下，比读文档快。

3. 浏览器历史是被低估的排查工具。

遇到「我这里不行 / 别人那里行」的问题，先去历史里看看正常情况访问的是哪个完整 URL——参数、hash、路径后缀都可能藏着答案。

小结

这次的收获不是修好了什么，而是纠正了一个错误归因：

之前我一直以为平台判定不稳定（7 分钟、84 分钟、不到账都有）。实际上是我自己用错了入口，把「没加载」当成了「加载了但没记分」。

排查这类问题，顺序应该是：先确认自己走的路对不对，再怀疑对方的系统。省下的不只是一个小时，还有对平台的一堆错误印象。