多工程共享栈升级策略

共享栈是把双刃剑：升级一次全组受益，也升级一次全组冒险。这篇讲多工程共享栈的升级策略，Air 系列十几个工程共栈的实操总结。

▍升级的触发与规划
触发源：安全修复（最优先）、框架新版本需要、上游应用要求的最低版本。规划期先摸清波及面：哪些工程用这个栈、各自用了哪些模块、有没有依赖旧行为的补丁。波及面清单决定升级窗口（错开各工程的发布期）。

▍四步迁移法
第一步，切源：构建脚本指向新栈。这只是开始。第二步，重编自有二进制：工程自己的 Qt 依赖库必须对新栈重新编译——真实坑：资源编译器生成的代码引用新栈已不存在的特性符号，链接才报错；更隐蔽的是版本化符号缺失在运行时才炸。检测手段：列出自产 so 的未定义符号，对照新栈的符号表核对。第三步，清理预载表：启动期的库预载清单对照新闭包清理，残留已删库名会让初始化静默中断（症状是纯黑或卡加载，无报错）。第四步，装机冒烟：防伪判定用三件套——截图字节量（大于阈值才算非黑屏）、前台归属确认（应用真的在前台）、CPU 增量（初始化真的跑了）。构建成功安装成功都不算数。

▍存量二进制的救活三术
不是所有二进制都能立刻重编（第三方预编译件）。按序选：等长符号手术（对旧 so 的符号引用做原位替换，走替代路径）、借件（从旧栈把裁掉的模块分发过来、配私有头文件副本与链接层）、垫片（版本化符号的转发层）、最后才是全量重编。

▍灰度与观察
升级后的第一个版本给观察期：崩溃率、启动成功率、关键路径埋点对比。观察期内不叠加大改（变量隔离）。

▍纪律红线
栈内库不就地改（专属需求 fork 独立前缀）；升级全程脚本化可重放；新旧栈共存期缩短（并存越久漂移越大）。

▍一句话
共享栈升级是工程项目，不是编译任务：波及面、四步法、防伪验证、观察期，四件套齐了才动手。

有疑问欢迎在本板块直接发帖，我们会逐条回复。