Wayland与PipeWire：替代X11与PulseAudio的渐进迁移指南

Wayland 和 PipeWire 是近十年 Linux 桌面和多媒体栈里最常被提起也最容易被混淆的两个名词。前者是显示协议目标是把已经运行几十年的 X11/Xorg 逐步替换掉后者是多媒体会话服务希望接管 PulseAudio 和 JACK 的音频场景同时解决桌面录屏和视频流转发问题。很多用户在发行版更新后不知不觉跑到了 Wayland 会话上声音服务也换成了 PipeWire随后出现窗口缩放、屏幕共享、蓝牙音频和 Qt 应用无法启动等各种问题。这篇文章从“Wayland、PipeWire 以及开源旧组件如何缓慢关闭”的角度切入梳理新旧协议并存的原因、会话切换方法、核心配置、常见报错和可复用排查清单。这里先说清楚一个判断Wayland 和 PipeWire 并不是要把 X11、PulseAudio 在一夜之间删除而是通过兼容层和并行安装的方式让新协议逐步接管新特性旧组件继续服务老应用。用户和开发者在过渡期真正需要掌握的不是某个激进的操作步骤而是如何确认当前会话、如何切换、如何查看日志、如何回滚。1. 先理解 Wayland 与 PipeWire 的定位差异和演进逻辑1.1 Wayland 首先是显示协议不是桌面环境也不是窗口管理器很多人把 Wayland 理解成“一个新的 GNOME”或者“一个新的桌面环境”这是最常见的误解。Wayland 实际定义的是一套客户端与显示服务器之间的通信协议它的核心目标是替代 X11 协议。X11 从 1987 年发展至今包含了大量为早年硬件和网络场景设计的功能比如远程 X11 转发、复杂的输入法链、窗口管理器与 X Server 的层层叠加等。这些机制在现代 GPU 合成、安全隔离和触摸屏场景里越来越难维护。Wayland 的思路更直接客户端把需要显示的缓冲区内容提交给 compositorcompositor 负责最终合成并输出到屏幕。也就是说Wayland 不是把绘制任务分散给每个窗口而是将合成权统一交给合成器。常见的 GNOME 的 Mutter、KDE 的 KWin、wlroots 都是不同形态的 Wayland compositor 实现。工作方式上的核心差异可以用最小链路表示X11: App - X Server - 合成器 - 显示屏幕 Wayland: App - Wayland Compositor - 显示屏幕在 Wayland 下App 不再与 X Server 打交道而是直接与 compositor 通信。这个简化带来两个主要收益画面合成路径更短延迟更容易控制窗口内容不再暴露给全局 X Server安全性更好。容易误解的地方在于Wayland 不是一个可执行程序名运行wayland命令是无效的。你需要运行的是一个实现了 Wayland 协议的 compositor比如 GNOME 桌面本身就是一个 Wayland compositor。对于用户来说登录时选择 Wayland 会话就是在告诉系统让我用 Wayland 协议作为显示链路。1.2 PipeWire 是多媒体服务音频之外还管视频流PipeWire 和 Wayland 经常一起出现是因为它们都在 Linux 桌面现代化过程中承担了“替换旧组件”的角色。PipeWire 不是显示协议而是一个多媒体服务框架。它最早由 Wim Taymans 在 Red Hat 发起目标是把 PulseAudio 的易用性、JACK 的低延迟能力和专业音频图模型整合到同一个服务里并在后续扩展出视频流采集和分发能力。通俗理解PulseAudio 主要管音频JACK 主要管专业音频连接关系而 PipeWire 想同时满足这两类需求再把摄像头、录屏、应用视频流也纳入统一管理。Wayland 环境下OBS 录屏、远程会议共享桌面等操作很多都依赖 PipeWire 配合 xdg-desktop-portal 完成。PipeWire 在发行版里通常拆成几个组件pipewire核心服务处理图调度和流路由。pipewire-pulsePulseAudio 兼容层让旧音频客户端继续通过pactl、pulseaudio接口工作。wireplumber会话管理器负责发现设备、加载策略、保存默认设备等信息。最小验证命令如下systemctl --user status pipewire pipewire-pulse wireplumber如果三个服务都在运行再使用pactl info | grep Server Name输出中有PulseAudio (on PipeWire)字样说明当前音频栈已经通过 PipeWire 提供 PulseAudio 兼容服务。这个兼容层很重要它让大量还没有迁移到原生 PipeWire API 的音频程序继续正常运行。1.3 “缓慢关闭”的真实含义旧组件不会立刻消失但新特性会优先落在新协议上项目标题里的 “Slowly Closing” 很容易被理解成某一天某个官方组织会直接关闭 X11 或 PulseAudio 的服务。实际上Linux 生态不存在一个总开关能关闭所有旧组件。更准确的说法是X11 和 PulseAudio 进入维护模式上游不再为它们设计大规模新特性而 Wayland 和 PipeWire 成为新功能的首选载体。可以用下面的表格表达当前常见的状态组件定位当前状态新功能方向兼容策略X11/Xorg显示服务维护模式基本不新增架构级特性Xwayland 提供兼容层Wayland显示协议活跃开发严格隔离、安全、高分屏、新输入协议通过 Xwayland 兼容 X11 应用PulseAudio音频服务维护模式基本不新增架构级特性pipewire-pulse 提供兼容层PipeWire多媒体服务活跃开发音视频统一图模型、低延迟、录屏、投屏同时兼容 PulseAudio 和 JACK 应用这个表格解释了很多用户的困惑为什么自己已经安装了 Wayland大多数应用还能用因为系统里有 Xwayland 在后台运行X11 应用被转换后显示在 Wayland 桌面上。为什么音频服务还显示 PulseAudio因为 pipewire-pulse 故意保留了 PulseAudio 的名字和服务接口让旧客户端不感知变化。注意判断一个系统是否“已经关闭”旧组件不能只看是否安装而要看默认会话、默认音频服务、以及上游项目的维护状态。2. 从 X11 到 Wayland切换前先确认会话再谈设置和扩展2.1 三条命令确认当前会话是 Wayland 还是 X11不少人遇到问题后连自己当前在哪个会话里都不知道排错就会走弯路。在 Linux 上确认会话类型最稳定的方式是查看环境变量和登录会话信息。第一条命令echo $XDG_SESSION_TYPE输出wayland或x11这是桌面会话启动时由显示管理器设置的环境变量。如果输出为空可以检查登录会话信息loginctl show-session $(loginctl | grep $(whoami) | awk {print $1}) -p Type输出示例Typewayland或者查看正在运行的关键进程ps -e | grep -E Xorg|wayland如果看到Xorg进程说明当前会话可能通过 Xorg 启动如果看到gnome-shell等 compositor 进程而没有 Xorg大概率是 Wayland 会话。这里要提醒一点Wayland 会话下也可能看到 Xorg 进程因为 Xwayland 本身就是由 Xorg 代码演变的所以不能只靠这一个命令下结论。最可靠的方式还是XDG_SESSION_TYPE。2.2 在登录管理器里切换会话GDM 和 SDDM 的操作路径很多用户需要从 Wayland 切回 X11最常见原因包括某些老软件截图黑屏、全局快捷键失效、高 DPI 缩放模糊、远程控制不流畅。切换位置在登录管理器的会话选择器里不在系统设置里。以 Ubuntu 默认的 GDM 登录界面为例在登录界面输入用户名后不要急着输入密码。点击密码输入框右下角或底部区域的齿轮/图形图标。从菜单中选择Ubuntu on Xorg这就是进入 X11 会话。输入密码登录后用echo $XDG_SESSION_TYPE验证。KDE Plasma 默认使用 SDDM 时登录界面左下角通常有会话类型选择菜单其中可能出现Plasma (Wayland)和Plasma (X11)两个选项。选择名称因发行版而异但做法一致。如果登录菜单里根本没有 Wayland 选项可能原因包括显卡驱动不支持 Wayland 合成器例如部分 NVIDIA 驱动版本受限。桌面环境版本没有启用 Wayland 会话文件。发行版刻意默认禁用 Wayland。这种情况不要直接手动安装一堆协议包先确认桌面环境的 Wayland 支持状态。2.3 Xwayland 兼容层老应用还能跑但可能存在姿势问题在 Wayland 会话里运行绝大多数 X11 应用靠的是 Xwayland。Xwayland 是一个运行在 Wayland compositor 上的 X Server它把 X11 应用的窗口内容桥接到 Wayland 合成器。好处是兼容性高坏处是某些 X11 特有的窗口操作在桥接时存在限制。常见表现包括Electron 老版本应用在多屏下缩放模糊。截图工具只能截到黑屏因为 Wayland 默认阻止 X11 应用读取整个屏幕内容。使用xdotool模拟全局点击、查找窗口时失效或权限不足。拖拽行为与应用预期的 X11 窗口管理逻辑不一致。如果为了排查某个应用在 Wayland 下行为异常可以临时让该应用走 XwaylandGDK_BACKENDx11 应用名 QT_QPA_PLATFORMxcb 应用名这里需要注意设置环境变量强制走 X11 只是排查手段不是长期解决方案。一旦该应用被桥接到 Xwayland它反而会失去 Wayland 原生应用的某些特性比如高分屏适配和输入法协同能力。2.4 GNOME 的 Wayland 扩展设置在哪扩展应用和配置目录热词里经常出现“gnome的wayland扩展在哪设置”说明很多人打开了 Extensions 应用却找不到自己安装的扩展。事实上GNOME Shell 扩展机制在 Wayland 会话下仍然有效只是配置入口有所差异。推荐路径gnome-extensions list gnome-extensions enable extension-id gnome-extensions disable extension-id从 GNOME 40 开始很多发行版把桌面扩展管理做成一个独立的 GUI 应用应用名就叫 “Extensions” 或 “GNOME Extensions”。部分发行版还需要安装额外的扩展管理器才能浏览在线扩展sudo apt install gnome-shell-extension-manager扩展的安装位置没有变用户级扩展放在~/.local/share/gnome-shell/extensions/扩展ID/遇到扩展在 Wayland 下不生效时先看扩展定义文件里是否依赖 X11 特定的窗口管理接口比如通过 Xfixes、EWMH 等机制操作全局窗口。这类扩展在 Wayland 下通常被 GNOME Shell 禁用只有兼容 Wayland 的扩展才能正常工作。注意在 Wayland 会话下强制启用带 X11 依赖的扩展不仅无法恢复功能还可能导致 GNOME Shell 反复卡顿或崩溃。优先查看扩展页面是否标注 “Supports GNOME 40 / Wayland”。3. 从 PulseAudio 到 PipeWire迁移不是卸载换装而是兼容叠加3.1 安装并确认 PipeWire 组件已经接管音频服务PipeWire 在主流发行版里越来越普遍但很多系统并不是自动迁移的。从 PulseAudio 换成 PipeWire 时不要先卸载 PulseAudio因为部分发行版的桌面组件还依赖pulseaudio包名。正确做法是安装 PipeWire 和兼容服务然后让pipewire-pulse接管 PulseAudio 的 socket。以 Debian/Ubuntu 系为例sudo apt install pipewire pipewire-pulse wireplumber安装完成后需要重启用户级服务或重新登录systemctl --user daemon-reload systemctl --user --now restart pipewire pipewire-pulse wireplumber验证是否接管成功pactl info在输出中查找Server Name。如果显示PulseAudio (on PipeWire)说明兼容层已经接管。如果仍然显示PulseAudio且进程是/usr/bin/pulseaudio说明系统仍在使用老的 PulseAudio 服务。此时需要检查pipewire-pulse.socket是否启用并考虑屏蔽原 PulseAudio 用户服务systemctl --user mask pulseaudio systemctl --user --now enable pipewire-pulse.socket这里不建议执行禁用手脚因为不同发行版默认服务互相依赖。务必备份当前配置并确认桌面环境没有依赖 pulseaudio 服务。3.2 配置文件放哪里系统默认文件与用户覆盖文件的优先级PipeWire 的配置结构比 PulseAudio 更模块化。系统级默认配置一般在/usr/share/pipewire/下面是多个.conf文件。用户级自定义配置放在~/.config/pipewire/。推荐做法是复制需要修改的默认文件到用户目录再改不要直接修改/usr/share。cp /usr/share/pipewire/pipewire.conf ~/.config/pipewire/在~/.config/pipewire/pipewire.conf里最常调整的是音频采样率和时钟配置context.properties { default.clock.rate 48000 default.clock.allowed-rates [ 44100 48000 96000 ] default.clock.quantum 1024 }参数含义参数影响调大效果调小效果default.clock.rate默认采样率音质可能更好但 CPU 占用增加资源占用低可能出现采样率不匹配default.clock.quantum音频处理周期更稳定但延迟升高延迟更低但可能出现爆音link.max-buffers缓冲数量抗抖动能力强但内存占用高内存占用低但链路容易欠载对于大多数桌面用户保持 48000 采样率和默认 quantum 即可。专业音频用户可以按 JACK 的使用经验调整quantum到 256 或更低但需要测试 CPU 是否能承受。3.3 蓝牙、录屏和 JACK 应用PipeWire 最容易出现问题的三个方向蓝牙耳机连接后没有声音是 PipeWire 迁移后最高频的问题之一。排查顺序如下先用bluetoothctl info确认蓝牙设备已连接。查看wpctl status中是否有蓝牙设备输出节点。使用wpctl set-default id切换默认音频设备。查看 WirePlumber 日志journalctl --user -u wireplumber -f日志中如果出现 Bluetooth 相关错误通常需要确认bluez版本和libspa-0.2-bluetooth是否安装。不同发行版的蓝牙插件包名不同不要只装核心 PipeWire 包。录屏黑屏是 Wayland 下的常见问题。Wayland 出于安全考虑不允许任意应用直接截取整个屏幕录屏必须通过xdg-desktop-portal与 PipeWire 协同。OBS Studio 在 Wayland 下选择 “PipeWire Video Capture Source” 作为采集源弹窗授权后才能采集。如果黑屏先检查 xdg-desktop-portal 的 Desktop Portal 实现是否完整systemctl --user status xdg-desktop-portalJACK 应用在 PipeWire 下并不是直接运行而是要安装pipewire-jack兼容层。安装后JACK 客户端会通过 PipeWire 运行但需要同时确认wireplumber的策略是否给 JACK 应用分配足够的实时优先级。3.4 生产环境回退策略保留 PulseAudio 服务的正确姿势PipeWire 并不适合所有生产环境。专业录音棚、低延迟音频采集、以及老设备上测试时可能仍然需要回到 PulseAudio。保留回退路径的关键在于服务单位之间的关系。准备回退时不需要卸载 PipeWire只需要暂停pipewire-pulse兼容层并恢复 PulseAudio 服务systemctl --user mask pipewire-pulse.service pipewire-pulse.socket systemctl --user --now enable pulseaudio.service但要注意很多桌面环境会在登录时自动启动 PipeWire 套件。如果只暂停服务下次登录可能又被拉起。此时需要检查用户 autostart 目录和发行版的/etc/xdg/autostart中是否包含 pipewire 相关启动项。建议在生产环境使用新音频协议前先在备用用户下完整测试并把服务启停写成一个脚本。不要在生产机器上只凭一行命令切换随后又无法恢复窗口和音频。4. 常见错误排查链路从 Qt Wayland 插件到缺失头文件4.1 Qt 应用提示 could not find the Qt platform plugin wayland这个错误经常出现在从旧系统升级、自行编译 Qt 程序、或者精简安装桌面环境之后。提示通常类似qt.qpa.plugin: Could not find the Qt platform plugin wayland in even though it was found. 或者 qt.qpa.plugin: could not load the Qt platform plugin wayland in even though it was found.先说原因Qt 启动时需要通过平台插件创建窗口。Wayland 会话下Qt 默认尝试加载libqwayland-egl.so或libqwayland-generic.so。如果这个插件没有随 Qt 安装应用就无法运行。排查步骤# 查看系统上是否安装 Wayland 平台插件 find /usr/lib -name *qwayland* 2/dev/null # 查看 Qt 插件搜索路径 qtpaths --plugin-dir对于 Qt 5Debian/Ubuntu 包名一般是qtwayland5sudo apt install qtwayland5对于 Qt 6sudo apt install qt6-wayland安装完成后重新运行应用。如果仍然报错可以开启 Qt 插件加载日志定位具体原因export QT_DEBUG_PLUGINS1日志中会打印插件目录、加载尝试和缺失依赖。临时绕行方案是把平台强制指定为 xcbexport QT_QPA_PLATFORMxcb ./你的Qt程序这只能让应用暂时通过 Xwayland 运行不能代替安装 Wayland 平台插件。长期使用时应优先补齐对应的 Qt Wayland 插件。4.2 交叉编译报错 “arm_acle.h、“core_cm0plus.h 头文件找不到一些做嵌入式 Linux 桌面接口或者底层媒体库移植的人在编译 PipeWire、Wayland 协议生成文件或 GPU 图形库时会看到与 ARM 编译器相关的头文件错误error: #5: cannot open source input file arm_acle.h: no such file or directory fatal error: core_cm0plus.h: No such file or directory这个报错从现象上看和 Wayland、PipeWire 没有直接关系但却是嵌入式环境编译多媒体栈时常见的拦路虎。两个头文件来源不同arm_acle.h属于 ARM C Language Extensions通常由 ARM Compiler 或现代arm-none-eabi-gcc工具链自带。core_cm0plus.h属于 CMSIS-Core 的一部分用于 Cortex-M0 内核设备描述通常由ARM::CMSISpack 提供。常见错误原因是工具链的 include 搜索路径没有包含这些头文件。排查顺序如下# 检查交叉编译工具链自带 include 路径 arm-none-eabi-gcc -print-file-nameinclude # 在输出目录中查找 arm_acle.h ls $(arm-none-eabi-gcc -print-file-nameinclude)/arm_acle.h如果工具链目录下找不到说明当前 GCC 版本或 ARM Compiler 版本不完整。不要从网上下载单个头文件塞进项目因为这容易造成编译器内建宏与头文件版本不匹配。正确做法是更新工具链或 Keil MDK 的 ARM Compiler 版本。在工程配置中安装对应 CMSIS pack例如在 Keil 中打开 Pack Installer选择 ARM::CMSIS。在编译参数里显式添加 CMSIS 头文件搜索路径-I../Drivers/CMSIS/Include如果报错出现在编译 Wayland 协议文件或 PipeWire 的库时还需要区分目标平台是 ARM Linux 还是 MCU 裸机。ARM Linux 编译通常使用aarch64-linux-gnu-gcc报错逻辑不同。先用工具链自身 include 路径定位再检查系统头文件依赖不要一开始就试图修改协议源码。4.3 编译 Wayland 相关项目时协议头文件或工具缺失自行编译 Qt、GTK、wlroots 或使用 Wayland 协议的应用时还可能遇到如下错误fatal error: wayland-client.h: No such file or directory Program wayland-scanner not found xdg-shell-protocol.c: No such file or directory这些错误说明开发环境中缺少 Wayland 开发包和协议描述文件。Wayland 本身不是静态协议很多接口通过 XML 协议描述文件生成代码。系统需要至少三个部分libwayland-dev包含wayland-client.h、wayland-server.h和wayland-scanner。wayland-protocols包含xdg-shell、wlr-layer-shell等协议 XML 文件。对应桌面环境的扩展协议包比如libqt5waylandclient5-dev。安装示例sudo apt install libwayland-dev wayland-protocols qtwayland5安装后验证pkg-config --modversion wayland-client wayland-scanner --version这样编译环境才能满足 Wayland 协议代码生成要求。4.4 高频问题排查表问题现象常见原因检查方式处理建议登录菜单没有 Wayland 选项显卡驱动不支持或桌面未启用 Wayland 会话查看/usr/share/wayland-sessions/是否存在桌面会话文件更新驱动确认桌面环境版本支持某些 Qt 程序启动即退出Qt 平台插件缺失或被强制加载 Wayland 插件QT_DEBUG_PLUGINS1查看日志find插件路径安装对应 qtwayland5/qt6-wayland必要时临时使用 xcb音频服务仍显示 PulseAudiopipewire-pulse 未接管或未屏蔽原服务pactl info查看 Server Name启用 pipewire-pulse.socketmask pulseaudio 服务蓝牙耳机连接后无声WirePlumber 未识别设备或未切换默认节点wpctl status、journalctl --user -u wireplumber -f安装蓝牙 spa 插件设置默认 sinkOBS 录屏黑屏未通过 xdg-desktop-portal 授权查看systemctl --user status xdg-desktop-portal在 OBS 中选择 PipeWire Video Capture SourceGNOME 扩展在 Wayland 下失效扩展依赖 X11 特有接口gnome-extensions info查看错误信息寻找支持 Wayland 的替代扩展5. 学习环境和生产环境分别怎么落地才是迁移的正确姿势5.1 学习环境快速试用但保留清晰回滚点学习 Wayland 和 PipeWire 时最大的优势是可以反复实验。推荐在这些场景里测试虚拟机安装一个全新的桌面发行版选择 Wayland 会话。使用备用用户登录避免破坏主用户配置。安装 PipeWire 但不卸载 PulseAudio先通过兼容层观察行为。记录/etc/apt/sources.list或软件源版本信息方便回滚。学习阶段的核心任务不是立刻把 X11 卸载而是建立几条命令的肌肉记忆# 查看当前会话 echo $XDG_SESSION_TYPE # 查看音频服务 pactl info | grep Server Name # 查看 PipeWire 日志 journalctl --user -u pipewire -u wireplumber -f5.2 生产环境迁移前检查清单生产环境涉及真实用户和数据迁移前要形成一张可勾选的清单。以桌面工作站为例检查项验证方式通过标准GPU 驱动和桌面版本glxinfo、桌面关于页面Wayland 会话能稳定登录无频繁崩溃浏览器和办公软件分别测试视频播放、下载、打印无窗口闪烁、缩放正常会议软件和录屏测试共享屏幕、摄像头、音频输入无黑屏、无回声、无无声蓝牙设备和专业音频连接蓝牙耳机、外接声卡设备能被识别并正常切换输入法和快捷键切换输入法、触发全局快捷键无失效现象日志与监控journalctl --user -u pipewire -u wireplumber无持续刷屏错误如果核心软件在高 DPI 缩放、多屏、混合刷新率等场景下无法正常工作就不建议立刻切到 Wayland。可以把迁移计划推迟到兼容版本发布后而不是让用户承担实验风险。5.3 最佳实践兼容层、环境变量、日志和回滚手段缺一不可无论使用 Wayland 还是 PipeWire过渡阶段的工程规范可以总结成几条可执行原则。第一不要急于卸载旧组件。Xwayland 和 pipewire-pulse 都是兼容层它们的价值就是让旧应用继续工作。很多迁移失败案例是在卸载旧组件后某些老应用连启动都变得困难。保留旧组件只是通过默认协议和服务接管实现切换风险远小于清除式迁移。第二环境变量要按应用设置不要全局强制。例如GDK_BACKENDx11 Google Chrome QT_QPA_PLATFORMxcb 某个老Qt工具不要把这些环境变量写进/etc/environment或 shell 配置文件的全局部分否则会让所有 GTK/Qt 应用都退化到 Xwayland失去 Wayland 原生性能。第三日志路径要固定遇到问题先看日志再改配置。Wayland 和 PipeWire 都属于用户级服务默认日志都输出到 journald 用户会话中。排查时优先查看journalctl --user -u pipewire -u pipewire-pulse -u wireplumber这里比直接改配置文件更有价值的是先看到错误行确认是设备识别、策略加载还是 buffer 溢出。第四配置文件和回滚脚本要纳入版本管理。至少把~/.config/pipewire/、~/.config/wireplumber/和当前登录会话信息保存备份。因为 PipeWire 配置项很多一个采样率参数就可能影响整个系统的音频稳定性。5.4 下一步学习路径从用户操作走向协议本质如果这篇内容帮助你完成了从 X11 到 Wayland、从 PulseAudio 到 PipeWire 的切换那接下来的学习方向可以更深一层。阅读 Wayland 官方文档和weston示例代码理解 compositor-client 握手过程。尝试用wayland-scanner从一个 XML 协议生成 C 客户端代码理解 xdg-shell 的创建流程。研究 PipeWire 的 object、node、port、link 模型用pw-cli或wpctl查看设备节点连接关系。阅读xdg-desktop-portal的会话管理逻辑了解 Wayland 下录屏和屏幕共享的授权链路。关注 X11 和 PulseAudio 上游的维护公告但不要把所有希望寄托在某次“废弃”消息上。新旧协议会在很长一段时间内共存。Wayland 和 PipeWire 的演进节奏并不相同Wayland 改变的是窗口系统底层的信任模型和合成路径PipeWire 改变的是音频和视频流的服务模型。它们的共同点在于都通过兼容层降低了迁移阵痛让开源生态得以在不打断用户工作的前提下缓慢关闭旧组件。对普通用户来说掌握会话类型确认、登录切换、音频服务验证和日志排查就够了对开发者来说深入协议本身才能在迁移来临时做出合理的架构判断。