* 背景 =fcitx= 是 Linux 下常用的输入法框架，用于在英文环境中输入中文、日文、韩文等语言。它的工作方式是"拦截"应用程序的键盘输入，在用户敲拼音时弹出候选词窗口，选中后把中文字符提交给应用程序。 这个"拦截"机制意味着 =fcitx= 会插入到键盘事件的传递链路中。如果这条链路的某个环节出了问题，键盘输入就会受影响——而我遇到的就是这种情况。 * 故障现象 某天，我发现启动 =fcitx= 后，整个键盘输入变得 *非常卡* ——敲一个键要等半秒甚至更久才有反应。但鼠标完全正常，丝毫不受影响。不启动 =fcitx= 就一切如常。 键盘卡而鼠标没事，这个现象很诡异。直觉告诉我：一定是 =fcitx= 做了什么只影响键盘、不影响鼠标的事情。 * 排查过程 ** 第一步：收集基础信息 先搞清楚环境。我的系统是 Arch Linux，窗口管理器是 =awesome= ，显示服务器是 =Xorg= ， =fcitx= 版本是 4.2.9.9（fcitx4）。 #+begin_src shell uname -r # 6.19.12-arch1-1 fcitx --version # fcitx version: 4.2.9.9 #+end_src 然后运行 =fcitx= 自带的诊断工具： #+begin_src shell DISPLAY=:0 fcitx-diagnose #+end_src 诊断结果暴露了大量问题，下面列出关键部分并逐一说明。 *** Fcitx 状态：DBus 通信断裂 #+begin_example # Fcitx State: 4. `fcitx-remote`: **Cannot connect to fcitx correctly.** 5. DBus interface: **Cannot find DBus name `org.fcitx.Fcitx` owner.** **Cannot find pid of DBus name `org.fcitx.Fcitx` owner.** #+end_example =fcitx-remote= 无法连接 =fcitx= ，DBus 总线上也找不到 =org.fcitx.Fcitx= 这个服务名。这意味着 =fcitx= 虽然进程在跑，但它 *没有成功注册到会话总线* 。 #+BEGIN_QUOTE *小知识：什么是 DBus？* DBus 是 Linux 桌面环境中的 *进程间通信* （IPC）机制。你可以把它想象成一个"内部公告栏"：各个程序在上面发布自己的服务，其他程序通过公告栏找到并调用这些服务。 对 =fcitx= 来说，DBus 的作用包括： - 输入法切换通知（从中文切到英文） - 输入法状态查询（当前是中文还是英文模式？） - 配置变更同步（修改了快捷键后立即生效） 如果 DBus 通信断了，这些操作要么失败，要么阻塞等待超时。 #+END_QUOTE 更进一步，检查进程列表发现 =fcitx= 启动了一个 *私有的 dbus-daemon= ： #+begin_example lujun9972 27481 /usr/bin/dbus-daemon --syslog --fork ... \ --config-file /usr/share/fcitx/dbus/daemon.conf #+end_example 正常情况下， =fcitx= 应该使用桌面会话的 DBus（ =/run/user/1000/bus= ），但它退而求其次启动了自己的私有 DBus 实例。这说明 =fcitx= 启动时会话总线不可用（或者地址不对）。私有总线意味着其他应用无法通过标准 DBus 接口与 =fcitx= 通信，输入法切换、状态同步等功能全部受影响。 *** 前端模块：环境变量缺失 #+begin_example # Frontends setup: ## Xim: 1. `${XMODIFIERS}`: **XMODIFIERS is not set** ## Qt: 1. qt4 - `${QT4_IM_MODULE}`: **Please set environment variable QT4_IM_MODULE ...** 2. qt5 - `${QT_IM_MODULE}`: **Please set environment variable QT_IM_MODULE ...** ## Gtk: 1. gtk - `${GTK_IM_MODULE}`: **Please set environment variable GTK_IM_MODULE ...** #+end_example 三个关键环境变量（ =XMODIFIERS= 、 =QT_IM_MODULE= 、 =GTK_IM_MODULE= ）全部未设置。不过这一条有 *误导性* ——我检查了 =~/.xinitrc= ，里面确实有设置这些变量，只是 =fcitx-diagnose= 运行所在的 shell 环境没继承到 X 会话的环境变量。所以这个问题的严重程度需要打个问号。 #+BEGIN_QUOTE *小知识：为什么需要三个环境变量？* - =XMODIFIERS=@im=fcitx= ：告诉 *所有 X11 应用* 通过 XIM 协议连接输入法服务器。这是最底层的兼容方案，几乎所有 X 应用都支持。 - =GTK_IM_MODULE=fcitx= ：让 *GTK 应用* 使用专门的 fcitx IM 模块，比 XIM 性能更好、体验更流畅（支持光标跟随、预编辑等）。 - =QT_IM_MODULE=fcitx= ：同理，让 *Qt 应用* 使用专门的 fcitx IM 模块。 三个变量的作用范围不同但互补： =XMODIFIERS= 是兜底方案， =GTK_IM_MODULE= 和 =QT_IM_MODULE= 是针对特定框架的优化方案。 #+END_QUOTE *** crash.log：BadWindow 错误 #+begin_example 3. `~/.config/fcitx/log/crash.log`: fcitx: BadWindow (invalid Window parameter) #+end_example =crash.log= 中记录了一次 =BadWindow= 错误。这是 X11 协议中的经典错误，表示 =fcitx= 尝试操作一个不存在或已销毁的窗口。这通常发生在窗口关闭时 =fcitx= 还没来得及清理对该窗口的引用。虽然未必直接导致卡顿，但说明 =fcitx= 的窗口管理与 X 服务器的状态存在不同步。 *** 配置工具：GTK2 模块缺失 #+begin_example # Fcitx Configure UI: 2. Config GUI for gtk2: **Config GUI for gtk2 not found.** ... ## Gtk: 1. gtk - gtk-query-immodules: **Failed to find fcitx in the output of `/usr/bin/gtk-query-immodules-2.0`** **Cannot find fcitx im module for gtk 2.** #+end_example GTK2 的 fcitx 输入法模块缺失。这在 2026 年影响不大——GTK2 应用已经很少见了，而且如果 =XMODIFIERS= 设置正确，GTK2 应用仍可通过 XIM 协议使用输入法。 *** Locale 警告 #+begin_example 3. XIM for Emacs: **Your LC_CTYPE is set to en_US.UTF-8 instead of one of zh, ja, ko. You may not be able to use input method in emacs because of an really old emacs bug that upstream refuse to fix for years.** #+end_example 这是一个 Emacs 的古老 bug ：当 =LC_CTYPE= 不是中日韩 locale 时，Emacs 的 XIM 输入可能不工作。对我来说影响不大，因为我用的是 Emacs 内置的输入法支持，不走 XIM 。 ** 第二步：发现键盘设备被禁用 =fcitx-diagnose= 虽然暴露了很多问题，但没有一个能直接解释"为什么键盘卡"。我需要换个角度思考： - *键盘卡，鼠标没事* → 两种设备的处理路径不同 - 在 X11 中，键盘和鼠标是 *独立的设备* ，各有各的事件传递管道 - 如果 =fcitx= 只干扰了键盘的管道而没有干扰鼠标的，那问题一定出在键盘设备的 *X 层面配置* 上 所以我用 =xinput= （X Input 扩展的命令行工具）来检查 X11 是怎么看待键盘设备的： #+begin_src shell DISPLAY=:0 xinput list-props "AT Translated Set 2 keyboard" #+end_src 输出中有一行： #+begin_example Device Enabled (176): 0 #+end_example =Device Enabled= 是 *0* ！物理键盘在 X 层面被 *禁用* 了！ 再看设备列表： #+begin_src shell DISPLAY=:0 xinput list #+end_src #+begin_example ⎡ Virtual core pointer id=2 [master pointer (3)] ⎜ ↳ Virtual core XTEST pointer id=4 [slave pointer (2)] ⎣ Virtual core keyboard id=3 [master keyboard (2)] ↳ Virtual core XTEST keyboard id=5 [slave keyboard (3)] ∼ AT Translated Set 2 keyboard id=10 [floating slave] ∼ ThinkPad Extra Buttons id=13 [floating slave] ... #+end_example 物理键盘前面的符号是 =~= （tilde），表示它是 *floating slave* ——一个浮动的、没有挂载到任何 master 设备上的从设备。正常情况下，物理键盘应该是 =↳= （attached slave），挂载在 master keyboard 下面。 #+BEGIN_QUOTE *小知识：X11 的输入设备层级* X11 的输入设备分为三层： 1. *Master 设备* ：虚拟的核心设备（master keyboard + master pointer），是应用程序看到的"键盘"和"鼠标" 2. *Slave 设备* ：物理设备，attach 到 master 上，通过 master 将事件传递给应用程序 3. *Floating slave* ：物理设备但 *没有* attach 到任何 master，事件走另一条路径 当物理键盘变成 floating slave 且被禁用时，键盘事件只能通过更慢的回退路径（如 XIM 或 XKB 扩展）传递，这就是输入卡顿的原因。 #+END_QUOTE ** 第三步：临时修复——重新启用键盘 我尝试了两个操作： #+begin_src shell # 将键盘重新挂载到 master keyboard DISPLAY=:0 xinput reattach 10 3 # 重新启用键盘设备 DISPLAY=:0 xinput enable "AT Translated Set 2 keyboard" #+end_src 执行后确认： #+begin_example Device Enabled (176): 1 #+end_example 键盘恢复了正常。这证实了： *键盘被禁用和分离就是卡顿的直接原因* 。 ** 第四步：定位根因——fcitx-xkb 插件 为什么键盘会被禁用？回到 =fcitx-diagnose= 的输出，我注意到 =fcitx= 加载了大量插件： #+begin_example Found 36 enabled addons: fcitx-xkb fcitx-xkbdbus fcitx-x11 fcitx-xim ... #+end_example 其中 =fcitx-xkb= 和 =fcitx-xkbdbus= 这两个插件引起了我的注意。 =fcitx-xkb= 的功能是接管 X 的键盘布局管理（XKB），当它启动时会： 1. 接管 XKB 布局控制权 2. 通过自己的管道处理键盘事件 它是怎么把物理键盘搞成 disabled + floating 的？我没有在源码中逐行确认，但推理链条很清楚： - =fcitx-xkb= 启动前：键盘正常（ =Device Enabled = 1= ，attached slave ） - =fcitx-xkb= 启动后：键盘被禁用且分离 - 停止 =fcitx= 后手动 =xinput enable= + =reattach= ：键盘恢复正常 - 鼠标设备完全不受影响（ =fcitx-xkb= 只管键盘布局，不管鼠标） 三个事实指向同一个结论： *=fcitx-xkb= 在接管键盘布局时，错误地禁用并分离了物理键盘设备* 。 而鼠标走的是完全独立的 XInput 路径，不受 XKB 插件影响。这完美解释了" *键盘卡而鼠标没事* "的现象。 同时，诊断还发现了 DBus 通信问题： #+begin_example Cannot connect to fcitx correctly. Cannot find DBus name org.fcitx.Fcitx owner. #+end_example =fcitx-remote= 也无法连接 =fcitx= ，说明 DBus 通信链路是断的。 =fcitx-xkbdbus= 插件需要通过 DBus 传递键盘状态，如果 DBus 通信断了，每次按键都可能在等待一个永远不会到来的 DBus 响应，进一步加剧延迟。 *** 根因链条 #+begin_example fcitx4 启动 → fcitx-xkb 插件接管 X 键盘布局 → 禁用/分离物理键盘设备 → 键盘事件走慢速回退路径 → 再叠加 DBus 通信断裂 → 每次按键都卡 #+end_example * 解决方案 我选择了升级到 =fcitx5= ，因为 =fcitx4= 太老了（4.2.9.9），它的 XKB 集成有 bug。 =fcitx5= 已经完全重写了 XKB 管理模块，不会有这个问题。 不过，如果你暂时不想升级，也有两个轻量的替代方案： 1. *禁用 fcitx-xkb 插件* ：在 =~/.config/fcitx/conf/= 中创建 =fcitx-xkb.conf= ，设置 =Enabled=False= ，然后重启 =fcitx= 。代价是失去通过 =fcitx= 管理键盘布局的能力（如果你只用英文布局，无影响）。 2. *在 .xinitrc 中加修复命令* ：在 =fcitx= 启动之后加一行 =xinput enable "AT Translated Set 2 keyboard"= ，强制重新启用键盘。 ** 升级到 fcitx5 #+begin_src shell # 移除 fcitx4 所有包 sudo pacman -Rns fcitx fcitx-configtool fcitx-googlepinyin \ fcitx-mozc fcitx-qt4 fcitx-qt5 fcitx-qt6 fcitx-rime \ fcitx-sogoupinyin fcitx-sunpinyin #+end_src #+begin_src shell # 安装 fcitx5 全家桶 sudo pacman -S fcitx5 fcitx5-configtool fcitx5-gtk fcitx5-qt \ fcitx5-chinese-addons fcitx5-mozc fcitx5-rime fcitx5-pinyin-zhwiki #+end_src ** 更新环境变量 =fcitx4= 和 =fcitx5= 的环境变量值不同，需要修改 =~/.xinitrc= ： #+begin_example # 旧的 (fcitx4) export GTK_IM_MODULE=fcitx export QT_IM_MODULE=fcitx export XMODIFIERS="@im=fcitx" # 新的 (fcitx5) export GTK_IM_MODULE=fcitx5 export QT_IM_MODULE=fcitx5 export XMODIFIERS="@im=fcitx5" #+end_example #+BEGIN_QUOTE *小知识：为什么环境变量值要改？* =GTK_IM_MODULE= 和 =QT_IM_MODULE= 告诉 GTK/Qt 应用加载哪个输入法模块。 =fcitx= 和 =fcitx5= 是两套独立的 IM 模块共享库，名字不同。如果环境变量还指向 =fcitx= ，应用会尝试加载一个已经不存在的 =im-fcitx.so= ，结果就是找不到输入法。 #+END_QUOTE 升级后重新登录 X 会话，一切正常，键盘输入丝般顺滑。 * 输入法对照表 升级过程中，输入法引擎也需要对应替换： | fcitx4 包 | fcitx5 包 | 说明 | |-----------------------+--------------------------+------------------| | =fcitx= | =fcitx5= | 核心框架 | | =fcitx-configtool= | =fcitx5-configtool= | 图形配置工具 | | =fcitx-sunpinyin= | =fcitx5-chinese-addons= | 拼音（内置更优） | | =fcitx-sogoupinyin= | =fcitx5-chinese-addons= | 拼音（内置更优） | | =fcitx-googlepinyin= | =fcitx5-chinese-addons= | 拼音（内置更优） | | =fcitx-mozc= | =fcitx5-mozc= | 日文输入 | | =fcitx-rime= | =fcitx5-rime= | Rime 输入 | | =fcitx-qt5/6= | =fcitx5-qt= | Qt IM 模块 | | （无） | =fcitx5-gtk= | GTK IM 模块 | | （无） | =fcitx5-pinyin-zhwiki= | 维基百科词库 | 值得一提的是， =fcitx-sogoupinyin= （搜狗拼音）没有 fcitx5 版本，但 =fcitx5-chinese-addons= 内置的拼音引擎带云拼音功能，体验不逊于搜狗。 * 复盘 ** 排查思路 这次排查的关键转折点是用 =xinput list-props= 检查物理键盘的状态。如果只停留在" =fcitx= 导致卡顿"的表面，可能会一直猜测是 =fcitx= 性能问题，而不会发现真正的原因是 =X11= 层面的设备被禁用了。 整个排查过程遵循了一个核心原则： *先找根因，再动手修* 。 #+begin_example 现象：键盘输入卡顿 │ ├─ 1. fcitx-diagnose 收集信息 │ → 发现 DBus 断裂、环境变量缺失等多个异常 │ ├─ 2. xinput list-props 检查键盘设备 │ → Device Enabled = 0，键盘被禁用！ │ ├─ 3. xinput list 看设备拓扑 │ → 物理键盘是 floating slave，未挂载到 master │ ├─ 4. xinput enable + reattach 临时修复 │ → 卡顿消失，确认根因 │ └─ 5. 定位 fcitx-xkb 插件为罪魁祸首 → 升级到 fcitx5 彻底解决 #+end_example ** 经验教训 1. *=xinput= 是排查 X11 键盘/鼠标问题的利器* ： =xinput list= 看设备拓扑， =xinput list-props= 看设备属性， =xinput enable/disable= 控制设备开关 2. *输入法问题不一定在输入法层面* ：这次表面是 =fcitx= 的锅，实际上是 =fcitx= 的 XKB 插件把 X11 的设备搞乱了，根因在 X 输入子系统 3. *老软件就该升级* ： =fcitx4= 已经停止维护， =fcitx5= 不仅修复了这类 bug ，架构也更现代。在 Arch Linux 这种滚动更新的发行版上，抱着旧版本不放只会积累技术债

盖世汽车讯 福特汽车公司正对其电动化路径进行战略调整，强调向增程式电动车（Extended-Range Electric Vehicle，EREV）转型并非对纯电路线的退让，而是基于客户需求的主动选择。福特Blue与Ford Model e总裁安德鲁·弗里克（Andrew Frick）在4月15日的“Daily Drive”播客中表示，该策略旨在结合纯电驾驶体验与燃油备用动力，以满足皮卡用户在拖拽和载重等高强度使用场景下的实际需求。

图片来源：福特

弗里克指出，第一代F-150 Lightning的市场反馈显示，许多消费者期望纯电动车具备传统燃油皮卡的性能表现，但其在负载状态下的续航能力和工作性能与现实中的电动车限制存在差距。他强调，F-150 Lightning并未“失败”，其销量未达预期主要反映的是整体市场对电动车的接受速度慢于预期以及价格敏感度上升，而非产品本身存在缺陷。

此外，弗里克为福特采用预订和定金系统进行辩护，称尽管该机制并不完美，但在Maverick、Bronco和Mach-E等车型上提供了有效的市场需求信号。他表示，福特未来将根据具体产品和细分市场继续灵活运用此类机制。展望未来，福特将优先考虑车辆的可负担性与使用场景适配性，计划推出一款售价约3万美元的中型电动皮卡。

与此同时，福特确认将在2029年前完成其产品线的大规模更新。根据公司官方声明，届时福特将在北美市场更新占销量80%的车型阵容，并在全球范围内更新70%的销量主力产品。这一计划包括第十五代F-150全尺寸皮卡及其重型版本F-Series Super Duty，预计两款新车将于2028年左右亮相。此前，福特曾在2025年2月表示新一代F-150将于2027年发布，但目前已调整时间表。

值得注意的是，福特已放弃原计划中的全尺寸纯电F-150车型，但保留了“Lightning”名称，并将其用于即将推出的EREV混合动力版本。该版本的具体细节尚未公布。

在平台技术方面，福特正推进名为UEV的新一代整车平台开发。该平台采用高压压铸技术，有助于简化车身结构并减轻重量，同时支持更高效的电驱动系统和先进驾驶辅助功能。福特计划基于UEV平台于2029年推出一款中型皮卡，并将该平台扩展至未来的混合动力车型生产。

销售数据显示，F-Series皮卡近年销量略有下滑。2025年全年在美国市场售出828,842辆，同比下降0.7%；2026年第一季度销量为159,901辆，同比减少16%。当前第十四代F-150于2020年首发，并在2023年9月经历中期改款。面对雪佛兰计划于2026年内推出新一代Silverado 1500的竞争压力，福特F-150的市场地位或将面临进一步挑战。

弗里克还提到，福特正积极管理供应链中断和关税风险，受益于其在美国本土的强大制造能力，并采取主动召回策略以持续提升产品质量和客户信任。

盖世汽车讯 现代汽车近日在米兰设计周期间正式发布IONIQ 3纯电紧凑型掀背车，该车型专为欧洲市场打造，基于E-GMP 400伏架构开发，提供两种电池配置，并搭载品牌最新Pleos Connect信息娱乐系统。

IONIQ 3是现代IONIQ系列首款紧凑级纯电动车，定位低于IONIQ 5。该车提供42.2千瓦时和61.0千瓦时两种电池选项，在欧洲WLTP测试标准下分别可实现最高344公里（213英里）和496公里（308英里）的续航里程。其中标准续航版配备最大输出147马力（约107.8千瓦）的前置单电机，长续航版则为135马力，两者的峰值扭矩均为250牛·米（184磅·英尺）。标准续航版0至100公里/小时加速时间为9.0秒，长续航版为9.6秒，最高车速均被限制在169公里/小时（105英里/小时）。

IONIQ 3采用现代全新“钢之艺术”（Art of Steel）设计语言，车身长度为4,155毫米，宽1,800毫米，高1,505毫米，轴距2,680毫米，整体尺寸小于Genesis GV60、大众ID.3及2027款雪佛兰Bolt EV。其风阻系数为0.263，并采用“空气动力学掀背”（Aero Hatch）造型，前脸配有代表字母“H”的摩尔斯电码四点式灯组。

车内方面，IONIQ 3是现代在欧洲首款搭载Pleos Connect信息娱乐系统的车型，该系统基于Android Automotive OS开发，配备12.9英寸或14.6英寸中控屏，支持导航、互联及车辆功能控制。尽管现代此前展示的Pleos系统取消了物理按键，但IONIQ 3在屏幕下方保留了一排实体按钮，用于调节座椅加热、温度、风量、空调模式及音量。

该车行李厢容积为443升（15.6立方英尺），其中包括位于后备厢地板下方的“Megabox”储物格（119升，4.2立方英尺）。其他可选配置包括Bose高级音响系统、双区自动空调和LED氛围灯。智能驾驶辅助方面，IONIQ 3配备现代SmartSense系统，包含高速公路驾驶辅助2（HDA2）、远程智能泊车辅助（RSPA）、记忆倒车辅助（MRA）、环视监控（SVM）和盲区视图监控（BVM）等功能。

IONIQ 3由现代汽车欧洲团队设计，并在现代汽车土耳其伊兹密特工厂生产。官方尚未公布具体售价，但预计起售价约为25,000英镑（约合33,500美元）。现代表示，该车型旨在满足日常实用需求，结合细分市场领先的续航、空气动力学效率以及空间实用性。

现代汽车明确表示，IONIQ 3目前无计划引入美国市场，部分原因包括美国对进口电动车征收的关税政策，以及当地消费者更偏好SUV和皮卡车型。不过有分析指出，其姊妹品牌起亚未来可能推出类似规格的车型进入北美市场，但续航表现或将有所降低。

现代此次推出IONIQ 3，意在欧洲竞争激烈的紧凑型纯电市场中争取份额，该细分市场正面临雷诺等传统品牌及中国车企的价格压力。

盖世汽车讯 2026年3月，欧洲14个主要欧盟及欧洲自由贸易联盟（EFTA）国家的纯电动车（BEV）注册量同比增长51%。根据New Automotive与E-Mobility Europe发布的最新数据，当月新增注册纯电动车超过22.4万辆，占上述市场新车总销量的22%，在全欧盟范围内的占比估计为21.2%。

这一增长正值中东冲突再度引发对欧洲进口石油依赖问题的关注之际。数据显示，电动车的普及已不仅关乎气候目标或使用成本，更日益与能源安全紧密关联。

图片来源：特斯拉

2026年第一季度，欧盟国家累计注册纯电动车逾50万辆，较2025年同期增长33.5%。E-Mobility Europe秘书长克里斯·赫伦（Chris Heron）表示：“3月电动车销量的激增是欧洲近期在能源安全方面取得的最大进展之一。在石油依赖已成为现实脆弱点的背景下，欧盟主要市场的电动车销量增速均超过40%，这标志着明确的结构性转变，而非统计波动。今年迄今注册的50万辆电动车，每年可减少约200万桶石油需求。”

增长并非仅由个别国家拉动，而是遍及欧洲所有主要市场。德国、法国、西班牙、意大利和波兰——欧洲五大经济体——2026年至今的纯电动车注册量同比增幅均超过40%。

其中，意大利表现尤为突出。截至2025年底，其电动车市场份额约为5%，到2026年3月已升至8.6%，年初至今注册量同比增长65%。德国在新激励政策推动下明显反弹，3月每4辆新车中就有1辆为纯电动车，带动年初至今销量增长42%。法国在大型市场中继续保持领先，3月电动车占新车销量的28%，其社会租赁计划推动年初至今销量增长近50%。

北欧国家仍大幅领先。丹麦3月新车销量中76.6%为纯电动车，芬兰接近50%。挪威继续位居全球首位，3月新车注册中98.4%为纯电动车。

New Automotive首席执行官本·内尔姆斯（Ben Nelmes）指出：“每注册一辆电动车，欧洲对进口石油的依赖就减少一分。在能源安全已上升为政治议程首要议题的当下，电动车转型正带来切实且可衡量的韧性。我们目前在主要欧洲市场——包括起步较慢的意大利和波兰——所看到的变化速度，表明转型已进入新阶段。”

值得注意的是，当前这一转变已在中东局势对数据产生全面影响前显现。消费者和车队采购行为正在加速，若该趋势持续，欧洲电动车转型步伐有望在2026年进一步加快。

盖世汽车讯 福特汽车公司近日公布了2026款Mustang Dark Horse SC的动力参数。该车型将搭载一台机械增压5.2升V8发动机，最大输出功率为795马力，峰值扭矩为660磅-英尺（约合895牛·米）。这一动力水平高于此前Shelby GT500的760马力，但低于Mustang GTD的815马力。

Mustang Dark Horse SC旨在填补Shelby GT500停产后留下的市场空白。其搭载的这台代号为“Predator”（掠食者）的发动机，与上一代Shelby GT500及Mustang GTD所用发动机相同。相比之下，标准版Mustang Dark Horse的最大功率为500马力，峰值扭矩为418磅-英尺（约合567牛·米）。

尽管Mustang Dark Horse SC的发布时间晚于Mustang GTD，但福特表示，该车型实际上是与Mustang GTD以及Mustang GT3赛车同步开发的。福特赛车全球总监马克·拉什布鲁克（Mark Rushbrook）表示：“将Mustang Dark Horse SC与Mustang GTD及我们的Mustang GT3赛车同步开发，使我们能够建立一条直接的创新通道。我们的目标是将最严苛耐力赛事中获得的技术转移和经验教训直接应用于量产公路车，让客户真正体验到我们赛车团队在赛道上的感受。”

该车型起售价为108,485美元，若选装Track Pack套件，价格将升至144,985美元。目前订单已开放，首批交付预计将于今年夏季开始。