入门 Eva J Patel(freeCodeCamp) 2026-09-10 16:14:02 · 0 阅读

第10章 State 与交互间数据管理

到目前为止,我们构建的大部分 Gradio 应用都遵循一个简单的模式:

  1. 用户输入数据。

  2. 用户触发事件。

  3. Python 函数处理输入。

  4. Gradio 展示结果。

这个模式足以应对许多小型应用,但实际项目中往往需要更多。

以聊天机器人为例,用户发送:

Hello!

应用回复:

Hi! How can I help?

然后用户接着问:

What is Gradio?

应用需要知道第二条消息是接在上一轮对话后面的。

如果每次交互都完全独立,应用就根本不知道之前发生过什么。

这正是状态发挥作用的地方。

什么是状态?

状态是应用在各次交互之间保存的信息。

它可以包括:

  • 对话历史

  • 已选配置

  • 计数器

  • 临时计算结果

  • 用户偏好

  • 上传的数据

  • 中间结果

一个简单的例子就是计数器。

假设有一个应用,上面有一个按钮,标签写着:

Increment

用户每点一次,屏幕上显示的数字就应该加一。

应用必须记住上一次的数字,这个被记住的值就是状态。

为什么普通 Python 变量不够用

你最初可能会这样写:

counter = 0

def increment():
    counter += 1
    return counter

但在 Gradio 应用里,这并不是管理状态的可靠方式。

这种做法有几个问题。

首先,Python 的变量作用域规则让修改外层变量比看上去复杂得多。

其次,全局变量的共享范围往往比预期更广。

第三,Gradio 应用可能有多个用户同时操作同一个应用。

你通常不希望一个用户的计数器影响到另一个用户的计数器。

Gradio 提供了专门用于管理交互式应用状态的机制。

gr.State

用于管理临时应用状态的主要组件是:

gr.State()

例如:

state = gr.State(0)

这里的 0 是初始值。

然后你可以把这个状态传入事件,并返回更新后的值。

构建一个计数器

下面是一个完整的例子:

import gradio as gr

def increment(count):
    count += 1
    return count, count

with gr.Blocks() as demo:
    count = gr.State(0)

    display = gr.Number(
        value=0,
        label="Count"
    )

    button = gr.Button("Increment")

    button.click(
        fn=increment,
        inputs=count,
        outputs=[count, display]
    )

demo.launch()

函数接收当前状态:

count

将其加一:

count += 1

并返回更新后的值。

第一个输出用于更新状态,第二个输出则更新用户看到的内容。

状态不一定是要显示的信息

需要区分的一点是,状态并不一定要直接显示在界面上。

例如:

conversation_history = gr.State([])

用户并不一定会看到这个列表本身,而是应用在内部使用它。

这使得状态非常适合用来保存那些需要持久化但无需直接展示的信息。

带重置功能的有状态计数器

接下来让这个计数器更实用一点。

import gradio as gr

def increment(count):
    count += 1
    return count, count

def reset():
    return 0, 0

with gr.Blocks() as demo:
    count = gr.State(0)

    display = gr.Number(
        value=0,
        label="Count"
    )

    with gr.Row():
        increment_button = gr.Button("Increment")
        reset_button = gr.Button("Reset")

    increment_button.click(
        fn=increment,
        inputs=count,
        outputs=[count, display]
    )

    reset_button.click(
        fn=reset,
        inputs=None,
        outputs=[count, display]
    )

demo.launch()

现在用户可以递增和重置计数器了。

状态与用户会话

状态(State)有实用价值的原因之一,是交互式应用可以同时服务多个用户。

假设 Alice 打开了你的应用,她点了五次计数器。

接着 Bob 打开同一个应用,他不应该自动看到 Alice 的计数。

State 的设计初衷是存放每个会话内的临时信息,而不是要求你把所有东西都存到全局。

如果需要持久化的用户账户或数据库,你得引入额外的基础设施。Gradio 的 State 不能替代数据库。

State 与数据库存储

这个区分很重要。

State 适合在交互或会话期间存放临时信息;当数据需要跨越应用的临时会话而长期保存时,就该用数据库。

举例来说:

State:

当前对话
当前选择
临时计算结果

数据库:

用户账户
已保存的文档
购买记录
长期偏好设置
应用数据

别拿 gr.State 当数据库用。

在 State 中存储列表

列表在记录对话历史时特别有用。

例如:

history = gr.State([])

函数可以接收现有的列表:

def add_message(message, history):
    history = history.copy()
    history.append(message)

    return history

聊天记录的具体结构取决于你使用的界面和 Gradio API,但核心思路不变:

Previous state
+
New information
=
Updated state

避免意外修改共享对象

操作列表和字典时,新建一个对象往往比就地修改已有对象更安全。

例如:

history = history.copy()
history.append(message)

这样更新操作更显式。

对于嵌套数据结构,根据实际需求你可能需要更深层的拷贝。

State 可以存储字典

例如:

settings = gr.State({
    "theme": "light",
    "language": "English",
    "temperature": 0.7
})

函数可以修改这些设置并返回更新后的字典,这在需要管理多项相关配置的应用中很有用。

示例:存储应用配置

import gradio as gr

def update_settings(language, temperature):
    return {
        "language": language,
        "temperature": temperature
    }

with gr.Blocks() as demo:
    language = gr.Dropdown(
        choices=["English", "Spanish", "French"],
        value="English",
        label="Language"
    )

    temperature = gr.Slider(
        minimum=0,
        maximum=1,
        value=0.7,
        label="Temperature"
    )

    settings = gr.State({})

    button = gr.Button("Save Settings")

    output = gr.JSON()

    button.click(
        fn=update_settings,
        inputs=[language, temperature],
        outputs=[settings, output]
    )

demo.launch()

State 保存当前配置,JSON 组件则将其可视化,方便演示。

实际项目中,State 通常只作为内部状态使用,不需要额外展示。

多步工作流中的 State

当应用由多个阶段组成时,State 的作用尤为突出。

以文档处理流程为例:

Upload document
↓
Extract text
↓
Clean text
↓
Analyze text
↓
Generate summary

你不一定希望每个阶段都重复之前的工作。提取出的文本可以存到 state 里。

例如:

document_text = gr.State("")

提取之后:

def extract_document(file):
    text = ...
    return text

这样文本就能供下一步操作使用了。

示例:文档处理的 State

import gradio as gr

def extract_text(file):
    if file is None:
        return "No file uploaded."

    return "Extracted document text goes here."

def summarize(text):
    if not text:
        return "No text available."

    return f"Summary generated from: {text[:100]}"

with gr.Blocks() as demo:
    file = gr.File(label="Upload Document")

    document_text = gr.State("")

    extract_button = gr.Button("Extract Text")
    summarize_button = gr.Button("Summarize")

    preview = gr.Textbox(
        label="Extracted Text",
        lines=8
    )

    summary = gr.Textbox(
        label="Summary",
        lines=6
    )

    extract_button.click(
        fn=extract_text,
        inputs=file,
        outputs=[document_text, preview]
    )

    summarize_button.click(
        fn=summarize,
        inputs=document_text,
        outputs=summary
    )

demo.launch()

提取出的文本单独存储,与可见的预览分开,这样后续操作就能用到它。

State 与聊天机器人

聊天机器人是体现 state 的最典型例子。

一段对话可能是这样:

User: What is Python?
Assistant: Python is a programming language.

User: What is it used for?
Assistant: It is commonly used for web development, data analysis, automation, AI, and more.

第二个回答需要知道之前的交互内容,所以聊天机器人需要维护对话历史。

好在 Gradio 的高层聊天界面已经帮你处理了大部分工作,我们会在第 13 章详细探讨。

State 不会自动让数据永久保存

这一点值得反复强调,因为很容易引起困惑。

如果你的应用把数据存在:

gr.State()

不要假设这些信息会被永久保存。会话结束后,状态数据可能不再可用。

如果需要持久化存储,应使用数据库、文件系统或外部服务。

状态与高开销计算

状态还能避免重复计算。

假设你已经处理过一份大型文档。不必每次用户提问时都重新解析同一份文档,而是将处理后的表示存储起来。

例如:

processed_document = gr.State(None)

后续问题可以直接使用这些数据。

这能显著提升应用的响应速度。

状态与安全

状态不能替代身份验证或授权机制,也不要把它当作存储高敏感信息的安全保险箱。

如果应用涉及隐私数据,需要有意识地设计存储、认证、访问控制和数据保留策略。

动手试试

试着做一个简单的"学习会话追踪器"。

应用应包含:

  • 科目下拉框

  • 开始学习会话的按钮

  • 标记会话完成的按钮

  • 会话计数器

  • 当前科目展示

使用 gr.State 记录:

  • 已完成的会话数

  • 选中的科目

再添加一个重置按钮。

目标是在交互之间存储信息,而不是每次都从界面组件重新计算。

要点总结

  • 状态用于在交互之间保存信息。

  • gr.State 适合存储临时的会话级数据。

  • 状态可以存储数字、列表、字典等 Python 对象。

  • 状态适用于计数器、设置、对话历史和中间结果。

  • 状态不等于持久化存储。

  • 当信息需要跨越会话保留时,使用数据库或持久化存储。

  • 避免用全局变量来管理用户级应用状态。

评论 (0)