Streamlit 适合快速原型但不可直接用于生产,需通过 nginx+gunicorn 部署并禁用开发模式;Dash 依赖显式 callback,需严格匹配 Input/Output 和 id;二者均需响应式 CSS 和合理轮询机制。

Streamlit 适合快速原型,但别在生产环境直接用 streamlit run
它启动的是开发服务器,默认不带鉴权、无并发控制、静态资源不压缩,上线后容易被刷崩或暴露源码。streamlit.config.toml 里设 server.port 和 server.address 只是改监听地址,不解决本质问题。真实部署得套 nginx 做反向代理,用 gunicorn 启动多个 worker(注意 Streamlit 官方不推荐 gunicorn,但社区普遍用 streamlit run --server.port=8501 --server.address=127.0.0.1 配合 gunicorn -w 2 -b 127.0.0.1:8000 --forwarded-allow-ips="*" streamlit_app:app 这类变通方式)。
常见错误现象:ConnectionRefusedError、页面加载一半卡住、刷新后状态丢失——基本都是没关掉开发模式的热重载或没隔离 session。
- 开发阶段用
streamlit run app.py没问题,但上线前必须删掉所有st.experimental_memo和st.cache_data的experimental_前缀(新版本已稳定) - 用户上传文件时,
st.file_uploader返回的对象不能直接传给 pandas;得先用.read()或转成BytesIO,否则报AttributeError: 'UploadedFile' object has no attribute 'read' - 图表交互卡顿?别在
st.button回调里反复调st.plotly_chart;把 figure 构建和渲染拆开,用st.empty()占位再.plotly_chart(fig)替换
Dash 的 Callback 必须显式声明输入输出,漏一个就白屏
Dash 不像 Streamlit 那样靠执行顺序隐式构建 UI,所有响应逻辑都靠 @app.callback 绑定。漏写 Output 或输错组件 id,页面不会报错,而是整个 layout 渲染失败,只留空白页——连浏览器控制台都可能没报错信息。
使用场景:多筛选器联动、图表下钻、实时数据轮询。这时候 dash.dependencies.Input 和 dash.dependencies.State 的区别很关键:State 不触发回调,只取值;Input 变了才跑函数。混用会导致“点了按钮没反应”或“改个下拉框整个图重绘”。
id必须全局唯一,且只能是字符串;别用变量拼接,比如f"chart-{i}"在循环里生成,容易引发 callback 匹配失败- 返回值类型必须和
Output声明的 component property 一致:比如Output("my-graph", "figure")就必须 return 一个 dict,不是plotly.graph_objects.Figure实例(得先调.to_dict()) - 别在 callback 函数里写 print;日志会被吞掉,调试用
dash.no_update+ 浏览器 Network 面板看请求 payload 更靠谱
大屏适配不是加个 width="100%" 就完事
Dashboard 在 4K 屏上文字小、按钮挤、图表变形,根本原因是默认用 px 单位 + 固定宽高。Dash 的 dbc.Container 或 Streamlit 的 st.columns 都不自动响应屏幕物理尺寸,得手动干预 CSS。
性能影响明显:用 vw/vh 单位做字体和容器大小,比 JS 动态计算快得多;但 Chrome 对 vh 在移动端有兼容问题(地址栏收放导致高度跳变),得加一层 min-height: 100dvh 兜底。
- Streamlit 中全局生效:在
.streamlit/config.toml加browser.gatherUsageStats = false减少上报,再用st.markdown注入自定义 style,比如html{font-size: calc(16px + 0.2vw);} - Dash 中推荐用
dash_bootstrap_components的dbc.Row+dbc.Col,设md=12而非xs=12,避免小屏强行撑满 - 图表库本身要设响应式:
plotly.express图必须加width=None, height=None,否则固定像素;altair要用.properties(width="container", height="container")
实时数据更新别用 time.sleep 或 while True
Streamlit 的脚本每次交互都会整页重跑,time.sleep(5) 会卡死整个会话;Dash 的 callback 是单次执行,想轮询得靠前端 Interval 组件或后端 WebSocket,硬塞循环只会让进程僵死。
容易踩的坑:用 st.autorefresh(已废弃)或自己写 st.empty().text("loading..."); time.sleep(2),结果用户点别的按钮时还在等那个 sleep。
- Streamlit 正确做法:用
st.fragment+st.rerun控制局部刷新,配合st.session_state记上次更新时间,避免高频请求 - Dash 正确做法:加一个
dcc.Interval(id="interval", interval=5000, n_intervals=0),然后在 callback 里监听Input("interval", "n_intervals"),返回新数据即可 - 如果后端是 FastAPI/Flask,更稳的方式是让前端用
fetch轮询 API,而不是靠框架内置机制——可控性高,也方便加 token 刷新和错误退避
复杂点在于:大屏往往要同时支持手动刷新、定时刷新、事件触发刷新三种模式,而这三者的状态同步很容易漏掉——比如用户刚点完“导出 CSV”,后台还在跑,定时器又到了,结果两个请求打架。这类边界得靠 st.session_state.running_task 或 Dash 的 clientside_callback 锁住按钮状态,不然运维半夜接到告警电话就是这个原因。