Apache Wicket 10.10.0 已正式发布。对于使用 Wicket 10.x 构建和维护 Java Web 应用的团队，这次更新最重要的信息不是增加了多少新接口，而是项目遵循语义化版本规则：与 10.0.0 相比，10.10.0 不包含 API 中断。已有应用通常可以把它作为一次兼容性升级来评估，而不必提前规划大规模代码迁移。
组件模型仍是 Wicket 的核心
Wicket 与以控制器、模板或前端 JSON API 为中心的框架不同。它将页面和表单拆成 Java 组件，并通过 wicket:id 把 Java 对象绑定到 HTML 元素。页面状态、事件处理和组件生命周期主要由服务端管理。
这种设计适合以下场景：
- 团队希望使用 Java 类型系统组织页面行为；
- 系统包含大量表单、权限控制和服务端状态；
- 项目需要长期维护，并重视组件复用；
- 页面主要由服务端渲染，不需要把全部交互迁移到独立的前端应用。
Wicket 已被用于政府、零售、大学、城市服务、银行和电子邮件服务等不同类型的网站。对这些生命周期较长的系统来说，小版本升级能否保持 API 稳定，往往比引入大量新特性更重要。
“没有 API 中断”不等于可以跳过验证
按照语义化版本约定，10.10.0 没有相对于 10.0.0 的 API 破坏。这意味着公开接口不应要求应用进行破坏性迁移，但运行时行为仍可能受到缺陷修复、依赖变化和应用自身扩展方式的影响。
升级时需要特别检查几个边界：
- 项目是否重写了 Wicket 内部实现，而不是只调用公开 API；
- 是否使用第三方 Wicket 组件库，以及它们是否支持 10.10.0；
- 自定义序列化、Session、Ajax 和页面存储逻辑是否依赖旧行为；
- 测试是否覆盖登录、表单提交、文件上传、重定向和异常页面；
- 应用服务器或 Servlet 容器的版本是否与当前部署组合兼容。
发布摘要提到了包括 WICKET-7107 在内的缺陷项，但没有提供该问题的完整描述。因此，不宜仅凭编号推断具体影响；实际升级应结合完整发布说明和项目测试结果判断。
可以这样实践：创建并验证一个 10.10.0 示例
下面是一套可改造的最小实践。假设 Wicket 10.10.0 对应的 Quickstart archetype 已发布到你的 Maven 仓库。执行前需要安装与 Wicket 10 兼容的 JDK 和 Maven；如果公司使用私有仓库，请确认该版本已经完成同步。
mvn archetype:generate \
-DarchetypeGroupId=org.apache.wicket \
-DarchetypeArtifactId=wicket-archetype-quickstart \
-DarchetypeVersion=10.10.0 \
-DgroupId=com.example \
-DartifactId=wicket-1010-demo \
-Dversion=1.0.0-SNAPSHOT \
-DinteractiveMode=false
cd wicket-1010-demo
mvn test
mvn jetty:run
启动后，可按生成项目的提示访问本地页面。若 archetype 尚未出现在所使用的仓库中，也可以基于现有 Wicket 10 项目修改 pom.xml：
<properties>
<wicket.version>10.10.0</wicket.version>
</properties>
<dependencies>
<dependency>
<groupId>org.apache.wicket</groupId>
<artifactId>wicket-core</artifactId>
<version>${wicket.version}</version>
</dependency>
</dependencies>
一个典型页面由 Java 类和同名 HTML 文件组成。例如 HomePage.java：
package com.example;
import org.apache.wicket.markup.html.WebPage;
import org.apache.wicket.markup.html.basic.Label;
public class HomePage extends WebPage {
public HomePage() {
add(new Label("release", "Apache Wicket 10.10.0"));
}
}
对应的 HomePage.html：
<!doctype html>
<html xmlns:wicket="http://wicket.apache.org">
<head>
<meta charset="UTF-8">
<title>Wicket 10.10.0</title>
</head>
<body>
<h1 wicket:id="release">Release name</h1>
</body>
</html>
这里的关键不是示例文本，而是组件绑定关系：Java 中的 Label("release", ...) 与 HTML 中的 wicket:id="release" 必须一致。升级完成后，这类页面渲染测试应成为回归验证的一部分。
现有项目的低风险升级步骤
不要在生产分支直接替换版本。可以先创建升级分支，并记录升级前后的依赖差异：
git switch -c upgrade/wicket-10.10.0
mvn -q dependency:tree > dependency-tree-before.txt
# 将 pom.xml 中的 Wicket 版本改为 10.10.0 后执行
mvn -q dependency:tree > dependency-tree-after.txt
diff -u dependency-tree-before.txt dependency-tree-after.txt || true
mvn clean verify
测试通过后，再在预发布环境完成浏览器级验证。建议至少覆盖：
- 启动应用并打开主要页面；
- 登录、退出和 Session 过期；
- 普通表单与 Ajax 表单提交；
- 页面刷新、返回和重定向；
- 文件上传、下载和错误处理；
- 集群部署中的 Session 序列化与故障切换。
是否应该立即采用
已经运行 Wicket 10.x 的应用，可以优先安排升级验证。语义化版本带来的 API 稳定承诺降低了迁移成本，而缺陷修复通常也值得进入常规维护周期。
仍在旧主版本上的项目则不应把 10.10.0 当成一次简单的补丁更新。应先评估跨主版本迁移要求、Java 与 Servlet/Jakarta 相关依赖、第三方组件兼容性，以及部署容器变化。无论属于哪种情况，可靠的采用标准都应是：依赖树已审查、自动化测试通过、关键页面完成预发布验证，并且回滚方案可执行。