Python 数据工具：从探索到交付，Jupyter 分析、Streamlit 展示

数据工作流通常分两段：先用交互式 notebook 把数据摸清、把特征试出来，再把结论做成能给别人点的页面。这两段用的工具不同——Jupyter 是分析与试验的默认工作台，Streamlit 是把脚本直接变成交互页面的利器。它们不是替代关系，而是"探索 → 交付"的接力。本文把两篇笔记合在一起，讲清各自适合在哪一段、各自的坑在哪。

一、Jupyter：探索数据、试验特征的默认工作台

Jupyter 把代码、输出和文字说明写在同一个 notebook 里，是数据分析和模型试验的默认工作台。它的本质是前后端分离：浏览器里的单元格发到 kernel，kernel 保持进程内的变量状态。因此上下单元格的执行顺序会影响结果，重启 kernel 与重跑全部单元格是两件事。生产化时不要直接把 notebook 当服务；应该把稳定逻辑抽成 .py 或脚本。JupyterLab 把终端、文件树和多 notebook 合在一起，更适合长期项目。

三个容易踩的坑

• 环境与依赖没锁死：用 conda 或 venv 为每个项目独立 kernel，避免全局包冲突；依赖写进 requirements 或 environment.yml。
• 单元格靠"手动先跑上面那格"：结果不可复现。关键结果要落盘或写入文件，便于 git 对比，不要依赖执行顺序。
• notebook 里塞密钥、生产库地址、大图或模型权重：.ipynb 会吸得很胀，提交前清空或用 nbstripout；密钥绝不能进仓库。

什么时候用：探索数据、试验特征、写教学演示时用 Jupyter 最顺手。定时训练、API 服务和团队协作的稳定管线，应迁出 notebook。多人共享时可用 JupyterHub，但要配资源限制与身份认证，不要把开放 kernel 直接挂公网。

二、Streamlit：把分析脚本快速变成可交互页面

Streamlit 用 Python 脚本直接画出交互页面，适合把数据分析、模型演示和 RAG 试玩结果快速普及给业务。它的执行模型是"整个脚本从上到下重跑"，widget 一变，代码重跑。因此要把耗时的加载用 @st.cache_data 或 @st.cache_resource 住起来。session_state 用来记对话历史与上传文件。它不适合做需要精细路由与权限的正式前端，但做内部 Demo 和标定工具极快。

三个容易踩的坑

• 客户端没进缓存：把源连接、向量库客户端和模型客户端进 cache_resource，把数据框进 cache_data。否则每次点击都会重连 Redis 或重载模型。
• 对话历史拼进全局变量：用 st.chat_message 加 session_state 存历史；多用户同进程时要注意隔离。
• 密钥写进仓库、并发不隔离：部署时用 secrets.toml 管密钥；并发采访要加锁或改用 FastAPI。

什么时候用：数据科学家向业务展示图表、验证 RAG 分块效果、做内部标注小工具时，Streamlit 能把周期压到几小时。面向外部用户的高并发产品、需要精细 SEO 或移动端交互的，不要选它。一旦 Demo 被确认，就把业务逻辑抽成服务，页面只留一层薄包装。

附：从探索到交付的分工表