脚本、热更新与逻辑扩展

Category

system / 脚本与热更子树总览。覆盖：脚本层定位（01）、宿主 VM 集成（02）、配置驱动与脚本驱动（03）、热更新体系（04）。

Definition

项目一旦进入长期运营，最贵的问题往往不再是“某个功能做不出来”，而是“明明知道问题在哪，却改不动、发不出、止不住损”。脚本层、热更新、配置驱动和宿主运行时之所以总会被反复讨论，不是因为它们听起来灵活，而是因为它们共同决定了项目后期的迭代速度、修复窗口和事故半径。

很多团队第一次引入这套能力时，想象的是“更灵活”“修得更快”。但真正上线以后，立刻会碰到另一面：

• 哪些逻辑适合脚本化，哪些逻辑一旦脚本化就难以治理
• 配置和脚本各自适合表达什么，不适合表达什么
• VM 和宿主引擎之间的边界怎么画，性能和调试怎么兜
• 热更新到底是在缩短修复链路，还是在扩大线上事故入口

这一章不是在推销某种技术方案，而是把“逻辑扩展能力”当成一套正式的运行时和发布机制来看。重点不在于它能不能做，而在于它会把复杂度引到哪里，哪些收益是真收益，哪些灵活性是在用治理成本换。

Related

关系链：脚本层定位（01）→ 宿主集成（02）→ 驱动分界（03）→ 热更体系（04）。上游：runtime 子树（宿主运行时）；下游：production/03（灰度回滚）、production/05（配置管线）、树根 系统总览。

Reference

节点清单见下节。

本章文章

• 脚本层定位与语言选择：先回答脚本层到底应该承担什么，避免把“灵活”变成“没有边界”。
• 宿主运行时与脚本 VM 集成：讨论脚本 VM 接进宿主以后，绑定、生命周期、调试和性能问题为什么会一起出现。
• 配置驱动与脚本驱动：解释配置和脚本分别适合承载什么变化，为什么两者不能互相替代。
• 热更新体系：把补丁、签名、灰度、兼容、回滚和事故控制放回同一条发布链路里讨论。