在 Kivy 项目里，ScreenManager 负责多个屏幕之间的切换和生命周期调度。把上一个屏幕的数据带到下一个屏幕，看似只是传一个变量，实际却涉及实例创建时机、KV 规则加载顺序和回调触发顺序。很多人会直接拿到目标屏幕实例然后赋值，例如 self.manager.get_screen('second').user_name = self.ids.input.text。如果目标屏幕在启动时已经通过 add_widget 常驻内存，这段代码通常能工作；一旦改成按需创建或完全交给 KV 规则管理，get_screen 就可能返回 None，或者目标屏幕内部的控件还没有构建完成，导致赋值成功但界面上看不到变化。下面会先从 ScreenManager 的实例创建机制讲起，再给出几种受控的传参方式。
一、屏幕实例的创建时机与直接赋值的风险
ScreenManager 可以容纳多个 Screen 子类。我们可以在 App 的 build 方法里一次性把所有屏幕实例 add_widget 到 manager 中，也可以只添加一部分，等需要切换时再创建剩余实例。如果屏幕完全由 KV 语言声明，Kivy 会在解析规则时按需创建对应实例，Python 代码中很难拿到创建完成的精确时间点。
直接赋值最大的问题就出在这里。比如下面这个错误的用法：
# 错误示例：目标屏幕可能尚未创建
class FirstScreen(Screen):
def send_value(self):
second = self.manager.get_screen('second')
second.user_name = self.ids.name_input.text
self.manager.current = 'second'
这段代码假设 get_screen('second') 一定能拿到实例。假如第二个屏幕是在 KV 文件里声明的规则，且从未被访问过，它可能还没有实例化；即使实例已经存在，user_name 属性被设置后，目标屏幕的 on_pre_enter 或 on_enter 如果负责刷新控件，也需要保证读取顺序在控件创建之后。实际运行中经常表现为：第一次点击报 AttributeError，第二次点击又正常，或者切换后标签仍显示旧值。
要避免这种不确定，就需要让数据传递与屏幕生命周期解耦。目标屏幕应该在自己准备好的时机主动读取数据，或者在创建时就把参数作为构造参数接收，而不是依赖外部在任意时刻向它写入属性。
二、三种更稳妥的参数传递方式
第一种是把参数放进目标屏幕的构造函数。屏幕按需创建时，我们可以在跳转前创建实例，把必需数据传进去。
class DetailScreen(Screen):
def __init__(self, user_name='', **kwargs):
super().__init__(**kwargs)
self.user_name = user_name
def show_detail(self, name):
if not self.manager.has_screen('detail'):
detail = DetailScreen(name=name, name='detail')
self.manager.add_widget(detail)
else:
self.manager.get_screen('detail').user_name = name
self.manager.current = 'detail'
这种方式的优势在于依赖关系明确，创建时就知道数据来源。不过它要求调用方负责屏幕是否已经存在，适合 detail 这类需要多次打开、每次携带新参数的场景。如果屏幕数量很多，可以配合工厂函数统一处理创建逻辑。
第二种是使用 App 级别的共享状态对象。可以在 App 类里放一个字典或普通类，保存需要跨屏幕传递的字段。原屏幕只负责写状态，目标屏幕在进入时读取状态。
class SharedState:
def __init__(self):
self.user_name = ''
class MyApp(App):
def build(self):
self.state = SharedState()
return self.manager
class OrderScreen(Screen):
def submit(self):
app = App.get_running_app()
app.state.user_name = self.ids.name_input.text
self.manager.current = 'result'
class ResultScreen(Screen):
def on_pre_enter(self):
app = App.get_running_app()
self.ids.greeting_label.text = '你好，' + app.state.user_name
共享状态对象的优点是不需要屏幕之间互相引用，传参变成读写一个双方都知道的数据源。当应用有更多业务状态，例如用户登录信息、购物车数据时，这种模式会自然扩展成集中式的状态管理。执行顺序也更可控，因为目标屏幕是在自己的生命周期回调里读取，而不是被外界打乱节奏。
第三种是使用 ScreenManager 自身或事件回调暂存参数。例如在切换前把数据挂在 manager 上，目标屏幕的 on_enter 中取出。
def go_to_next(self, value):
self.manager.pending_value = value
self.manager.current = 'next'
这种方式和共享对象类似，但数据挂在 manager 上，容易导致 manager 职责不清。如果只有一两个临时参数，用起来快；状态多了还是建议独立的状态对象。对比下来，小型应用可以用构造参数或临时属性，中型应用更适合 App 级共享状态。
三、完整示例：输入屏幕传值给展示屏幕
这里给出一个可运行的完整示例。应用包含 FirstScreen 和 SecondScreen 两个屏幕，FirstScreen 提供一个 TextInput 和按钮，用户输入名字后点击发送，SecondScreen 显示问候语。代码使用 App 级共享状态，目标屏幕在 on_pre_enter 中刷新显示。
from kivy.app import App
from kivy.uix.screenmanager import ScreenManager, Screen
from kivy.lang import Builder
kv_string = '''
<FirstScreen>:
BoxLayout:
orientation: 'vertical'
TextInput:
id: name_input
hint_text: '请输入姓名'
Button:
text: '发送'
on_release: app.go_to_second(name_input.text)
<SecondScreen>:
BoxLayout:
Label:
id: greeting_label
text: '等待数据'
'''
class SharedState:
def __init__(self):
self.user_name = ''
class FirstScreen(Screen):
pass
class SecondScreen(Screen):
def on_pre_enter(self):
app = App.get_running_app()
name = app.state.user_name or '未填写'
self.ids.greeting_label.text = '你好，' + name
class MyApp(App):
state = None
def build(self):
self.state = SharedState()
Builder.load_string(kv_string)
self.manager = ScreenManager()
self.manager.add_widget(FirstScreen(name='first'))
self.manager.add_widget(SecondScreen(name='second'))
return self.manager
def go_to_second(self, name):
self.state.user_name = name
self.manager.current = 'second'
if __name__ == '__main__':
MyApp().run()
运行这个例子时，FirstScreen 不需要知道 SecondScreen 的存在，也不用调用 get_screen 去修改对方属性。按钮回调把输入文字交给 App 层的 go_to_second 方法，该方法先更新共享状态，再执行屏幕切换。SecondScreen 每次进入前都会执行 on_pre_enter，从 App 状态中取出最新值并更新 Label。这样即使输入为空、重复进入或调整屏幕创建顺序，行为也能保持一致。
如果想改成构造参数传递，也可以把 SecondScreen 的构造器接收 user_name，跳转时创建实例。但在本例中，SecondScreen 已经在启动时加入 manager，构造参数并不适合每次刷新。这个对比可以帮助理解：屏幕常驻时用生命周期回调读取状态，屏幕按需创建时用构造参数更直接。
四、需要避开的反模式与调试技巧
第一种常见反模式是使用模块级全局变量。比如在 screen1.py 里定义 USER_NAME = ''，在 screen2.py 里 import 后读取。这样的代码量最少，但全局变量会残留在进程生命周期里，测试和重新打开窗口时很容易拿到上一次的旧值。多个源同时修改时，问题更难排查。建议至少把状态归属到 App 实例下，保证生命周期与应用一致。
第二种是在目标屏幕的 __init__ 中读取 App 状态。KV 规则自动创建的屏幕，其 __init__ 调用顺序可能早于 App.build 中状态对象的初始化，这时访问 App.get_running_app().state 会得到 None 或抛异常。更安全的位置是 on_pre_enter 或 on_kv_post，这时 App 已经构建完成，控件也基本就绪。
第三种是在 on_enter 里再次修改 manager.current。某些开发者希望进入屏幕后自动跳转，但如果逻辑判断失误，A 屏幕进入后跳到 B，B 屏幕进入后跳回 A，就会形成切换循环，甚至导致无限递归。on_enter 和 on_pre_enter 只适合做数据准备和界面刷新，真正决定跳转的动作应该放在用户交互回调或明确的业务条件判断之后。
调试时可以临时在目标屏幕的 on_pre_enter 中打印当前屏幕名和状态值，确认切换路径。例如 print(self.name, app.state.user_name)。如果你发现数据为 None 或旧值，通常说明写入时机早于状态初始化，或者目标屏幕读取时状态还没有更新。把这些日志放在关键节点，能快速定位是写晚了还是读早了。
总结来说，ScreenManager 传参没有唯一正确答案，核心是让数据存在一个生命周期明确的位置，并让目标屏幕在自己准备好的时机去读取。避免依赖实例存在性和外部直接赋值，你的代码在屏幕越来越多时仍然会保持清晰可控。
KivyScreenManager参数传递修改时间：2026-10-03 14:48:30