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 变了才跑函数。混用会导致“点了按钮没反应”或“改个下拉框整个图重绘”。
立即学习“Python免费学习笔记（深入）”；
-
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 锁住按钮状态，不然运维半夜接到告警电话就是这个原因。
