ARTICLE · 1093916
官方文档都写明白了,为什么团队还是选择“有问题再说”?
当官方已经把平台构建边界写得足够清楚，最无奈的不是没有方案，而是方案已经给出，仍然没人愿意执行。
前言
最近在处理 Flutter 打包相关的事情时，碰到了一场让我很困惑的技术讨论。
依据 Flutter for OpenHarmony 项目说明中的建议：OHOS 平台使用鸿蒙侧维护的 Flutter 版本产物进行编译，其他平台使用 Flutter 上游社区版本产物进行编译。
这句话的意思其实很明确：业务代码可以共用，但不同平台的构建工具链不必强行相同。
最开始，大家担心的是“两套打包方式”会带来额外负担。这个担心我能理解，所以我并没有要求每个人自己维护两套环境、记两套命令，更没有要求 iOS 也必须照着我的方式做。我已经给出了统一使用方式的落地方案：对日常使用者保持统一入口，把按平台选择 SDK 的差异收在方案内部。
可方案给出来之后，阻力仍然存在。有人就是不愿意接受按平台分 SDK，最终技术负责人也接受了“现在没问题，有问题再说”的方向。
这篇随笔不想评价谁的能力，只想把这件事背后的工程逻辑和执行者的无奈说清楚。
一、文档写的是“建议”，但不是一句可以忽略的客套话
从项目说明截图可以看到，Flutter for OpenHarmony 对构建方式给出了明确建议：OHOS 平台使用其适配产物，其他平台使用 Flutter 社区版本产物。
“建议”当然不等于项目必须机械执行。团队可以根据人力、交付周期、历史工程和验证结果做取舍。
但如果决定偏离推荐路径，至少应当回答三个问题：
为什么当前项目不采用推荐方案；
不采用后可能失去什么兼容性与排查能力；
当风险真正出现时，谁负责验证、处理和回退。
否则，“一套 SDK 现在能跑”只是一种现状描述，不是一份长期可维护的工程结论。
二、两套 SDK，不等于两套业务代码
抵制“两套打包方式”时，最常见的误解是：两套 SDK 等于两套业务代码、两套页面、两套功能。
其实并不是。
Flutter 的 Dart 业务逻辑、页面、状态管理和大部分通用组件，依然可以共享。真正按平台区分的，是 SDK、引擎实现、构建脚本、平台插件和最终编译产物。
更准确地说，这不是“维护两个产品”，而是：
OHOS 打包时，使用已适配 OHOS 平台的 Flutter 工具链；
Android、iOS 等其他平台打包时，使用 Flutter 上游社区工具链；
业务层尽量共用，平台构建层明确分流。
我关注的是自己负责的 Android 构建边界，并没有要求 iOS 也必须按同一种方式调整。官方文档要求的是按平台选择对应 SDK，不是让团队复制两份业务工程。
三、统一方式已经给了，真正被拒绝的不是复杂度
如果担心不同 SDK 会让日常使用变复杂，解决方式并不是假装平台差异不存在。
我已经给出的方案，是让使用方保持一个统一入口：日常打包依旧按同一种方式发起，内部再依据目标平台选择对应 SDK。这样做的目的，是把差异收拢在构建方案里，而不是把差异丢给每个开发同学。
它至少解决了几个现实问题：
不需要每个人手动维护和记忆两套日常操作；
不需要为了不同 SDK 复制两份业务代码；
平台 SDK、版本和依赖边界可以明确记录；
出现问题时，知道应该沿哪条工具链定位与回退。
所以，讨论走到这里，已经不再是“有没有统一方案”的问题。
统一方式已经给了，仍然不愿意采用分 SDK 的构建边界，说明真正被拒绝的不是操作复杂度，而是“平台确实需要不同 SDK”这个事实本身。
四、“现在没问题”，不能替代责任边界
讨论中，有人认为 SDK 一旦选定，除非有重大技术调整或严重问题，否则可能一两年都不会切换版本；既然当前能正常打包，为什么还要折腾？
这是一种现实考虑，但它仍然没有回答最关键的问题：如果未来 Android 因 SDK 兼容性出现问题，谁来负责解决？如果 OHOS 侧的适配发生变化，又该从哪条工具链开始排查？
“当前没有问题”最多只能说明当前环境下能正常构建，不能自动证明未来版本升级、插件更新、平台变化之后仍然没有问题。
更何况，文档推荐路径本身已经摆在那里。选择不按推荐路径走，不是不能，但必须有人愿意为这个选择的验证、处理和回退负责。
五、方案已经给了，为什么还是不肯执行？
另一段沟通里，分歧说得更直接。
我反复强调：这不是我主观要求维护两套业务代码，也不是要求所有平台都跟着我改；官方文档明确要求不同平台使用对应产物，而我已经提供了统一使用方式的方案。
对方的顾虑是，团队现在同时做多个平台，单独为 Android 走一套 SDK，如何保证其他同学开发的功能也正常。
这个顾虑本身可以讨论，也应该通过构建验证来解决。但它不能成为直接忽略官方建议和既有方案的理由。
因为方案的核心不是“让 Android 单独变成另一套项目”，而是让不同平台在共享业务代码的前提下，各自走官方建议的构建链路。真正需要验证的是兼容范围，而不是把平台差异一概当成不该存在。
最让我困惑的是：统一方案已经给出，官方建议也很明确，最后大家仍然更愿意保留一套 SDK，等问题真的发生再处理。
六、技术负责人可以做取舍，但“有问题再说”不该是终点
技术负责人当然可以在交付周期、人力和历史成本之间做取舍。
但当技术负责人最终接受“现在没有问题就先不动，有问题再说”时，这就不再只是一次普通讨论，而是一项团队决策：原本可以前置验证和记录的风险，被明确留给未来处理。
这项决定至少应该同步留下这些内容：
与官方推荐方案相比，当前方案差异在哪里；
已做过哪些验证，哪些风险尚未验证；
出现兼容性问题后，谁负责定位、处理与回退；
哪些变化会触发重新评估；
为什么拒绝已经给出的统一入口方案。
“有问题再说”如果要成立，至少应该翻译成：问题由谁处理、什么情况触发处理、如何证明问题已经解决。
否则，它只是把不确定性留给未来真正负责打包、发版和排查的人。
写在最后
做技术的人，大概都经历过这种时刻：文档看了，建议查了，风险说了，统一方案也给了；最后却发现，方案能不能落地，未必只取决于技术本身。
这件事从来不是“要不要写两套业务代码”，也不是我要求大家凭空增加工作量。
它真正的问题是：当平台维护方已经明确给出不同的构建建议，且统一使用方式已经给出后，团队仍选择不执行，并把答案留给未来的故障。
作为具体执行的人，未必总能决定最终方向。但至少可以把文档依据、已有方案、风险边界和未被采纳的理由记录下来。
因为风险被推迟，不代表风险消失；方案被拒绝，也不代表一开始没有人把路指出来。