Jib 能不依赖 Docker daemon 构建镜像，因其绕开 docker build 流程，不调用 Docker CLI 或 dockerd，而是直接组织类、依赖、资源为镜像分层，并通过 HTTP 推送至远程仓库。
为什么 Jib 能不依赖 Docker daemon 构建镜像
Jib 的核心在于绕开了 docker build 流程——它不调用 Docker CLI，也不需要本地运行 dockerd。它直接将 Java 应用的类、依赖、资源按镜像分层结构组织好，然后通过 HTTP 协议把 layer push 到镜像仓库（如 Docker Hub、Harbor、阿里云 ACR）。所以只要网络通、有仓库写权限，就能构建。
常见错误现象：java.lang.RuntimeException: Failed to pull base image 或构建时卡在 “Authenticating push” —— 多半是镜像仓库认证没配对，或基础镜像（如 gcr.io/distroless/java17）被墙，不是 Docker 进程问题。
- 基础镜像必须可远程拉取；国内推荐换用
ghcr.io/graalvm/jdk:21或阿里云镜像站代理的 distroless 镜像 - Jib 默认使用
tar.gz格式缓存本地构建产物，路径在~/.jib/，删错会导致重复上传 layer - 若项目用了自定义
Dockerfile，Jib 会直接忽略——它不解析也不执行 Dockerfile
Gradle 中配置 Jib 插件的关键参数
Jib 在 Gradle 里靠 jib 插件工作，最常出问题的是 to.image、from.image 和 container.mainClass 这三个字段没对齐。
典型错误：Container entrypoint class not found，其实是 container.mainClass 写成了全限定名但漏了包路径，或者类在 classpath 里但没被 Jib 正确识别为启动类。
立即学习“Java免费学习笔记（深入）”；
-
to.image必须含仓库域名和命名空间，比如registry.cn-hangzhou.aliyuncs.com/myteam/app:1.2，不能只写app:1.2 -
from.image推荐用 distroless 镜像（如gcr.io/distroless/java17），避免 JDK + JRE 混用导致NoClassDefFoundError -
container.mainClass值必须与META-INF/MANIFEST.MF中的Main-Class一致，且该类需有public static void main(String[])方法
如何让 Jib 推送镜像到私有 Harbor 仓库
Jib 不走 Docker 登录机制，所有认证都靠 Gradle 或 Maven 的 credentials 配置。Harbor 启用 HTTPS 且自签证书时，Jib 默认会拒绝连接，报错类似 PKIX path building failed。
这不是 Jib 的 bug，而是 JVM 的 SSL 信任链限制。解决方案不是关校验，而是把 Harbor 的 CA 证书导入到 Java truststore。
- 用
keytool -import -trustcacerts -keystore $JAVA_HOME/lib/security/cacerts -storepass changeit -alias harbor-ca -file harbor.crt导入证书 - 确保
to.auth.username和to.auth.password是 Harbor 项目的 robot account（非个人账号），否则权限不足 - Harbor 项目需开启“公开”或给 robot account 分配
push权限，否则 Jib 报UNAUTHORIZED错误
Jib 构建失败时怎么快速定位问题
Jib 日志默认较安静，加 --info 才能看到关键步骤（如 layer 计算、auth 请求、push 进度）。真正难排查的是 “构建成功但容器起不来”，这类问题往往出在启动命令或环境变量上。
常见表现：容器秒退，docker logs 显示 Error: Could not find or load main class，或 java.lang.NoClassDefFoundError。
- 用
./gradlew jib --image=xxx --dry-run查看 Jib 计划生成的镜像结构，确认mainClass和classpath是否合理 - Jib 默认把依赖打进
/app/libs/，启动时用java -cp /app/libs/*:/app/resources:/app/classes，不要在container.jvmFlags里硬写-cp - 如果项目用了 Spring Boot 的
fat jar，别再让 Jib 自动拆包——改用container.appRoot = "/app"并设container.entrypoint = ["java", "-jar", "/app/app.jar"]
复杂点在于 Jib 的 layer 策略是静态分析 classpath 得来的，它不会运行你的代码，也看不到 profile 激活逻辑。一旦依赖加载顺序、SPI 实现类路径、甚至 resources 下的配置文件位置不对，运行时才暴露，这时候得靠 jib.exportDockerContext 导出 tar 包手动 inspect。
