我们已经使用 Wicket 1.3.7 几年了，目前正在将我们的项目升级到 Wicket 6.x
我对页面版本参数做了很多研究（例如 ?1 ）附加到每个URL，以及如何摆脱它们。（不幸的是，在官方文档中找不到有关此的详细信息。在这样做的时候，我读了很多声明（来自 Wicket 开发人员和用户，如
需要跟踪页面版本，否则将无法有状态
和
您需要使您的页面无状态才能摆脱它
还建议使用AbstractComponentMapper的自定义实现，覆盖encodePageComponentInfo不附加参数。这有一个明显的缺点，即破坏已挂载页面的状态性。（例如，请参阅此SO答案）
昨天我偶然发现了RenderStrategy.ONE_PASS_RENDER。
我试了一下，经过一些测试，我的印象是这是"恢复旧的检票口方式"的设置：页面版本参数消失了，但我的页面是有状态的。
好吧，还有一个缺点。如果必须自己处理双重提交问题，但我可以忍受。
问题：还有其他我（还）不知道的缺点吗？有什么惊喜吗？
这似乎是完美的解决方案，我只是想知道为什么有这么多关于如何摆脱这些参数的讨论，即使是与检票口开发人员，也不建议这样做......
提前谢谢。
我们经历了类似的升级路径，升级后的第一反应是"哇，这些是一些讨厌的 URL......"。
最初，我们还切换到单通道渲染以获得更好的 URL。但是，在深入研究之后，似乎"？id"不仅仅解决了双和位问题。
包含 Ajax 组件的页面可能是有状态的：当用户与页面交互时，您可以添加组件、删除其他组件等。使用 URL 参数中的页面 ID，如果刷新页面 （F5） 或导航到另一个页面，然后按后退按钮，则会以与离开页面相同的状态返回页面。
如果切换到一次传递呈现，则会失去该功能，因为浏览器无法识别页面存储中的哪个页面是目标，并且通常最终会得到页面对象的另一个实例。
这在"列表结果"页面（显示带有 Ajax 分页和过滤的"项目"列表/表的页面）中尤其明显。在具有一次通过呈现的此类页面上，即使您单击了几次"下一页"，您也经常会丢失搜索条件或返回到结果的开头。
我们最终使用了"标准"渲染机制（而不是一次通过重新创建）。URL 看起来不太好，但我们认为利大于弊（而且 href 看起来不错，它只是浏览器 URL 栏）。
另一个问题是我们网站的"可抓取性"。为了不让 302 或"url？id"影响 Google 索引，我们在 Wicket 应用程序 init 方法中添加了以下代码，以强制 Google Bot 进行一次性渲染：
setPageRendererProvider(new IPageRendererProvider() {
@Override
public PageRenderer get(RenderPageRequestHandler handler) {
return new WebPageRenderer(handler) {
@Override
protected boolean isOnePassRender() {
// To avoid 302s with Google Bot and have good SEO.
String userAgent = ((HttpServletRequest) RequestCycle.get().getRequest().getContainerRequest()).getHeader("User-Agent");
if (StringUtils.contains(userAgent, "Googlebot")) {
return true;
} else {
return super.isOnePassRender();
}
}
};
}
});