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

Python大屏展示怎么做_Dash与Streamlit框架快速构建Web版数据看板

Streamlit 适合快速原型,但别在生产环境直接用 streamlit run

它启动的是开发服务器,默认不带鉴权、无并发控制、静态资源不压缩,上线后容易被刷崩或暴露源码。streamlit.config.toml 里设 server.portserver.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。

Dash 的 Callback 必须显式声明输入输出,漏一个就白屏

Dash 不像 Streamlit 那样靠执行顺序隐式构建 UI,所有响应逻辑都靠 @app.callback 绑定。漏写 Output 或输错组件 id,页面不会报错,而是整个 layout 渲染失败,只留空白页——连浏览器控制台都可能没报错信息。

使用场景:多筛选器联动、图表下钻、实时数据轮询。这时候 dash.dependencies.Inputdash.dependencies.State 的区别很关键:State 不触发回调,只取值;Input 变了才跑函数。混用会导致“点了按钮没反应”或“改个下拉框整个图重绘”。

大屏适配不是加个 width="100%" 就完事

Dashboard 在 4K 屏上文字小、按钮挤、图表变形,根本原因是默认用 px 单位 + 固定宽高。Dash 的 dbc.Container 或 Streamlit 的 st.columns 都不自动响应屏幕物理尺寸,得手动干预 CSS。

性能影响明显:用 vw/vh 单位做字体和容器大小,比 JS 动态计算快得多;但 Chrome 对 vh 在移动端有兼容问题(地址栏收放导致高度跳变),得加一层 min-height: 100dvh 兜底。

实时数据更新别用 time.sleepwhile True

Streamlit 的脚本每次交互都会整页重跑,time.sleep(5) 会卡死整个会话;Dash 的 callback 是单次执行,想轮询得靠前端 Interval 组件或后端 WebSocket,硬塞循环只会让进程僵死。

容易踩的坑:用 st.autorefresh(已废弃)或自己写 st.empty().text("loading..."); time.sleep(2),结果用户点别的按钮时还在等那个 sleep。

复杂点在于:大屏往往要同时支持手动刷新、定时刷新、事件触发刷新三种模式,而这三者的状态同步很容易漏掉——比如用户刚点完“导出 CSV”,后台还在跑,定时器又到了,结果两个请求打架。这类边界得靠 st.session_state.running_task 或 Dash 的 clientside_callback 锁住按钮状态,不然运维半夜接到告警电话就是这个原因。

本文转载于:互联网 如有侵犯,请联系zhengruancom@outlook.com删除。
免责声明:正软商城发布此文仅为传递信息,不代表正软商城认同其观点或证实其描述。