GeoServer 路线图列出了 3.0、2.28 与相关 GeoWebCache、GeoTools 版本的维护和终止支持节点。GIS 服务升级应据此安排 Java、容器和客户端协议回归。
可核查事实
- GeoServer 路线图将 3.0.x 标为 2026 年 3 月稳定、2026 年 10 月维护结束、2027 年 4 月终止支持。
- 同一表格列出 GeoServer 3.0.x 对应 GeoWebCache 2.0.x 与 GeoTools 35.x。
- 路线图列出 GeoServer 3.0.x 支持 Java 17 和 Java 21，并列出 Tomcat 11。
- 路线图将 2.28.x 的终止支持列为 2026 年 9 月。
- 2026 年 8 月 15 日的计划条目列出 GeoServer 3.0.1、GeoTools 35.1 和 GeoWebCache 2.0.1。
核心机制
服务端版本的风险来自依赖组合，而不只是 GeoServer 本身。Java 版本、Tomcat、GeoTools、GeoWebCache、数据存储驱动和 OGC 服务能力会共同决定升级结果。路线图提供时间边界，项目还要建立自己的兼容矩阵。
把这些事实放入 GIS 项目时，必须保留原始链接、发布日期和本次读取时间。来源的描述可以证明产品、维护窗口或版本计划，却不能自动证明本地数据已经正确处理；后者只能由可复现的运行记录、抽样比对和责任人审核完成。
GIS 场景与实施路径
可先选择一台非生产实例，导入脱敏工作区，跑 WMS、WFS、WMTS、REST 和缓存预热。然后用同一套请求比较状态码、图层范围、符号、缓存键和日志；通过后再安排数据库和网关切换。
实施时先建立“来源—数据—处理—产出”的最小链路：来源页面进入登记表，原始数据或接口响应进入可追溯目录，脚本和参数进入版本库，地图、统计和异常进入验收记录。出现差异时按这个链路回查，能避免用改标题或补一句说明掩盖事实与产出不一致。
可执行建议
- 固定一份可复跑的样本、输入版本和预期输出。
- 把来源日期、数据版本、处理参数和运行环境写入任务日志。
- 先在小范围验证，再扩展到批量和生产任务。
- 为失败建立可观察的重试与人工复核条件。
- 在发布结论前区分软件能力、数据事实与业务判断。
资料来源与数据口径
本文的具体时间、版本、接口和项目事实均来自文末所列一手页面。文中提出的测试方法是实施建议，不是来源机构的服务等级承诺。空间结果应明确坐标参考、范围、时间粒度、缺测处理和更新周期；涉及公众风险或资源配置时还要完成业务部门复核。
风险边界
路线图中的日期具有计划性质，社区模块和第三方扩展的支持周期可能不同。不要把稳定分支维护到期理解为立即不可运行，而应在到期前完成安全补丁、Java 兼容和回滚演练。
任何自动化都应保留失败状态而非静默补值。对需要认证、外部服务、第三方插件或实验性渲染后端的工作流，还应准备可审计的降级路径和恢复检查。
结论
GeoServer 3.0 的维护窗口临近：服务端升级别只看版本号 所指向的不是一次“跟进新闻”的任务，而是一项可验证的 GIS 变更。先把事实、数据口径和回归样本固定下来，再决定是否进入生产，团队才能在升级、维护或新项目出现时保持结果可解释。