一次课堂临时接手的 Streamlit 问卷平台网络卡顿排查记录

问题背景

这次问题发生在一节概率论课堂上的临时活动中。主理人和我之前并不认识，我也没有提前参与这个项目，对项目背景、代码结构、部署方式和运行环境都不了解。

当时课堂活动已经开始，同学们需要现场访问一个在线问卷/实验平台完成任务，但平台加载很慢，无法支撑两个班同时使用。我是在这种情况下临时接手，尝试帮忙排查和寻找应急方案。

角色概览：

• 我：笔者，课堂现场临时接手排查问题
• 主理人：项目开发者，我之前并不认识
• 老师：授课老师，概率论课程
• 同学们：一个班约 30 人，一共两个班，总人数应该不超过 60 人，在线人数不少于 50 人

项目情况：

• 一个在线调查问卷/实验平台，里面还有概率论相关问题需要填写，整体耗时较长。
• 项目运行在主理人的笔记本电脑上。
• 学生通过校园网局域网访问。
• 我在接手前没有看过项目，也不了解它的启动方式、数据保存方式和具体技术实现。

问题现象：

19:40 左右，同学们使用校园网访问项目时，发现页面很卡，资源加载很慢，无法支撑两个班同时使用。

现场压力：

• 这是课堂现场临时出现的问题，时间非常紧。
• 解决网络并发或部署问题本身需要时间，无法保证短时间内立刻找到方案。
• 主理人和老师应该都不是计算机专业，短时间内难以快速定位问题。
• 我不了解项目，难以马上判断根因，也不能保证短时间内一定能解决。
• 如果排查时间过长，可能会影响课堂活动继续进行。

当时问题排查的过程

1. 询问项目情况

主理人说明：

• 项目是 Python 开发的。
• 使用 VS Code 开发。
• 使用网页端 DeepSeek 辅助开发。
• 项目跑在她的笔记本中，通过校园网局域网提供访问。
• 测试时 10 人左右访问正常。

我当时的第一反应：

听到项目是用网页端 DeepSeek 开发的，我当时有些惊讶。看到她电脑上似乎有 Claude Code，我的第一反应是：如果她会用，或者可以直接在她电脑上操作，也许可以在本地最快处理。

随后我又想到另一个方案：让她把项目打包发给我，我在自己的电脑上用 Claude Code 排查。但这个方案马上暴露出几个问题：

• 源代码和配置可能涉及隐私或敏感信息。
• 项目依赖虽然看起来不算特别重，但运行环境不一定能在我电脑上快速复现。
• 这是课堂现场，重新迁移项目本身就有时间风险。

当主理人描述为“校园网访问很慢”时，我的第一直觉是：把项目部署到我的阿里云服务器上，通过公网访问，绕过教室局域网。我最近刚用云服务器部署过一个项目，所以直觉上觉得“云服务器可能能解决个人笔记本带不动、校园网访问慢”的问题。

但我当时也很清楚，这个方案并不稳妥：

• 我有云服务器部署经验，但还不够熟练。
• 云服务器上没有提前配置好 Claude Code，现场操作不方便。
• 时间太短，无法保证能完整部署、开放端口、测试访问。
• 我不能保证这个问题一定是“换到公网/云服务器”就能解决。

所以我本来并不想接手这个问题，因为不确定因素很多。但最终还是硬着头皮上了：一方面是课堂现场确实需要解决，另一方面这也是一次真实的线上问题应急场景。原本这节课我还打算准备第二天学校线下招聘相关的内容，结果临时变成了一次非常真实的“线上事故排查训练”。

2. 简单了解项目

项目依赖：

streamlit>=1.35.0
openai>=1.30.0
pandas>=2.0.0
openpyxl>=3.1.0
qrcode>=7.4.0

我的初步判断：

• 项目使用了 openai 包，实际调用的应该是 DeepSeek API。
• 项目中存在硬编码 API Key 的情况，这涉及敏感信息和隐私风险。
• streamlit 这个依赖我之前没用过，对它的并发模型和资源消耗不了解，当时确实有点慌。
• 其他依赖看起来不算重，没有 PyTorch 这类大型依赖。

当时我没有完全冷静下来。正常的排查流程应该是先定位问题，再选择方案；但我因为现场压力，直接开始想“怎么快速解决”，问题分析还不够充分。

我让主理人把她和 DeepSeek 的对话记录发给我，想先快速了解项目情况。但记录不完整，很多细节我后来也记不清了。

当时的疑问和判断：

• 项目 10 人测试时是正常的，所以我一开始不理解为什么 60 人就会明显卡顿。我当时的理解是：网页请求建立连接、获取资源、提交数据之后，连接应该不会一直占用太多资源。
• 我当时对校园网局域网提供服务的机制也不熟悉：为什么连接同一个校园网后，就能直接通过端口访问别人电脑上的服务？是否需要学校网络开放端口？会不会有防火墙或网络策略限制？这些我都不能确定。
• 这让我想到之前见过的类似情况：我有同学通过校园网打通 22 端口，在校园网内远程 SSH 连接寝室设备；我也用过 Tailscale 搭建虚拟局域网。但这些都只是经验片段，并不等于我真正理解了校园网内提供服务的机制。
• 当时正好临近期末，我这学期计算机网络课程还没有系统学完，对网络的认识更多来自零散实践，所以很多判断都只能算直觉判断。
• 我想到过公网部署，但不敢在现场直接上云服务器，因为流程不熟、时间不够、风险较大。
• 我也想到过热点，但当时觉得校园网都卡，热点大概率也不稳。

于是，我优先在主理人的电脑上，通过网页端 DeepSeek 寻找快速方案。对话记录：DeepSeek - 探索未至之境。

我的提问：

...(主理人分享的对话链接只显示了这么多)

但是，我经过测试，我的朋友能够在校园网的局域网下访问啊，只有10个人左右，能够访问，但是现在到教师课堂之后，有大概60+的人数，有人能够访问到，但是很卡。这是什么情况？

快速地解决方法，能立马10min之内解决的方案

AI 给出的方案是：使用 ngrok 快速穿透。

于是我就按这个方向尝试。

3. 尝试解决问题

我让 Claude Code 帮忙处理，大致输入如下：

了解当前的项目。我需要在10min中内，部署项目，提供服务，线下使用。可以热点或局域网

这是我的对话记录，当前遇到的问题：
[此处插入了从网页端的复制的对话记录]

ngrok 的授权码是: "3EqySPXq------Cad41SS11riwy"
ngrok 下载的程序是： "C:\Users\senio\Desktop\ngrok.exe"

目前不要中断服务！
我能通过docker打包了之后，上传到阿里云服务器部署吗？

最终确实获得了一个 ngrok 可访问链接，公网访问也能打开。但它并没有真正解决现场加载慢的问题。还没等我进一步部署或验证，主理人已经和老师商量好继续采用本地运行的方式完成课堂任务。

事后看，现场问题可能不只是“公网/内网访问方式”的问题，也可能和电脑状态有关。例如中途把笔记本盖子盖上，可能导致电脑休眠或网络连接中断。但这只是可能因素之一，我不能确定它就是当时问题的根因。这个问题理论上可以通过电源设置规避：将“合上盖子”设置为“不采取任何操作”，避免服务在后台中断。

（主理人聪明啊！最终还是本地跑的，完成了最终的任务！拯救了事故！而我，没有在紧急情况下真正理解问题原因，找到问题的根本所在！）

解决过程中的思考：

• 程序本身能跑，校园网局域网访问也是可行的，至少说明服务端口在当时网络环境下可以被访问。
• 通过 AI 对话我了解到，是否能通过校园网端口提供服务，还可能受到防火墙、网络策略等影响。
• 我当时仍然不理解：局域网理论上应该很快，为什么 60 人访问会这么慢？
• 后来我才意识到，可能不只是“带宽够不够”的问题，还可能涉及 Streamlit 的长连接、无线 AP 并发、客户端数量、上传文件、AI 交互等多个因素叠加。但这些是事后推测，不能直接当成确定结论。

我没有直接改源代码。原因是：

• 项目能跑，课堂现场最怕改坏。
• 我不了解业务逻辑和数据保存方式。
• 让 AI 临时修改陌生项目风险太高。
• 如果改出新问题，现场可能没有足够时间回滚。

4. 事后进一步思考

这次之后，我意识到需要补充了解 streamlit。

我最开始以为主理人可能只是为了图方便，选择了一个“最简单”的技术栈。后来发现事情可能没这么简单：这个平台不仅是问卷，还包含 AI 对话。结合我之前使用 Spring AI 开发 AI 应用的经验，AI 对话需要管理上下文和会话状态。对非计算机专业开发者来说，Streamlit 可能确实是一个能快速实现功能的选择。

我的事后推测：

• 项目需要为每个学生维护 AI 对话上下文。
• 如果不使用数据库，可能会直接用运行时内存管理会话数据。
• Streamlit 默认通过 WebSocket 保持交互状态，因此多个学生同时使用时，连接和内存压力可能会增加。
• 这些只是我基于后来资料和个人经验的推测，不能直接当作本次问题的唯一原因。

这也是我之前没有想到的：一个问卷平台中，既有选择题、在线作答、拍照上传，还有 AI 对话功能。这个功能组合比普通问卷复杂得多。

不过，我更关注的不是技术栈本身“对不对”，而是这次排查问题、理解问题、处理现场的过程。

我：

streamlit这个依赖提供在线服务的时候，很占资源吗？是长连接吗？

---

DEEPSEEK：

Streamlit 属于长连接，但并发时的资源消耗确实比较高，对部署环境有一定要求。

简单说，它默认会为每个用户维护一个持久的 WebSocket 连接来实现实时交互，这个设计本身是为了丝滑体验。但同时，为了简化开发，它在资源使用上做了些取舍，导致它对资源（尤其是内存）的胃口比较大。

🔗 双向实时通信，属于长连接

Streamlit 采用长连接，具体是 WebSocket + Protocol Buffers 的架构：

• 持久双向连接：与传统的 HTTP "一问一答"不同，Streamlit 在浏览器和服务器之间建立了一个持久的 WebSocket 通道，可以双向实时通信。
• 性能优势：它能保持会话状态，实现流畅的前后端交互，并且比每次新建 HTTP 连接效率更高。
• 部署关键：因为是长连接，如果使用 Nginx 这类反向代理，必须确保其空闲超时时间设置得足够长。否则，代理服务器可能会提前切断连接，导致页面频繁重刷。

💾 资源消耗情况：内存占用高，并发是挑战

…

---

我：

什么情况下才会用这种技术栈？适用于临时的学生调查问卷吗？一个问卷持续大概30min，有60个人，局域网

---

DEEPSEEK：

对于你的具体需求——60人、30分钟的局域网问卷——结论很明确：技术上完全可行，但也是 Streamlit 的“压力测试”。

你可以把它想象成一种“高效但费油的跑车”。它能让你在几分钟内就搭建出一个网页，但也需要你对它“吃资源”的特性有所准备，不然很容易在半路抛锚。

⚙️ Streamlit 的「高光时刻」：何时它是绝佳之选？

Streamlit 最擅长的是下面这几类事情，你的问卷场景恰好符合前两点：

• 内部数据工具：为数据分析师或团队成员快速搭建临时的数据看板、实验记录系统，这正是它的设计初衷。
• 原型与内部演示：快速地制作一个最小可行性产品（MVP）给客户或团队看，验证想法。
• 机器学习演示：为你的模型快速搭建一个能交互的Demo，让别人能体验算法效果。
• 学术与科研项目：像有专门的 streamlit-survey 库一样，可以很方便地构建在线问卷并自动收集数据。

📋 你的场景可行性分析：60人局域网问卷

以你提供的信息为基础，我们可以把挑战拆解成两部分来看：

1. 性能潜力 (Performance Potential)：你的局域网内网环境，网络延迟和带宽通常都很理想，这是 Streamlit 赖以生存的土壤。如果能将模型和数据缓存在高性能的服务器上（例如有 8GB 内存和 4 vCPU 的配置），那么应对 60 人的并发是完全有可能的。
2. 并发瓶颈 (Concurrency Bottleneck)：这是真正需要面对的挑战。

…

---

我：

性能上，有必要用这个技术栈吗？我要避免性能的问题发生。我用的是校园网。

---

DEEPSEEK：

综合你60人并发、30分钟问卷、校园网这一系列明确的需求来看，如果用Streamlit做服务器，对你的校园网服务器而言，性能上的压力会比较大。我建议你优先考虑技术门槛低、资源占用小的替代方案，这样能更稳妥地保证项目成功。

以下是核心方案的精要总结和对比，希望能帮你更直观地做决定。

💡 三个方案快速对比

对比维度	🏆 稳妥之选：PyWebIO	⚡️ 高效之选：Flask/FastAPI	🚀 挑战之路：Streamlit + Nginx
一句话点评	开箱即用，省心首选。完全为快速搞定简单网页而生。	性能怪兽，灵活高效。理论基础扎实，适合有编程基础的人。	大力出奇迹，但更折腾。实现你的需求需要不少额外的工程工作。
技术门槛	极低。纯Python代码，专注逻辑，无需处理HTML/JS。	中等。需要理解基础的HTML/HTTP概念和框架流程。	高。除了应用，还需掌握Nginx配置、进程管理等运维知识。
资源占用 & 并发能力	极低。测试显示，类似Flask等轻量级框架可稳定承载200人/分钟的并发访问。	低。Async异步框架，性能优秀。一个简单的应用，在2核2G服务器上运行完全足够。	高。单实例性能有限，为应对60人，需要部署多实例+负载均衡，资源消耗线性增长。
部署复杂度	极简。pip install后直接运行脚本。	简单。官方文档丰富，有现成的部署教程。	复杂。需要自己搭建和管理Nginx及多个应用实例，调试WebSocket timeout等。

…

反思总结

1. 【问题边界】能访问 ≠ 能稳定使用

• 关键词：可访问、可承载、真实场景
• 我对“10 人测试能访问”和“50-60 人课堂现场稳定使用”之间的差异认识不够清楚。
• 当时我更关注“项目能不能打开”，但课堂真正需要的是“多人同时使用时能不能持续稳定”。
• 这个项目不只是普通问卷，还可能涉及 AI 对话、会话状态、图片上传、长连接等因素，因此不能简单按普通网页访问来估计压力。
• 这次暴露出我对“功能能跑”和“上线能稳”的区别理解还不够深。

2. 【排查顺序】过早寻找方案，没有先拆解问题

• 关键词：先定位、再处理、逐项验证
• 我当时第一反应是找快速方案，比如云服务器、ngrok、公网访问、热点。
• 这些方向不能说完全错，但问题在于，我还没有先拆清楚根因可能在哪里。
• 当时至少应该先区分：
  • 服务是否还在正常运行？
  • 电脑是否休眠、断网或关盖影响服务？
  • 校园网、防火墙或端口访问是否有限制？
  • 无线 AP 是否承载不了这么多设备？
  • Streamlit 的交互方式是否导致连接或资源占用较高？
  • AI 请求、图片上传、同时刷新是否造成了额外压力？
• 我当时更多是在“寻找一个看起来能解决的方案”，而不是“先列假设，再逐项验证”。
• 这说明我的现场排查框架还不够成熟。

3. 【能力边界】不能保证的事情，要明确标注风险

• 关键词：不确定、不能保证、风险边界
• 我当时想到把项目部署到云服务器，但其实我不能保证 10 分钟内完成环境配置、代码迁移、端口开放、数据保存和访问测试。
• 我尝试 ngrok，也只能说明它可能提供一个公网入口，不能保证它一定能解决现场加载慢的问题。
• 我对 Streamlit、WebSocket、校园网局域网访问机制都不够熟，所以不能把自己的推测直接当作结论。
• 这次让我意识到：临时救火时，重要的不只是能想到方案，还要清楚哪些方案自己能保证，哪些方案只是可以尝试。
• 对自己不能保证的部分，必须在判断和表达中保持谨慎。

4. 【临时接手】陌生项目的难点不只是技术

• 关键词：陌生项目、临时接手、沟通确认
• 这不是我提前参与的项目，主理人和我之前也不认识，我没有提前了解代码、环境、数据保存方式和业务流程。
• 在这种情况下，直接改代码、迁移部署、切换方案都有较高风险。
• 临时接手陌生项目时，应该先快速问清楚：
  • 项目怎么启动？
  • 数据保存在哪里？
  • 当前服务是否还在运行？
  • 哪些文件、配置、数据不能动？
  • 是否有备用方案？
  • 如果失败，能否快速回到原来的运行方式？
• 这次暴露出我在“陌生人员 + 陌生项目 + 课堂现场”这种情况下，沟通确认和风险控制能力还不够成熟。

5. 【技术认知】我对网络和部署链路理解不够系统

• 关键词：局域网、AP 并发、WebSocket、部署链路
• 我当时对“局域网为什么还会卡”理解不够，直觉上觉得局域网应该比公网快很多。
• 但真实场景里，问题可能不只是带宽，还可能包括：
  • 教室无线 AP 的并发承载能力；
  • 多台手机同时连接造成的竞争、排队、重传；
  • Streamlit 可能存在的长连接或会话状态维护；
  • AI 请求和图片上传带来的额外压力；
  • 笔记本休眠、关盖、电源策略等设备因素。
• 这些因素我当时没有系统纳入判断，更多是事后通过 AI 对话和回忆逐渐意识到。
• 这说明我需要补的不只是某个工具的使用，而是完整理解“网络—应用—部署—设备”这一整条链路。

6. 【应急原则】现场优先止损，而不是追求最优方案

• 关键词：先保服务、降低风险、现场可控
• 课堂现场最重要的是让活动尽量继续，而不是立刻找到技术上最完美的方案。
• 当项目还能本地运行时，贸然改代码或强行迁移到新环境，可能反而制造新的问题。
• 更稳妥的顺序应该是：
  1. 先确认服务是否还活着；
  2. 再确认电脑是否休眠、断网、关盖；
  3. 确认当前访问入口是否可用；
  4. 尽量减少同时进入、频繁刷新、图片上传等高峰操作；
  5. 最后再考虑 ngrok、云服务器、Docker 等备用方案。
• 这次让我意识到，应急处理的目标不是“方案最先进”，而是“现场风险最低、活动能继续”。

7. 【后续改进】以后要提前准备检查清单

• 关键词：检查清单、真实压测、备用方案
• 如果以后再参与类似课堂平台、在线问卷或实验系统，不能只验证“功能能跑”。
• 至少要提前确认：
  • 是否按真实人数测试过？
  • 是否在真实网络环境下测试过？
  • 数据是否能正常保存？
  • 电脑是否会休眠或关盖断网？
  • 是否有公网备用入口？
  • 是否有 Docker 镜像或云服务器备用部署方案？
  • 如果系统临时不可用，是否有纸质问卷、分批完成或其他替代流程？
• 这些准备看起来琐碎，但真正上线时，决定系统能不能稳住的往往就是这些细节。

8. 总结

• 关键词：能跑不等于能稳，能想到不等于能落地
• 这次经历不是一次完整可控的项目部署，而是一次课堂现场临时接手陌生项目的应急排查。
• 我最大的收获是认识到：真实问题往往不是单点技术问题，而是技术、网络、设备、时间、人员沟通共同作用的结果。
• 我目前欠缺的不只是某个具体工具的使用，而是现场判断、风险控制、问题拆解和部署验证的系统能力。
• 以后再遇到类似问题，我要先明确边界、快速拆解、降低风险、保住现场，再考虑进一步优化。