Streamlit应用的核心是脚本重执行机制，每次用户操作都会从头运行整个脚本，因此需避免全局变量、将UI与逻辑平铺在顶层、用@st.cache_data缓存耗时操作，并正确使用st.number_input等四大常用控件。
Streamlit 不需要你写前端代码，也不需要 Flask 那类路由配置——只要把数据分析逻辑用 Python 写清楚，再用 st.* 函数把输入、输出和交互“挂”上去，应用就跑起来了。
怎么让脚本变成可交互的 Web 页面
Streamlit 的核心机制是「每次用户操作（比如拖动滑块、选下拉项）都会从头重跑整个脚本」。这意味着你不能依赖全局变量存状态，也不能靠 if __name__ == '__main__' 控制执行流程——所有 UI 和逻辑必须平铺在顶层作用域里。
- 所有
st.text_input()、st.slider()等控件返回的是当前值，不是“绑定对象”，直接赋给变量即可使用 - 不要在函数内部调用
st.*（除非用@st.cache_resource或@st.fragment显式标记）；否则可能触发未定义行为或重复渲染 - 如果数据加载慢（如读 CSV、查数据库），务必用
@st.cache_data包裹，否则每次交互都重新加载
哪些控件最常用、参数怎么设才不翻车
真实项目里，90% 的交互需求靠四个控件就能覆盖：数值输入、单选、文件上传、布尔开关。它们的默认行为和常见陷阱比文档写得更实际：
-
st.number_input("阈值", min_value=0.0, max_value=1.0, value=0.5, step=0.01)：不设step时，浏览器里可能只允许整数输入，哪怕value是浮点 -
st.selectbox("模型", ["XGBoost", "LightGBM"], index=0)：必须显式传index，否则首次加载会报IndexError（空列表时尤其危险） -
st.file_uploader("上传CSV", type=["csv"])：返回None表示没上传，不是空文件对象；后续用pd.read_csv(uploaded_file)前要先判空 -
st.checkbox("显示原始数据")：返回布尔值，但别直接塞进st.dataframe(df)里——应该用if show_raw:控制是否渲染
图表和表格怎么嵌进去才不卡、不崩
Streamlit 对 Pandas 和 Plotly 支持最好，但默认渲染方式会影响体验：
立即学习“Python免费学习笔记（深入）”；
-
st.dataframe(df)是交互式表格（可排序、缩放列宽），适合中等规模数据（st.table(df.head(100)) 静态渲染，避免前端卡死 - 用 Plotly 画图优先选
st.plotly_chart(fig, use_container_width=True)，它自动适配响应式宽度；Matplotlib 图要用st.pyplot(fig)，且记得在绘图后调plt.close(fig)防内存泄漏 - 别在循环里反复调
st.line_chart()——每个调用都生成一个新图表组件，页面会越来越卡；应提前聚合好数据，一次画完
本地跑通后，部署前必须检查的三件事
很多人本地能跑，一上 Streamlit Cloud 就白屏或报错，问题往往出在环境假设上：
- 确认所有第三方库都在
requirements.txt里，且版本明确（比如pandas==2.2.2，别写pandas>=2.0） - 读取本地文件（如
pd.read_csv("data.csv")）在云端根本找不到路径——必须改用st.file_uploader或从 URL 加载（如pd.read_csv("https://example.com/data.csv")） - 自定义 CSS 或 JS 注入（用
st.markdown(..., unsafe_allow_html=True)）在免费版 Streamlit Cloud 上被禁用，会静默失效
真正麻烦的不是写第一行 st.title()，而是理解「脚本重执行」这个底层逻辑——所有状态都要显式管理，所有耗时操作都要缓存，所有外部依赖都要可复现。漏掉其中任意一点，应用看起来能跑，但交互一多就不可控。
