Erupt 2.0：Spring Boot 3.5 时代的注解低代码升级

预计阅读时间：11 分钟

Erupt v2.0.3 把一次普通版本升级做成了平台级翻新：底座跟进 Spring Boot 3.5.16，新增 erupt-designer 和 erupt-print 两个开源模块，erupt-web 2.0 也完成了 Angular 20 到 21 的全量重写。对正在用 Erupt 做后台、数据管理、内部工具的团队来说，这不是“点一下版本号”的升级，而是一次后端模型、前端运行时、安全策略和 AI 能力一起移动的版本线。

这次升级的核心信号

Erupt 的主线仍然是“注解驱动低代码”：开发者用 Java 实体和注解描述数据模型、表单、列表、查询、导出等后台能力，框架生成可用的管理界面。

2.0 版本的几个变化值得拆开看：

底座升级到 Spring Boot 3.5.16：这意味着项目依赖、插件、Jakarta 命名空间、运行时兼容性都需要重新确认。
新增 erupt-designer 与 erupt-print：一个指向可视化设计，一个指向打印场景，说明 Erupt 正在从“后台 CRUD”扩展到“业务界面编排”和“文档输出”。
新增 21 项能力：摘要提到注解增强、AI 能力、查询与导出等，这些都和开发效率直接相关。
前端重构 50+ 项：erupt-web 2.0 基于 Angular 21 全量重写，前端插件、自定义页面、主题样式都要纳入回归测试。
安全升级：密码加密从 MD5 迁移到更安全方案。摘要未给出目标算法细节，因此升级时应重点检查历史账号兼容和重置流程。

注解增强意味着什么

低代码框架最怕两件事：简单场景很快，复杂场景很别扭。Erupt 的注解增强如果落在查询、导出、表单、字段控制这些位置，实际价值会很直接：少写控制器、少写前端页面、少写重复的权限和导出逻辑。

可以这样理解它的开发模型：业务字段仍然放在实体里，展示、编辑、检索等后台行为通过注解挂上去。下面是一个“可改造”的示例，用来表达这种写法。具体注解名和参数请以你项目当前 Erupt 版本为准。

package com.example.admin.model;

import jakarta.persistence.Entity;
import jakarta.persistence.GeneratedValue;
import jakarta.persistence.Id;
import jakarta.persistence.Table;

// 假设：项目已引入 Erupt 2.x，以下 Erupt 注解名需按实际版本调整。
@Erupt(name = "客户档案")
@Table(name = "crm_customer")
@Entity
public class Customer {

    @Id
    @GeneratedValue
    private Long id;

    @EruptField(
        views = @View(title = "客户名称"),
        edit = @Edit(title = "客户名称", notNull = true)
    )
    private String name;

    @EruptField(
        views = @View(title = "手机号"),
        edit = @Edit(title = "手机号")
    )
    private String phone;

    @EruptField(
        views = @View(title = "客户等级"),
        edit = @Edit(title = "客户等级")
    )
    private String level;

    public Long getId() { return id; }
    public void setId(Long id) { this.id = id; }
    public String getName() { return name; }
    public void setName(String name) { this.name = name; }
    public String getPhone() { return phone; }
    public void setPhone(String phone) { this.phone = phone; }
    public String getLevel() { return level; }
    public void setLevel(String level) { this.level = level; }
}

要点不在于这段代码有多短，而在于它把后台页面的“结构性信息”固定在 Java 模型旁边。团队做代码评审时，可以同时看到字段、展示标题、编辑约束和查询导出意图，减少后端实体和前端表单长期漂移。

前端全量重写，升级时要盯住自定义扩展

erupt-web 2.0 从 Angular 20 到 21 的全量重写，是这次版本里风险最高也最值得投入测试的部分。框架内置页面通常会被维护者覆盖，但项目里的自定义页面、自定义组件、静态资源、主题覆盖、菜单嵌入点，最容易在大版本升级里暴露问题。

可以把回归范围压成一张清单：

登录、退出、刷新 token 或会话续期。
列表页分页、排序、查询、重置。
表单页新增、编辑、删除、批量操作。
文件上传、导入、导出。
自定义菜单、自定义前端页面、自定义按钮。
移动端或窄屏后台使用场景，如果你的团队真的在用。

如果项目把前端作为独立包维护，可以先做一次依赖体检：

node -v
npm -v
npm outdated || true
npm audit --omit=dev

如果你没有独立维护 erupt-web，也应该在升级环境里完整走一遍浏览器控制台检查，重点看运行时错误、接口 401/403、样式覆盖失效和导出下载异常。

安全迁移：别只换算法，还要处理历史密码

摘要明确提到密码加密从 MD5 升级。MD5 不适合继续保存密码，这是正确方向；但真实项目里最麻烦的是历史数据怎么迁。

可以这样实践：先识别库里疑似 MD5 的账号，再决定使用“登录时渐进升级”还是“强制重置密码”。下面 SQL 只做排查，不修改数据。

-- 假设用户表名为 erupt_user，密码字段为 password。
-- MD5 常见形态是 32 位十六进制字符串；请按实际表结构调整。
SELECT id, username, password
FROM erupt_user
WHERE password REGEXP '^[a-fA-F0-9]{32}$';

如果数据库不支持 REGEXP，可以先用长度和字符范围做粗筛：

SELECT id, username, password
FROM erupt_user
WHERE LENGTH(password) = 32;

在 Spring Boot 项目里，建议把密码迁移策略写清楚，而不是散落在登录逻辑里。下面是一个可改造的配置示例，表达“新密码用强哈希，旧 MD5 只用于过渡验证”的思路。具体 encoder 接入方式请以 Erupt 2.x 暴露的安全扩展点为准。

package com.example.admin.security;

import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
import org.springframework.security.crypto.bcrypt.BCryptPasswordEncoder;
import org.springframework.security.crypto.password.PasswordEncoder;

@Configuration
public class PasswordSecurityConfig {

    @Bean
    public PasswordEncoder passwordEncoder() {
        // 可以根据项目安全要求调整 strength，例如 10、12、14。
        return new BCryptPasswordEncoder(12);
    }
}

迁移策略建议二选一：

登录时渐进升级：用户用旧密码登录成功后，立即用新算法重写密码摘要。体验平滑，但需要保留一段兼容逻辑。
强制重置密码：安全边界清晰，适合内部系统或账号量不大的后台，但会增加运维和客服成本。

无论选哪一种，都不要长期保留 MD5 校验路径。

可以落地的升级步骤

建议不要在主分支上直接替换依赖。更稳的做法是切一个升级分支，把数据库、后端、前端、账号体系分开验收。

# 1. 创建升级分支
git checkout -b upgrade/erupt-2

# 2. 查看当前 Spring Boot 与 Erupt 相关依赖
./mvnw dependency:tree | grep -E "spring-boot|erupt" || true

# 3. 跑后端测试
./mvnw test

# 4. 打包验证
./mvnw clean package -DskipTests

如果你的项目使用 Maven，可以把 Spring Boot 版本先固定到和 Erupt 2.0.3 兼容的版本线。下面示例需要你替换真实的 Erupt 依赖坐标，因为摘要没有提供 artifact 细节。

<properties>
    <java.version>17</java.version>
    <spring-boot.version>3.5.16</spring-boot.version>
    <erupt.version>2.0.3</erupt.version>
</properties>

<dependencyManagement>
    <dependencies>
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-dependencies</artifactId>
            <version>${spring-boot.version}</version>
            <type>pom</type>
            <scope>import</scope>
        </dependency>
    </dependencies>
</dependencyManagement>

采用建议

新项目可以直接从 Erupt 2.0 开始，尤其是需要后台管理、打印、导出、AI 辅助能力的内部系统。老项目升级则要谨慎拆分：先确认 Spring Boot 3.5 兼容，再处理前端自定义扩展，最后收口密码迁移和账号回归。

上线前至少检查这几项：

Java 版本、Spring Boot 插件和第三方 starter 是否兼容 3.5.x。
所有 Erupt 注解是否还能按预期生成列表、表单、查询和导出。
erupt-web 2.0 下自定义菜单、样式、页面是否正常。
历史 MD5 密码是否有明确迁移路径。
erupt-designer、erupt-print 是否真的进入业务链路；不用的模块不要急着引入。

Erupt 2.0 的方向很清楚：把低代码后台从“快速生成页面”推进到“可设计、可打印、可接 AI、可升级安全基线”。真正的收益不会来自版本号，而来自你是否把升级拆成可验证的小步骤。