Streamlit 是一个开源的 Python 应用框架,专为数据科学与机器学习场景设计,让开发者仅用纯 Python 脚本即可将数据模型、算法结果和 LLM 对话快速转化为可交互的 Web 应用。它解决了传统 Web 开发中「前端逻辑与后端服务分离」带来的高成本问题:数据科学家不需要掌握 HTML、CSS 或 JavaScript,只要按脚本方式书写 Python 代码,Streamlit 会自动完成页面渲染、组件布局与事件响应——任何对代码的修改都会通过「热重载」机制即时反映到浏览器中。自 2022 年被 Snowflake 收购后,Streamlit 的定位从「演示工具」逐步扩展为涵盖缓存、会话状态、多页面架构与云端部署的完整数据应用方案。本篇攻略覆盖从安装配置、核心 API 实操、生产部署到选型对比的完整链路,并基于官方文档整理常见坑点与面试考察点,读者可对照步骤直接上手。
掌握 Streamlit 意味着你可以在 30 分钟内把训练好的模型交付成可交互的 Demo 或内部工具——这是数据岗位与 AI 工程岗位面试中高频考察的一项实操技能。
目录
速览卡是工具类内容的固定首屏模块:30 秒判断「这工具是什么、能不能商用、适不适合我」。
为什么需要 Streamlit:从模型到可交互应用的最短路径
传统数据应用交付路径包含三层工作:后端 API 开发(FastAPI/Flask)、前端页面编写(React/Vue)、前后端联调部署。对一个以模型实验为主的数据团队来说,这三层工作占用的工时往往超过算法本身,且模型迭代后前后端接口需要同步修改,维护成本持续累积。尤其是 LLM 应用场景,对话界面的流式输出、缓存管理、多轮会话状态都需要额外编码,进一步拉高了交付门槛。
Streamlit 用「纯 Python 脚本即应用」的执行模型解决了这一痛点:每一段脚本从上到下执行一次,页面组件(按钮、输入框、图表、数据表)通过 API 调用直接映射为 UI 元素,事件回调由框架自动处理,开发者无需编写任何前端代码或网络层逻辑。配合 st.cache_data 装饰器缓存耗时计算、st.session_state 保存跨交互的用户状态,一个可用的模型 Demo 通常在半小时内即可完成。与 Gradio 相比,Streamlit 更强调「应用级」能力——多页面导航、复杂布局、自定义组件与深度数据可视化集成,而不是仅停留在「函数到界面」的映射;与 Dash 相比,Streamlit 不需要声明回调依赖图(Dash 的 @app.callback 模式),代码更接近自然脚本流。这种低心智负担的设计使 Streamlit 成为数据团队成员自行交付工具的首选。
安装与环境配置:3 步就绪
安装 Streamlit 建议使用独立的 Python 虚拟环境,避免依赖冲突。以下步骤基于 Python 3.9–3.13 官方支持范围。
步骤一·安装。 使用 pip 或 conda 安装最新稳定版:
步骤二·验证安装:运行内置的欢迎页检查环境是否正常:
该命令会启动本地服务并打开浏览器,显示示例集合(包含图表、地图、LLM 对话等演示)。如果你在无图形界面的服务器上运行,可加 --server.headless true 参数。
步骤三·确认版本与配置:
首次运行时,Streamlit 会在用户目录生成 ~/.streamlit/config.toml 配置文件。常用配置项包括 server.port(端口,默认 8501)、server.address(监听地址)、browser.gatherUsageStats(是否收集匿名使用统计,建议设置为 false)。
python -m venv .venv && source .venv/bin/activate # 创建并激活虚拟环境pip install streamlit
streamlit hellostreamlit version # 查看当前版本streamlit config show # 显示全部可配置项及默认值
# 完整安装、验证、配置命令(可直接复制运行)python -m venv .venvsource .venv/bin/activatepip install streamlitstreamlit versionstreamlit config show
快速上手:10 分钟跑通第一个数据应用
以下示例以「加载 CSV 并交互式筛选」为最小可用场景:先写一个 20 行以内的脚本,再通过命令行启动,即可在浏览器完成数据上传、筛选与图表联动。Streamlit 的核心思路是「每个交互控件都是一个变量赋值语句」——用户操作控件时,脚本会从上到下重新执行,控件返回值自动赋给对应变量。
1. 在工作目录创建 app.py,写入下面的完整代码。
2. 在终端运行 streamlit run app.py,浏览器自动打开 http://localhost:8501。
3. 点击「浏览文件」上传一个 CSV,表格与图表会立即渲染;拖动滑块或选择筛选条件,界面实时刷新。
4. 结束运行按 Ctrl+C 停止服务。
import streamlit as stimport pandas as pd st.set_page_config(page_title="数据筛选器", layout="wide")st.title("📊 CSV 数据快速浏览与筛选") uploaded = st.file_uploader("上传 CSV 文件", type=["csv"])if uploaded is None: st.info("请上传文件开始体验") st.stop() df = pd.read_csv(uploaded)st.dataframe(df, use_container_width=True) # 数值列筛选num_cols = df.select_dtypes(include="number").columns.tolist()if num_cols: col = st.selectbox("选择数值列", num_cols) min_v, max_v = float(df[col].min()), float(df[col].max()) lo, hi = st.slider("筛选范围", min_v, max_v, (min_v, max_v)) filtered = df[(df[col] >= lo) & (df[col] <= hi)] st.line_chart(filtered.set_index(col) if not filtered.empty else pd.DataFrame())
核心能力详解:5 大支柱
支柱一·数据展示与交互组件。 st.dataframe 提供基于 Grid 引擎的交互式表格,支持排序、列宽拖拽、单元格选择,配合 st.column_config 可为列定制进度条、图片缩略图、链接等展示格式;st.data_editor 则在表格基础上允许用户直接编辑单元格并回写数据。图表方面,st.plotly_chart、st.altair_chart、st.line_chart 等 API 将主流可视化库的图表嵌入页面,其中 Plotly 图表保留全部交互能力(缩放、悬停、框选)。这类组件的共同点是「声明式」——开发者只描述数据与类型,渲染细节由框架接管。
支柱二·缓存系统。 st.cache_data 和 st.cache_resource 是性能优化的核心机制。st.cache_data 缓存返回可序列化数据的函数(如 DataFrame、字符串),适合数据加载与预处理;st.cache_resource 缓存不可序列化的全局资源(如数据库连接、大模型实例、TensorFlow 会话)。两者均基于函数参数与函数体哈希值判断是否命中缓存,并支持 ttl(存活时间)参数做定时失效。正确使用缓存可将重复计算降为 0,是数据应用从「能跑」到「快」的关键。
支柱三·会话状态管理。 st.session_state 是一个跨脚本重运行的字典,用于保存用户会话期间的变量:登录信息、表单输入、对话历史、分页页码等。配合 st.rerun 可手动触发重运行,配合回调参数 on_click、on_change 可在控件触发时执行额外逻辑。多轮 LLM 对话应用必须依赖会话状态保存消息历史,否则每次交互上下文都会丢失。
支柱四·多页面与导航。 st.Page + st.navigation 是 1.36 后新增的声明式多页面 API:先定义多个页面函数或文件,再用 st.navigation 组装导航结构,支持分组、图标与 URL 路径。相比早期基于文件目录的 pages/ 文件夹约定,新 API 支持动态页面控制(如根据登录状态决定可见页面),且页面切换不再完整重运行根脚本。多页面架构让 Streamlit 应用从「单页 Demo」升级为「多模块工具台」。
支柱五·LLM 对话专项能力。 st.chat_message 与 st.chat_input 两个 API 专为对话式应用设计:前者按「用户/助手」角色渲染气泡消息,后者提供输入框并自动管理提交事件。配合 st.write_stream 可实现 LLM 输出的流式打字效果,配合 st.status 可在对话中展示「思考中/执行工具」的阶段性状态。官方文档中的 LLM 教程提供了基于 OpenAI API 的完整对话应用参考实现,也兼容 LangChain 等框架的回调接口。
生产部署与监控:从上线到运维
部署方式一:Streamlit Community Cloud。 官方托管的免费部署方案:将应用代码推送至 GitHub 仓库,在 [share.streamlit.io](https://share.streamlit.io) 上用 GitHub 账号登录并选择仓库即可完成部署,支持自动检测 requirements.txt 安装依赖、每次 git push 自动重新部署、为应用分配 https://[app名].streamlit.app 子域名。免费层级限制为单个应用、约 1GB 内存与休眠机制(无访问时进入睡眠,下次访问冷启动约 10–30 秒),适合 Demo 与内部工具;企业版提供私有部署、SSO 与专属资源。
部署方式二:Docker 自托管。 需要私有化部署或资源弹性时,用官方镜像 python:3.11-slim 为基础构建:安装 Streamlit 后以 streamlit run app.py --server.port=80 --server.address=0.0.0.0 --server.headless=true 启动容器,配合 Nginx 反向代理与 HTTPS 证书。扩展多个副本时,需注意每个副本进程都有独立的会话状态,若需横向扩展应考虑将会话亲和性(sticky session)配置在负载均衡层。Kubernetes 部署可参考社区维护的 Helm Chart,但官方并未提供经过认证的 Helm 包,需自行验证。
可观测性。 Streamlit 内置 --server.fileWatcherType 控制文件监听策略;日志输出到标准输出,可用任意日志采集器(如 Promtail、Filebeat)收集。社区开发的 streamlit-analytics 等三方库可统计组件交互事件,但官方不提供内置埋点方案。指标监控建议独立实现:将关键业务指标通过 st.metric 展示给最终用户,同时在外层用 Prometheus exporter(如 prometheus-fastapi-instrumentator 包)暴露应用级指标——注意 Streamlit 自身是基于 Tornado 的 WSGI 服务,采纳此类方案时需要适配。
<p class=“para-label“>避坑清单:</p><ul class=”dash-list”><li>缓存与可变对象:默认 st.cache_data 对返回的 DataFrame 做深拷贝,但若函数内修改了全局可变对象(如 list.append),缓存会返回污染数据——缓存函数应保持纯函数,内部只读外部状态</li><li>敏感信息写入会话状态:st.session_state 中存放 API Key 等机密时,浏览器端可通过 Session State 调试面板查看——生产环境应改用 st.secrets 管理密钥,并通过后端代理调用大模型 API</li><li>跨会话共享缓存:st.cache_resource 缓存的是进程级单例,多个用户共享同一数据库连接或模型实例——注意连接池的并发上限与线程安全问题</li><li>多页面根脚本重复执行:使用旧的 pages/ 目录时每次页面切换都会重运行根脚本,如根脚本中有重计算会在页面切换时卡顿——改用 st.navigation 或把重逻辑移入缓存函数</li><li>社区云免费版资源限制:1GB 内存限制下加载大模型会直接 OOM——大模型应用应部署在自托管环境,社区云只放轻量推理的转发层</li></ul>
| 维度 | Streamlit | Gradio | Plotly Dash | NiceGUI |
|---|---|---|---|---|
| 定位 | 数据应用框架(脚本即应用) | ML 模型演示与分享 | 数据仪表盘框架 | 通用 Web UI 框架 |
| 编排范式 | 脚本重运行模型(自上而下) | 函数到界面映射(Inputs→Outputs) | 回调依赖图(@app.callback) | 基于 Vue/Quasar 的响应式绑定 |
| 类型约束 | 无类型系统(Python 原生) | 输入输出组件需声明类型 | 回调需声明 Input/Output 组件 | 无显式类型约束 |
| 学习曲线 | ★★☆☆☆ 低 | ★★☆☆☆ 低 | ★★★★☆ 中高 | ★★★☆☆ 中 |
| 生态集成 | 与 Pandas、Plotly、Altair 深度集成 | Hugging Face Spaces 一键部署 | 与 Plotly 图表同源 | 与 FastAPI 无缝对接 |
| 生产部署 | Community Cloud / Docker / 自托管 | HF Spaces / Docker | 自托管(企业版 Dash Enterprise) | Docker / 自托管 |
| License | Apache 2.0 | Apache 2.0 | MIT(Dash Community)+ 商业版 | MIT |
| 适合谁 | 数据科学家·ML 工程师·内部工具团队 | ML 研究者·模型分享者 | 企业数据分析团队·BI 场景 | 全栈 Python 开发者 |
选型建议:需要快速交付带数据探索、多页面结构的内部工具选 Streamlit;只需要把单个模型函数变成可分享的网页 Demo,选 Gradio 更轻(尤其配合 Hugging Face Spaces);要构建生产级、高定制度的企业数据仪表盘且团队有前端能力,选 Dash 更合适;如果追求接近原生 Web 的交互体验且愿意写更多控制逻辑,NiceGUI 是新兴备选。
版本迭代
Streamlit 自 2019 年开源以来保持每月一个小版本的高频迭代,主线方向从「单页 Demo 渲染」持续演进为「生产级数据应用平台」。2023 年 11 月至 2024 年 11 月间,重点补齐了多页面导航、对话框、局部状态控制与 LLM 对话专项 API,整体朝着模块化、可维护性方向收敛。(截至训练数据 2025 年初,可能已有更新版本)
| 版本 | 时间 | 变化 | 提升 |
|---|---|---|---|
| 1.30 | 2023-11 | `st.dataframe` 性能优化 | 大规模数据集的渲染性能显著提升,引入列配置 API(`st.column_config`) |
| 1.32 | 2024-01 | `st.dialog`(测试版) | 新增模态对话框组件,支持在弹窗内承载表单与流程 |
| 1.34 | 2024-03 | `st.popover` + `st.page_link` | 新增弹出式容器与页面链接组件,布局灵活性增强 |
| 1.36 | 2024-04 | 性能优化专项 | 脚本重运行耗时平均降低,改进 `st.rerun` 行为 |
| 1.39 | 2024-07 | 多页面 API 测试版 | 引入 `st.Page` / `st.navigation` 声明式多页面方案 |
| 1.41 | 2024-11 | 多页面正式版 + LLM 增强 | `st.navigation` 转正;`st.chat_message` 支持流式渲染;`st.status` 新增暂停/继续能力 |
Streamlit 的版本演进清晰地指向「摆脱玩具印象」——从单页渲染走向多页面架构,从手动管理状态走向内置会话机制,从通用组件走向 LLM 专项 API。选型建议关注 1.36 之后的版本,多页面与性能优化均在此之后才真正成熟;如果你依赖 st.navigation 做生产应用,务必使用 1.41+。
AI 应用场景
场景一:ML 模型交互式 Demo 与客户演示
阶段:模型交付 / 演示验证
解决的问题:算法团队交付模型时,业务方无法直观评估效果——传统做法是写 Jupyter Notebook 给业务看,或由前端团队开发一个完整的演示站点。Streamlit 将模型加载、推理、结果可视化压缩到一个脚本中,业务人员可通过滑块、上传控件直接与模型交互,从而在评审会上独立验证模型表现。
具体案例:某零售企业的销量预测模型交付中,数据团队用 Streamlit 构建了预测 Demo——业务人员上传历史销售 CSV,通过日期范围滑块调整预测区间,页面实时显示预测曲线与置信区间。演示从准备到上线耗时 1 个下午;相比此前开发 Flask + React 演示站的 1 周工期,交付效率提升约 20 倍,且模型迭代后只需重启脚本即可同步更新。
场景二:LLM 应用原型与内部工具
阶段:LLM 应用开发 / Agent 编排
解决的问题:LLM 应用的传统开发需要处理流式输出、多轮上下文、工具调用状态可视化等复杂交互。Streamlit 的 st.chat_message、st.write_stream、st.status 组合使开发者能够在 50 行内完成一个带流式输出的对话应用;配合 st.cache_resource 复用大模型实例,避免每个用户请求都重复加载模型。多页面 API 还支持将「对话测试」「Prompt 管理」「评估结果」拆分为独立页面,形成小型的 LLM 工作台。
具体案例:某金融科技公司的 RAG(检索增强生成)系统内测阶段,算法团队用 Streamlit 搭建了内部评测台:左侧上传测试文档集并触发向量化,中间进行对话质询,右侧展示检索命中的片段与回答得分。内测团队 30 人通过该工具在一周内完成了 2000 多轮评测对话,问题定位速度相比手工脚本提升 5 倍。
常见误区
误区Streamlit 能写复杂的 Web 应用,我应该用它替代 Django/FastAPI 来开发正式产品。
正解Streamlit 的脚本重运行模型虽然上手快,但在精细的 URL 路由、权限体系、WebSocket 长连接、复杂前端交互(如拖拽排序、富文本编辑)上能力有限。它最擅长的是数据密集型、交互层级浅的内部工具与原型;正式对外产品的后端逻辑应交给 FastAPI 等服务端框架,Streamlit 可作为其管理后台或展示层。
为何常见:Streamlit 官方 Gallery 展示了不少视觉精美的应用,容易让初学者误以为它能胜任任意复杂度的 Web 产品——实际上这些案例大多是数据展示型应用,交互深度有限。
误区遇到性能问题就给函数加上 `@st.cache_data`,缓存越多越快。
正解滥用缓存会引入两类问题:一是缓存了含副作用(写文件、发请求、生成随机数)的函数导致逻辑错误;二是 st.cache_data 对返回对象做深拷贝,大 DataFrame 反复拷贝反而增加内存开销。正确做法是只缓存纯计算函数、设置合理的 ttl、对超大对象改用 st.cache_resource(引用复用,不拷贝)。缓存命中率可通过 st.cache_data 附属的命中统计与调试面板观察。
为何常见:官方文档强调缓存是性能优化的关键,初学者容易将其视为「万能加速器」,忽略了纯函数前提与拷贝开销。
误区把 API Key 放在 `st.session_state` 或直接写在脚本里是安全的,反正用户看不到源码。
正解Streamlit 应用的脚本代码虽然默认不向最终用户展示,但社区云的部署模式下任何有权访问应用的人都可以通过浏览器的网络面板、Session State 调试器或应用的 _stcore 接口探查运行状态。正确的密钥管理方式是使用 st.secrets(社区云上通过「Secrets 管理」界面配置,自托管时通过环境变量注入),且不要在前端代码中引用敏感值做展示。
为何常见:本地开发时开发者能直接看到源码,容易形成「源码即安全边界」的错觉,忽略了 Web 应用的运行时信息暴露面。
误区Streamlit 要在项目里建一个固定名称的 `pages/` 文件夹,放入多个 `.py` 文件,这是唯一的多页面方式。
正解自 1.36 起,官方主推的 st.navigation + st.Page API 支持从单个文件或 Python 函数定义页面,不再依赖文件目录结构;旧版 pages/ 目录方式仍可用但已非推荐,且每次页面切换都会重运行根脚本,性能开销更大。新 API 还能按条件动态控制页面可见性(如登录态)。新项目应直接采用 st.navigation,存量项目可逐步迁移。
为何常见:大量早期教程和社区文章都基于 pages/ 目录写法,而官方文档中新 API 的阐述在 1.39 之后才逐渐完整,信息滞后导致多数人停留在旧模式。
面试题
Q1. 以下哪个命令用于启动 Streamlit 应用?
- A.
streamlit run app.py← 正确答案 - B.
streamlit serve app.py - C.
python streamlit app.py - D.
streamlit start app.py
答案:A。启动 Streamlit 应用的命令是 streamlit run <脚本路径>,默认监听 8501 端口。serve、start 均不是 Streamlit 的合法子命令;python streamlit app.py 也不是标准启动方式。
Q2. st.cache_data 与 st.cache_resource 的核心区别是?
- A.前者缓存函数返回值,后者缓存类实例
- B.前者只用于 DataFrame,后者只用于模型
- C.前者缓存可序列化数据并做深拷贝,后者缓存不可序列化资源(如连接、模型实例)且复用引用← 正确答案
- D.前者有 TTL 参数,后者没有
答案:C。st.cache_data 适用于返回可序列化对象的函数,框架会对返回值做深拷贝以隔离数据;st.cache_resource 适用于数据库连接、模型实例等不可序列化的全局资源,直接复用引用而不拷贝。两者都支持 ttl 参数,选项 D 错误;选项 A、B 的表述过于片面,选项 C 最准确。
Q3. Streamlit 的「脚本重运行」模型是指什么?
- A.每次用户交互,整个脚本会从上到下重新执行一遍← 正确答案
- B.脚本只在首次访问时运行一次
- C.脚本在后台持续运行,按时间间隔刷新
- D.只有被事件绑定的函数才会重运行
答案:A。Streamlit 的核心执行模型是「任何控件交互(点击、滑动、输入)都会触发整个脚本从头到尾重运行」,控件返回值在重运行中赋给对应变量。选项 B 是一般静态 Web 的模型;选项 D 是传统回调式框架(如 Dash)的模型,Streamlit 没有声明式事件绑定。
Q4. 在 st.navigation 多页面 API 中,页面之间的切换对脚本执行的影响是?
- A.每次切换都会重运行所有页面的脚本
- B.只重运行当前激活页面的脚本,根脚本不再整体重跑← 正确答案
- C.页面切换不触发任何脚本重运行
- D.切换时整个应用服务重启
答案:B。st.navigation 相比传统的 pages/ 目录方案,在切换页面时不再每次重运行根脚本,只执行当前页面对应的函数或文件,改善了多页面应用的性能。选项 A 是旧版目录方式的缺陷;选项 C、D 与 Streamlit 执行模型不符。
Q5. 以下哪个场景适合使用 st.cache_resource 而非 st.cache_data?
- A.读取 CSV 文件并返回 DataFrame
- B.调用外部 API 获取 JSON 数据
- C.初始化一个经由
torch.load加载的 PyTorch 模型← 正确答案 - D.计算两个 DataFrame 的合并结果
答案:C。PyTorch 模型实例不可序列化(含张量与梯度信息),且每个用户请求复用同一个模型实例能避免重复加载,这正是 st.cache_resource 的适用场景。选项 A、B、D 均返回可序列化数据(DataFrame、JSON),使用 st.cache_data 更合适。
Q6. 关于 st.session_state 的说法,正确的是?
- A.它存储在浏览器端,所有用户共享
- B.它存储在服务端,仅当前用户会话可见,且跨重运行保留← 正确答案
- C.它存储在服务端,所有用户共享
- D.它在每次脚本重运行时自动清空
答案:B。st.session_state 是服务端维护的会话级字典,绑定到当前浏览器会话(通过 session_id 标识),脚本重运行时保留数据,用户关闭浏览器或会话过期后清除。选项 A、C 混淆了浏览器端与服务端的存储位置;选项 D 与跨重运行保留的特性相反。
Q7. 以下哪些 API 是专为 LLM 对话应用设计的?
- A.
st.chat_message← 正确答案 - B.
st.chat_input← 正确答案 - C.
st.write_stream← 正确答案 - D.
st.data_editor
答案:ABC。st.chat_message 渲染对话气泡,st.chat_input 提供聊天输入框,st.write_stream 实现 LLM 输出的流式打字效果,三者是 Streamlit LLM 应用的组合基础。st.data_editor 是数据表格编辑组件,用于表格数据的交互编辑,不属于对话专项 API。
Q8. 关于 Streamlit Community Cloud 免费版,以下说法正确的有?
- A.免费版应用无访问量限制
- B.免费版有约 1GB 内存限制← 正确答案
- C.应用长时间无访问会进入休眠← 正确答案
- D.免费版支持私有仓库部署
答案:BC。Community Cloud 免费版限制单个应用约 1GB 内存,应用无访问一段时间后进入休眠(下次访问需冷启动),选项 B、C 正确。免费版不支持私有仓库部署(需公开仓库),也不承诺无访问量限制——资源受限时应用会被限流休眠。选项 A、D 与官方免费层限制不符。
Q9. 以下哪些做法能有效规避 Streamlit 生产中常见的坑?
- A.缓存函数保持纯函数,不修改外部全局状态← 正确答案
- B.将 API Key 直接放在
st.session_state中供前端调用 - C.使用
st.secrets管理密钥,并通过环境变量注入← 正确答案 - D.大模型应用部署在自托管环境而非社区云免费版← 正确答案
答案:ACD。保持缓存函数纯函数可避免共享可变状态的污染。st.secrets 是官方推荐的密钥管理方式,社区云可在控制台配置,自托管通过环境变量注入。免费版 1GB 内存无法容纳多数大模型,应自托管或使用付费资源。选项 B 将密钥存入会话状态会被浏览器端探测,属于安全反模式。
Q10. 在 Docker 部署 Streamlit 时,以下哪个启动命令参数能确保容器内的应用监听在外部可访问的地址?
- A.
streamlit run app.py --server.port=80 --server.address=0.0.0.0← 正确答案 - B.
streamlit run app.py --server.port=8501 --server.address=127.0.0.1 - C.
streamlit run app.py --client.showErrorDetails=false - D.
streamlit run app.py --server.headless=false
答案:A。--server.address=0.0.0.0 使服务监听所有网络接口,容器外可通过宿主机端口映射访问;127.0.0.1 仅本机回环访问,容器外无法连接。--client.showErrorDetails 是控制错误信息展示详情的参数,与网络监听无关。--server.headless=false 是关闭无头模式(用于本地浏览器自动打开),在容器中反而无意义。正确选项为 A。