Odoo 问卷直播场为什么不只是“大家一起答题”：会话码、主持端推进、排行榜与结果广播链路讲透

先说结论

Odoo Survey 的 Live Session，不是“普通问卷 + 投屏页面”这么简单。

从 /home/ubuntu/odoo-temp/addons/survey/controllers/survey_session_manage.py 和 addons/survey/models/survey_user_input.py 来看，官方实际构建的是一套轻量实时互动系统，里面至少包含：

• 用短码进入现场答题
• 由主持端控制题目推进
• 给每道题设置独立开始时间
• 按当前题实时汇总结果
• 动态渲染排行榜
• 通过总线广播下一题开始时刻

所以它真正解决的问题不是“很多人同时打开同一份问卷”，而是：

主持人如何控制节奏，而参与者如何在尽量低门槛的入口里，跟着同一题面、同一时间窗完成实时互动。

第一层：为什么 Live Session 要单独做会话码入口

控制器里有三个很关键的入口：

• /s
• /s/<session_code>
• /survey/check_session_code/<session_code>

这说明 Odoo 很清楚，现场答题的第一问题不是“问卷做得好不好”，而是参与者能不能足够快地进来。

如果现场主持人要让上百人手动输入长链接或复杂 token，互动体验几乎一定会垮掉。

因此官方做了短链思路：

• 参与者只需记住或看到一个短码
• 系统根据 session_code 找到对应问卷
• 再重定向到真正的开始地址

这和普通 Survey 的访问逻辑明显不同。

普通问卷更关心“你有没有权限进入”。 Live Session 更关心“你能不能在十几秒内顺利进场”。

第二层：为什么会话码不是找到就能进

_fetch_from_session_code() 的判断也很说明产品思路。

它会校验：

• session_code 是否存在
• 对应 survey 是否存在
• 问卷不能是 certification
• session_state 必须是 ready 或 in_progress

这几个限制都很有意义。

为什么认证问卷不能走这个入口

因为 Live Session 的目标是现场互动，而 certification 更偏正式考试与个人结果。 把两者混用，容易让认证考试失去控制边界。

为什么必须看 session_state

因为现场主持人需要掌握节奏。 如果主持端还没开场，参与者不应提前进入正式答题；如果会话已经结束，也不该继续放人进来。

所以短码入口看似简单，实际上已经在做实时活动门禁。

第三层：为什么“下一题”必须由主持端驱动

/survey/session/next_question/<survey_token> 是整套 Live Session 最核心的路线之一。

主持端触发它后，系统会：

1. 如果当前会话还在 ready，先 _session_open()
2. 找到下一题 _get_session_next_question(go_back)
3. 把 session_question_id 写到问卷上
4. 把 session_question_start_time 写成当前时间再加 1 秒
5. 通过 bus.bus 向前端广播 next_question
6. 返回下一题 HTML 和背景图 URL

这说明 Odoo 的 Live Session 不是“所有人自己点下一页”，而是：

主持端推进题目，全体参与者跟着同一题同步前进。

这和普通问卷完全不一样。

普通问卷强调个人路径。 Live Session 强调群体同步节奏。

第四层：为什么还要故意多给 1 秒

源码注释里写得非常直白：

• 为了考虑服务器延迟
• 系统会给 current_question_start_time 人为加 1 秒
• 这样对所有参与者更公平

这是一个非常“现场化”的小细节。

因为 Live Session 一旦带有：

• 单题限时
• 排行榜
• 速度评分

那么几百毫秒到 1 秒的差异，就足以影响参与者感受。

官方在这里主动加了一个缓冲时间，本质是在承认：

• 网络并不完美
• 前端渲染并不同步
• 实时系统里“绝对同时”很难做到

所以与其假装没有延迟，不如显式给全场一个统一缓冲。

这种设计非常成熟。

第五层：结果页为什么只看当前题、当前会话窗口

survey_session_results() 不是去统计整份问卷结果，而是只抓：

• 当前问卷
• 当前题 session_question_id
• 且 create_date >= session_start_time

也就是说，它看的不是“历史上一共有多少人这样答过”，而是：

这场正在进行的 Live Session 中，当前这道题此刻被答成了什么样。

这点特别重要。

因为现场互动最怕的，就是把历史数据和本场数据混在一起。

如果不按 session_start_time 截断：

• 之前测试题留下的数据会污染结果
• 上一场活动的答案会残留
• 主持人看到的投票比例会失真

所以 Odoo 把“本场会话窗口”当成统计边界，而不是单纯拿题目本身做聚合。

第六层：排行榜为什么单独做成一条路由

/survey/session/leaderboard/<survey_token> 单独返回排行榜片段，而不是塞进统一大页面里。

这意味着排行榜不是附属品，而是 Live Session 的核心展示模式之一。

从业务上看也说得通。

现场互动里，主持人常常会在三种大屏态之间切换：

• 当前题
• 当前题结果
• 当前排行榜

Odoo 把排行榜单独做成一个可异步调用的端点，就是为了让这三种状态切换更轻。

而且排行榜调用的不是静态表，而是 survey._prepare_leaderboard_values()，说明：

• 排名不是一个页面样式问题
• 而是问卷会话本身的业务输出

第七层：为什么 survey.user_input 还要感知“这是会话答题”

survey.user_input 里有两个字段很关键：

• is_session_answer
• question_time_limit_reached

它们表明：

• Live Session 并不是一个纯控制器层概念
• 答题记录本身也知道自己是不是现场会话的一部分

这非常重要，因为如果底层记录不知道自己属于 session，就无法正确区分：

• 普通问卷的总时长限制
• Live Session 的单题限时
• 排行榜相关的速度语义

换句话说，Live Session 不是“前台看起来像实时互动”，而是数据层也真的按实时互动在建模。

最容易误解的四个点

误区一：Live Session 就是问卷大屏模式

不对。它有自己的入口、状态边界、主持端动作和统计窗口。

误区二：会话码只是短链接优化

也不止。它还是一层现场门禁，负责判断当前会话是否允许进入。

误区三：下一题只是前端翻页

不是。真正决定下一题的是主持端写入 session_question_id 并广播开始时间。

误区四：排行榜只是好看

其实排行榜是 Live Session 产品语义的一部分，它影响参与感、节奏和主持方式。

实战上怎么把 Live Session 跑顺

如果你要把 Odoo Survey 用在培训、课堂或活动现场，我建议重点盯住下面几件事：

1. 会前先测试短码入口，别让参与者一上来就卡在进场
2. 主持端不要把 Live Session 当普通问卷去操作，而要按“控场面板”来理解
3. 如果启用限时或速度评分，要特别关注网络环境和投屏延迟
4. 每场活动开始前确认 session 是新的，不要混进旧数据
5. 结果页与排行榜页的切换节奏，最好先和彩排脚本一起演练

最后总结

Odoo Survey 的 Live Session，真正厉害的地方不是“大家能一起答题”，而是它把现场互动里最关键的三件事都收了进去：

• 低门槛进场
• 主持端控节奏
• 结果与排行榜实时反馈

所以它不是一张问卷换了个皮，而是一套轻量但完整的实时互动 orchestration。

也正因为如此，看懂它最好的方式不是研究题目长什么样，而是理解：

谁在控制当前题、谁在定义时间窗、谁在决定此刻屏幕上该显示什么。