Skip to content
FEAT

什么时候考虑 Native Image

This content is not available in your language yet.

Native Image 往往很吸引人，因为它意味着更快启动、更低内存和更轻的运行时。
但对大多数项目来说，真正的问题不是“能不能构建”，而是“现在值不值得上”。

先回答：你真的需要 Native 吗

Section titled “先回答：你真的需要 Native 吗”

如果你当前只是：

  • 还在本地开发
  • 刚把 JRE 容器版本跑通
  • 还没形成稳定交付链路

那通常不建议马上切到 Native。
先把 交付一个 Feat Cloud 应用 里的 JRE 路线跑通，成本更低。

Native 更适合这些情况

Section titled “Native 更适合这些情况”
  • 你非常在意启动速度
  • 你运行在资源受限环境
  • 你部署在 Serverless 或弹性伸缩场景

如果这些都不是当前优先级，那 Native 往往不是第一步。

为什么 Feat 对 Native 更友好

Section titled “为什么 Feat 对 Native 更友好”

Feat 的一个重要优势在于：它很多运行逻辑并不是高度依赖运行期反射。
这也是为什么它和 AOT 机制天然关联更紧。

如果你已经看过 AOT 是怎么工作的，这里会更容易理解。
如果还没看过，也没关系，你只需要知道：

  • Feat Cloud 的编译期生成机制，使它比很多传统框架更容易进入 Native 路线

最实用的建议

Section titled “最实用的建议”

不要把 Native 当成“默认部署形态”，而应该把它当成“在 JRE 已经稳定之后再评估的优化路径”。

更合理的顺序通常是：

  1. 先把普通 JRE 版本交付稳定
  2. 再验证 Native 版本是否有明确收益
  3. 最后决定是否把 Native 纳入主交付链路

你真正需要关心的不是命令，而是代价

Section titled “你真正需要关心的不是命令，而是代价”

Native 的收益很直观：

  • 启动更快
  • 运行时更轻

但成本也很真实：

  • 构建更复杂
  • 调试更麻烦
  • 兼容性和工具链约束更多

所以这一页真正想表达的不是“怎么一条命令构建出来”，而是“你应该什么时候认真对待它”。

下一步

Section titled “下一步”