跨平台移动开发已不再是遥不可及的目标。银行、保险公司及类似产品机构将多平台应用作为常规要求，而非实验室实验。最昂贵的错误是选择适合某场会议演讲的技术栈，而不是基于你的客户组合、国家覆盖范围和现有工程重心。Flutter 和 Kotlin Multiplatform 在 2026 年都能交付真实产品。它们解决不同的问题。只有在明确 Android、iOS 和 Web 是否为对等角色，或者 Android 是否为核心且 iOS 群体虽有意义但规模较小之后，才能将它们视为替代方案。
决策首先是组织层面的，其次才是技术层面的。一个需要手机和浏览器上外观完全一致的绿色消费钱包应用，与一个已在 Android 上运行 Kotlin 且需将逻辑扩展到 iOS 而无需新建 Dart 资产的大型零售产品，是完全不同的问题。地理因素也很重要。亚洲大部分地区以及许多大型零售银行客户群以 Android 为主。香港、新加坡、英国和美国部分地区则倾向于 iOS 和 Android 更均衡的组合，Web 往往是重要的获客和服务渠道。请使用你自己的业务数据，而非全球平均值。
2026 年各方案的实际含义
Flutter 是一个单一 UI 的跨平台工具包。你使用 Dart 编写，交付一种交互模型，并让 Flutter 引擎绘制像素。在 iOS 以及 Android API 29 及以上版本中，Impeller 是默认渲染引擎，着色器提前编译以消除旧有的着色器卡顿路径。同一个产品界面可以从单一代码库同时支持 Android、iOS、Web 和桌面。这就是诚实的定位：一个团队，一个设计系统，多个目标。
Kotlin Multiplatform（KMP）并不是“用 Kotlin 实现的 Flutter”。JetBrains 在 2023 年 11 月的 Kotlin 1.9.20 中宣布 KMP 核心稳定且可用于生产。Google 将 KMP 文档化为支持在 Android 和 iOS 之间共享业务逻辑。你可以共享领域模型、网络、策略和持久化；UI 可以保持原生（Android 使用 Jetpack Compose，iOS 使用 SwiftUI），也可以转向 Compose Multiplatform（CMP）。CMP 是构建在 KMP 之上的可选 UI 共享层，并非 KMP 的同义词。2025 年 5 月的 Compose Multiplatform 1.8.0 将 Compose for iOS 标记为稳定且可用于生产。这改变了你可以共享多少 UI（如果你选择这么做）。它并不强制你共享 UI，也不默认让 KMP/CMP 的 Web 能力与 Flutter 的 Web 故事对等。
尽早在任何指导委员会中澄清概念。没有 CMP 的 KMP 是共享逻辑加上平台拥有的 UI。带有 CMP 的 KMP 是共享逻辑加上在你选择的地方使用共享的 Compose UI。Flutter 则是单一 Dart 技术栈下的共享 UI 和共享逻辑。这是三种姿态，而非两个 Logo。
Flutter 的优势
Flutter 的优势在于跨目标平台的单一 UI 和交互模型。品牌旅程、 onboarding 漏斗和设计系统组件可以一起迁移。热重载、成熟的工具链以及庞大的绿色产品团队招聘池，使其在无法组建平行原生 UI 团队时极具吸引力。对于需要 Android、iOS 和类似应用的 Web 界面感觉像同一个产品的组织，Flutter 仍然是实现一致品牌体验的最短路径。
当设计系统是定制化的而非“像素级 OS 原生”时，这种一致性最为重要。钱包、营销驱动的获客流程以及视觉独特的消费产品通常希望各处像素完全相同。Flutter 正是为这一理念而生。桌面目标在需要时存在；对银行和保险公司而言，实际收益通常来自一个团队同时实现移动端与 Web 的一致性。
Flutter 的不足或代价
Flutter 并非真正的原生 UI。可访问性、排版和平台习惯需要刻意投入。屏幕阅读器和操作系统约定逐年改善，但它们仍然是一个工程项目，而非 Dart 组件免费附带的特性。深度平台 SDK 集成（OEM 银行 SDK、专有加密模块、特定支付或认证库）需通过平台通道或 FFI 实现。这种摩擦在需要大量设备和供应商集成的企业资产中会显现。
如果组织已是 Kotlin 和 Java 技术栈，Dart 就是一个技能孤岛。应用体积和通道复杂度会随着每一次 awkward 的原生桥接而增长。这些都不是致命问题，但都是真实成本中心，而会议演示往往省略这一点。如果你的合规故事依赖于对生物识别、密钥库和操作系统安全面的直接原生控制，请在庆祝共享组件树之前先计算桥接成本。
KMP 和 Compose Multiplatform 的优势
KMP 允许复用 Kotlin 领域、网络和策略逻辑，而无需在重要地方放弃原生 UI。这对以 Android 为主的团队和已有 Kotlin 代码库来说是非常自然的。Netflix 曾描述通过 KMP 在其 Android 和 iOS 工作室应用中共享平台无关的业务逻辑，同时保留对 Jetpack Compose 和 SwiftUI 的偏好。Cash App 已多年在生产环境中运行 KMP，成为 JetBrains 材料中长期的金融应用案例。请将供应商案例研究视为存在证明，而非你自己的资产也能共享相同代码比例的保证。
当 UI 保持平台拥有时，原生 iOS 和 Android 体验仍然可用。从 2025 年中期开始，CMP 稳定的 iOS 路径允许团队在需要时共享更多 UI，包括逐屏逐步采用，而无需全盘重写。对希望对生物识别、密钥库和操作系统安全 API 保持原生控制的受监管机构而言，KMP 加原生 UI 的姿态通常比全自定义渲染技术栈更容易向安全审查者解释。Google 对 DataStore、Room 和 ViewModel 等库的 Jetpack 多平台支持，进一步减少了“共享模块感觉次等”在 Android 端的反对意见。
KMP 和 CMP 的不足或代价
没有 CMP 时，你仍需为两个 UI 团队或两个 UI 代码库付费。共享逻辑减少了领域层的重复，但不会消除 SwiftUI 和 Compose 的人员配置。使用 CMP 时，iOS 尤其是 Web 的成熟度，以及招聘超出 Android 的 Compose 人才，对某些团队而言仍落后于 Flutter 的单一技术栈开发者体验。JetBrains 自己的 CMP 1.8 说明将 Web 描述为正在演进而非完成：导航和打磨有所改善，但 Compose Multiplatform for Web 并非 Flutter 在一流产品渠道上的对等物。
许多银行无论如何都会将 Web 作为独立的 React 或 Angular 资产。这通常是正确的做法。不要默认认为 KMP 可以取代 Web 产品策略。协调开销依然存在：共享模块、API 合约以及跨平台专家的发布列车。KMP 奖励那些已有 Android 和 iOS 专家且能就合约达成一致的组织。它会惩罚那些希望一个初级团队就能抹除平台差异的组织。
Flutter 的良好适用场景
适用于需要品牌 UI 在 Android、iOS 和 Web 上完全一致的绿色消费应用。小型或中型产品团队如果无法组建平行原生 UI 团队，将从单一交互模型中获得不成比例的价值。在两个移动操作系统以及移动 Web 通常都是首要获客渠道的市场中，单一界面策略更有利。以设计为主导的产品（钱包、onboarding、营销驱动的旅程）而非深度 OEM 集成，是理想场景。
如果你无论如何都要丢弃旧的 Android 应用，且 Web 一致性是未来十二个月的关键路径，即使在原本以 Kotlin 为主的公司中，Flutter 也是一个连贯的选择。代价是建立一个 Dart 资产。收益则是不再假装三个渠道是一个，却按三个渠道来配置人员。
KMP 和 CMP 的良好适用场景
适用于以 Android 优先的组织向 iOS 扩展而无需 Dart 重写的情况。核心银行和高保障移动应用（原生 UI 和平台安全 API 不可妥协）适合共享逻辑模型。已在生产环境中运行的大型 Kotlin 后端和 Android 应用可以逐步共享领域层。主要为 Android 且 iOS 群体虽有意义但规模较小的覆盖范围符合经济性：保护 Android 交付速度，扩展逻辑，保持 iOS UI 原生或选择性使用 CMP。
逐步采用是一个特性，而非妥协。先共享网络和策略。如果设计系统和团队技能支持，再在选定屏幕上添加 CMP。这种顺序一旦你已全面投入 Dart，就很难用 Flutter 伪装。
策略分叉 A：Android、iOS 和 Web 均为首要
当客户群覆盖两个移动操作系统且将移动或桌面 Web 视为真实渠道时，分叉很明确。在 iOS 和 Android 均衡混合的国家和细分市场（常见于香港、新加坡、英国和美国部分地区）加上 Web 驱动的 onboarding，会推动采用单一产品界面。当一个设计系统必须在各处交付且你不会为相同旅程资助单独的 Web 产品栈时，选择 Flutter。
仅在 Web 保持为独立栈且你接受移动端仅使用原生或 CMP UI 时，才选择 KMP。这仍然可能是正确的：许多机构会为公共 Web 保留 React 或 Angular，并使用 KMP 构建已认证的移动应用。不要将这种姿态宣传为“单一跨平台策略”。应将其宣传为移动逻辑共享，同时伴随一个诚实的 Web 资产。失败模式是因幻灯片写了“multiplatform”就承诺 KMP/CMP 能提供类似 Flutter 的 Web 一致性。
策略分叉 B：以 Android 为主，部分 iOS
当客户群和国家以 Android 为主（亚洲大部分地区、许多大型零售银行基础），iOS 群体虽重要但规模较小时，公司内部现有的 Android 和 Kotlin 重心通常会胜出。选择 KMP：保护 Android 交付速度，将逻辑共享到 iOS，保持 iOS UI 原生或选择性使用 CMP。安全和平台团队可继续使用熟悉的 API。招聘仍留在你已在投入的 Kotlin 人才市场内。
如果 Web 一致性比 Android 传承更重要，或者你是在替换而非扩展旧 Android 应用，Flutter 在这里仍可行。判断依据是下一个主要版本是“扩展我们已有的”还是“带有浏览器一致性的新消费界面”。没有 Web 压力的传承指向 KMP。带有 Web 对等角色的绿色品牌界面则指向 Flutter。
CTO 的决策要点
按产品而非口号为组合打分。从客户和国家开始：你真实业务数据中的操作系统份额，而非供应商的全球图表。询问 Web 是对等的 App，还是手册加响应式网站。明确资产情况：是绿色项目，还是打算保留的大型 Kotlin 或 Android 代码库。明确团队形态：是一个跨平台团队，还是不会一夜之间变成 Dart 工程师的 Android 和 iOS 专家。
接下来是合规和设备安全深度。如果平台通道与原生 API 的对比将主导每个发布列车，请诚实地为这种摩擦定价。明确你的 UI 原则：各处像素完全相同，还是原生平台习惯。设定时间范围：十二个月内上线倾向于你团队现在能配置的技术栈；五年平台则倾向于你能长期维持的语言和招聘市场。写下明确的非目标：什么你不会共享（Web、桌面、OEM SDK、可访问性关键屏幕）。模糊的非目标正是 Flutter 项目悄悄放弃 Web、KMP 项目悄悄发明第三个 UI 框架的原因。
立即下一步行动
在产品、移动和安全负责人共同参与的一次工作会议中，按该清单为每个产品打分。只有在决策确实接近时才双向试点一个旅程；否则就选择并配置人员。没有人打算终止的双试点是路线图停滞的原因。将“我们以后可能会添加 Web”冻结为架构决策记录中的明确假设。这一个句子往往比任何功能矩阵都更清晰地决定 Flutter 与 KMP 的选择。
当你的客户组合、国家覆盖范围以及 Kotlin 或 Dart 重心被闲置在白板上时，却执着于框架潮流，这就是机构买错未来五年的方式。Flutter 仍然在需要单一 UI 跨越 Android、iOS 和 Web 时胜出。KMP（搭配可选的 Compose Multiplatform）则在 Android 为核心、原生控制重要且 Web 保持次要或独立时胜出。根据你已有的技术资产来选择。