Quarkus 3.29.3 的测试在 Docker 24 失效，显式 API 配置要升级后才生效

升级 Quarkus 后，原来的 Docker 24 CI 不再能启动 Testcontainers 或 Dev Services；设置 api.version 也没有作用。这类故障要同时检查服务端支持的最大 API 和 Java 客户端实际使用的 API。服务端过旧与客户端过旧，处理方向正好相反。

Quarkus 3.29.3 为兼容当时提高最低 API 的 Docker 29，在环境检测路径中临时把 api.version 设为 1.44。Docker 24 支持的是较低版本，强制使用 1.44 会超出服务端能力。这段设置还覆盖了用户原有系统属性，导致外部配置无法纠正版本。

先在执行测试的同一台机器、同一 Docker context 下确认：

docker context show
docker version
./mvnw dependency:tree -Dincludes=org.testcontainers

不要以开发机 Docker 的版本替代 CI 的版本。远程 Docker、容器里的 socket 和桌面 context 都可能指向不同服务端。记录 Server 的 API 范围，尤其是最大值。

升级 Quarkus，再传入服务端支持的 API

Quarkus 3.29.4 的修复改为：仅当 api.version 未设置时才写默认 1.44，已有属性则保留。因此停留在 3.29.3 时反复加 -Dapi.version 并不能解决这一覆盖问题。采用该修复或后续兼容版本时，先让 BOM 与 Maven 插件版本保持一致，再给测试 JVM 传入服务端支持的版本。

例如 POM 使用常见属性管理平台与插件，可以调整对应属性，实际项目的属性名称可能不同：

<quarkus.platform.version>3.29.4</quarkus.platform.version>
<quarkus-plugin.version>3.29.4</quarkus-plugin.version>

对于 docker version 显示最大 API 为 1.43 的 Docker 24 环境，可在升级后尝试：

./mvnw -Dapi.version=1.43 test

若项目的 Surefire、Failsafe 或 CI 启动脚本不向测试 JVM 传递这个属性，需要在实际测试 JVM 的 system properties 中配置它。例如 Surefire 中可以加入：

<systemPropertyVariables>
  <api.version>${docker.api.version}</api.version>
</systemPropertyVariables>

并运行 ./mvnw -Ddocker.api.version=1.43 test。先确认测试进程取得了属性，不要在 application.properties 中写一个相似名称便认为已生效。集成测试由 Failsafe 执行时，也要检查对应插件。

这项修复恢复的是显式配置的优先级，并没有证明所有 Docker 版本都能自动协商。如果测试迁到 Docker 29.0，继续固定 1.43 又会低于当时服务端的最低 1.44。不同 CI 节点应使用各自兼容配置，或统一升级到支持当前协议的受维护组合。

验收应包括一个真实使用数据库容器的测试：确认容器启动、应用完成连接、测试结束后容器清理，并检查日志不再出现协议版本错误。仅运行不依赖容器的单元测试不能证明恢复。若报错改为 socket 权限、镜像拉取或端口超时，需要继续排查新的原因；不要用这一条 API 配置覆盖所有“找不到 Docker 环境”的情况。