企业官网建设流程全解析

1. 6004不是网络错：先把“它到底在拦什么”搞明白

调用 HMS SDK 接口报错 6004，第一次遇到的人十有八九会往网络、鉴权、接口参数这几个方向猜。我最初也是这么想的，抓了半天包，发现请求压根没有真正发出去——请求在更早的一层就被拦下了。所以这篇不着急贴解决方案，先把这道错误的“语义”讲透：6004 属于签名身份校验类错误，本质是“你这个安装包是谁签的”和“你在这个项目里登记的是谁”对不上，而不是服务端拒绝了你。

理解这一点非常关键。因为一旦你确认它是指纹校验失败，排查路径就变得极短：一边是 APK 里实际携带的签名证书指纹，一边是后台登记过的指纹，两边比对，不同就对齐。整个过程不需要读 SDK 源码，不需要开代理抓包，也不需要怀疑接口参数拼错。反过来，如果你把它当作网络或参数问题去查，可能会花掉一整天时间去反复检查初始化时机、权限声明甚至设备网络状态，最后发现根因只是发布包和调试包用了两套签名。

这篇内容适合三类人看：正在接 HMS 生态能力（账号、推送、定位、支付等 Kit）的客户端开发；被同事拉来“看一眼这个报错”的移动端负责人；以及需要在 CI 里把这类问题提前挡住的工程效率同学。基础弱一点也没关系，我会把证书、指纹、签名这些概念用生活化的方式重新讲一遍，保证你看完能自己动手比对。

1.1 一次典型现场：接口没调错，身份对不上

先说一个我印象比较深的场景。某个 Android 工程接入了账号能力，在开发机上一切正常，登录回调、token 获取全都跑得通。打了一个正式包给测试同学装到另一台机器上，登录按钮点下去，回调直接进失败分支，打出来的错误码是 6004。开发同学第一反应是“这台机器的网络有问题”，换 Wi-Fi 再试，还是 6004；又怀疑是这台机器上装的核心服务版本太老，升级之后依旧是 6004。

转折点出现在我们把两台机器的日志拉出来对比的时候。开发机上成功的那次，日志里有一行握手成功的记录；测试机上失败的那次，日志在握手阶段就中止了，后面压根没有业务请求的痕迹。这一下就很清楚了：故障点不在业务接口，而在于“客户端向服务证明自己身份”的前置环节。

再看我们工程里的构建配置，问题一目了然。buildTypes.debug用的是默认调试签名，buildTypes.release用的是公司统一的发布证书，而项目后台当时只登记了调试证书的指纹。也就是说，开发机上那台设备装的包，签名正好在登记名单里；测试机装的正式包，签名不在名单里，于是被拒。这不是 SDK 的 bug，也不是接口调错了，纯粹是“人证不符”。

这种案例之所以值得反复讲，是因为它有一个非常迷惑人的特征：同一个功能，在同一份代码上，表现却不一样。人会本能地怀疑环境、怀疑设备、怀疑网络，唯独不容易怀疑“包本身不一样”。而 6004 恰恰就是专门为“包不一样”准备的一个错误码。

1.2 校验链条：AGC应用 → agconnect-services.json → APK签名证书

要把这个问题彻底吃透，得把校验链条顺下来。HMS 生态下的应用，身份信息是三段式绑定的，缺一段或者错一段，都会走到 6004。

第一段是后台应用档案。你在 AGC（AppGallery Connect）里创建应用时填的包名，是这个应用在整个生态里的唯一标识。这个档案下会挂一份“允许的签名证书指纹清单”，可以是多条，比如调试一条、发布一条。这份清单就是白名单。

第二段是工程内的配置文件。从后台下载的agconnect-services.json会被放进app/目录，随 APK 一起打包。这个文件里固化了项目 ID、应用 ID、包名、API Key 等信息，相当于“身份证复印件”。它决定了运行时 SDK 知道自己该找哪个后台档案。

第三段是APK 实际签名。APK 安装到设备上之后，系统能读到它的签名证书。SDK 在初始化阶段会把这份证书的摘要值算出来，连同配置文件里的应用信息一起送到后台，后台拿它去比对白名单。

三段的对应关系可以这样记：

所以 6004 出现的位置很明确：前两段都对上了，唯独第三段对不上。如果前两段有问题，通常会报出别的错误码，或者在初始化阶段就抛异常。这个区分很重要，它帮你把排查范围从“整条链路”收窄到“签名指纹”这一格。

1.3 为什么它极易被误判成“调用姿势不对”

这个错误码的迷惑性还来自另一个地方：它往往只在某些调用上出现，而不是全量失败。比如有的 Kit 在初始化时就完成校验，有的 Kit 要等到首次发起业务请求才校验。于是你会看到“推送能收到，登录却报 6004”这种组合，人很容易顺着“登录接口怎么调”的方向去查，越查越偏。

还有一种情况是延迟触发。某些能力有本地缓存，首次校验通过后一段时间内不再重复校验。你在 A 设备上验证通过，换到 B 设备上却失败，会误以为是设备兼容性问题。实际上是 B 设备从来没有通过过校验。

我的建议很直接：看到 6004，先不要读业务代码，先去比对指纹。这个动作最多花五分钟，能排除掉绝大多数可能。如果指纹一致还报 6004，再回头查别的，那时候你的排查是有基础的，不是瞎猜。

提示：不要靠“重装一次试试”“清一下缓存试试”这类动作来判断 6004。这类动作有时确实会让现象消失，但那是缓存被清导致的假象，问题还在，下次换个包又会冒出来。

2. 取证：把签名指纹从工程里挖出来

排查的核心动作就一句话：拿到 APK 真实的 SHA-256 指纹，和后台登记的比。听起来简单，实操里有一堆细节能把人绊住——比如你从.jks文件里算出来的指纹，和从 APK 里读出来的指纹，理论上必须一致；但如果中间经过了加固、重签名、平台签名服务，两者就会分道扬镳。这一章把三条取证路径讲清楚，并且告诉你什么场景该用哪条。

2.1 keytool、apksigner、Gradle三条路的取舍

三条路各有适用面，选错了会拿到“看起来对但其实不是这个包”的指纹，这是最容易白忙一场的地方。

路径一：从 keystore 文件算。这是最常用的方式，适合你手里有签名文件、想确认“我这个证书到底是什么指纹”。

keytool -list -v \ -keystore release.jks \ -alias release \ -storepass 你的密码

输出里会有一行SHA256:，形如AB:CD:EF:...，共 32 组十六进制、用冒号分隔。这串东西就是你要填到后台去的值。

路径二：从已构建的 APK 里读。这是最可靠的方式，因为它读的是真正装到设备上的那个包。适用于怀疑构建过程改过签名的场景。

# build-tools 目录下 apksigner verify --print-certs app-release.apk

输出里会有Signer #1 certificate SHA-256 digest:。注意这里输出的是不带冒号的小写十六进制串，和 keytool 的格式不一样，填后台时要注意转换。

老项目可能还在用keytool -printcert -jarfile app-release.apk，这个命令对只做了 v1 签名的包有效，对 v2/v3 签名的包支持不全，容易读出空结果或者读错。如果你的包是近几年的构建产物，一律用 apksigner。

路径三：在 Gradle 里自动打印。适合放进构建流程，避免人工抄错。这段脚本我一直在用：

import java.security.KeyStore import java.security.MessageDigest tasks.register("printSigningFingerprint") { doLast { def cfg = android.signingConfigs.release // JDK 9+ 默认 KeyStore 类型是 PKCS12，jks 文件必须显式指定 def type = cfg.storeFile.name.endsWith(".jks") ? "JKS" : "PKCS12" def ks = KeyStore.getInstance(type) cfg.storeFile.withInputStream { ks.load(it, cfg.storePassword.toCharArray()) } def cert = ks.getCertificate(cfg.keyAlias) def digest = MessageDigest.getInstance("SHA-256").digest(cert.encoded) def hex = digest.collect { String.format("%02X", it) }.join(":") println "SHA-256(${cfg.keyAlias}) = $hex" } }

这里有个坑单独说一下：JDK 9 之后KeyStore.getDefaultType()变成了PKCS12，直接KeyStore.getInstance(KeyStore.defaultType)去加载.jks文件会抛Invalid keystore format。我第一次写这段脚本时就在这卡了十来分钟，一度以为是密码错了。所以脚本里必须按文件后缀显式指定类型。

三条路径的定位我用一张表总结：

2.2 后台填写格式的三个细节坑

指纹拿到了，填进去还是报错，这种经历我遇到过不止一次。问题基本都出在格式上。

坑一：冒号和小写。keytool 输出的是带冒号的大写，apksigner 输出的是不带冒号的小写。后台输入框对格式的宽容度因版本而异，最稳妥的做法是统一成不带冒号的小写十六进制再粘贴。如果你不确定，两种都试一次，成本很低。

坑二：SHA-1 和 SHA-256 混填。有些老文档、老截图里写的是 SHA-1 指纹，现在主流的校验用的是 SHA-256。keytool 输出里两个都有，别抄错行。我见过一个团队把 SHA-1 填进 SHA-256 的框里，折腾了两天才发现。

坑三：一条还是多条。一个应用档案下可以登记多条指纹，这是设计上支持的。正确的做法是把调试证书和发布证书的指纹都登记上，而不是每次切换构建类型就去后台改一次。后者不仅麻烦，还容易在团队协作时互相覆盖，造成“我这边好好的，你那边就报错”的扯皮。

顺带提一句配置文件。agconnect-services.json是从后台下载的，它和后台档案是绑定的。如果你换了应用档案、改了包名、或者后台加了新的指纹，务必重新下载这个文件并替换。很多人只改了指纹没换文件，结果因为文件里的应用 ID 没变而误以为配置没生效——实际上指纹是生效的，只是他被别的问题误导了。

2.3 用一张表把“哪边不一致”定位出来

取证完成后，把“实际指纹”和“登记指纹”摆在一起，用下面这张表快速定位：

这张表覆盖了我处理过的绝大多数情况。真正需要往深处查的，是表格最后两行——它们分别对应“分发平台改签”和“配置生效延迟”，我在后面单独展开。

3. 六种真实根因，按出现频率排

指纹对不上是表象，往下一层，导致对不上的原因有好几种。这一章按我遇到的频率从高到低排，每一种都给出识别特征和处置方式。你可以直接对着自己的场景找对应条目。

3.1 调试包跑通、正式包翻车

这是最高频的一种，占比我估计超过一半。开发阶段用默认调试签名，上线前换成发布证书，后台只登记了前者。识别特征非常明显：同一份代码，assembleDebug出来的包装上去正常，assembleRelease出来的包报 6004。

处置动作就是把发布证书的 SHA-256 补进后台指纹列表。补完之后记得重新下载配置文件——虽然指纹校验不依赖配置文件更新，但保持两者同步能避免后续踩别的坑。

这里有个经验：新项目立项时就把两条指纹一次性登记好，成本几乎为零，能省掉后面至少一次线上事故。我现在的习惯是在项目初始化清单里加一行“AGC 登记 debug + release 双指纹”，跟配置混淆规则、申请权限放在一起。

3.2 分发平台的签名服务改写了指纹

这个坑更隐蔽，因为它只在“从商店下载的包”上出现，本地构建的包完全正常。原因是一些分发平台为了保护开发者密钥，提供了上传包后由平台重新签名的能力。开发者上传的是用自己的证书签的包，但用户下载到的包，签名证书已经被平台换成了平台持有的证书。

于是链条变成：你在本地测的是指纹 A，用户在商店下到的包指纹是 C，后台只登记了 A，用户一打开就 6004。更难受的是这个现象在灰度阶段可能不明显——内测分发渠道往往不做改签，等到正式上架才暴露。

识别方法很简单：从商店下载安装包，用apksigner verify --print-certs读一次指纹，和本地产物对比。不一致就说明被改签了。

处置方式是把平台侧的指纹也登记进白名单。一般平台会在应用详情或者签名管理页面提供这个指纹，直接复制过来即可。需要注意的是，平台签名服务开启后通常不可逆，后续所有更新包都必须走同一条路径，否则新旧包的签名不一致，用户覆盖安装会失败。这一点在开启前要想清楚。

3.3 加固与二次签名

移动端做安全加固时，加固工具通常会对 APK 重新签名。如果你的加固流程里配的是另一套证书，或者加固平台默认用了它自己的证书，出来的包指纹就变了。

这种情况的特征是：加固前正常，加固后 6004。排查时不要去怀疑加固破坏了 SDK 代码，先读一下加固产物的签名指纹，五分钟就能确认。

正确的做法是：加固完成后，用你自己的发布证书对产物重新签名，而不是接受加固平台给的默认签名。这样指纹始终保持一致，后台不需要改。如果你的加固平台支持上传自有证书，优先用这个能力。

还有一种变体是多渠道打包工具。一些老的打包脚本会在 APK 尾部追加渠道信息后重新签名，用的证书如果和主包不一致，也会 6004。这类工具现在用得少了，但存量项目里还有。

3.4 多渠道与 flavor 后缀

工程里配了productFlavors，并且给不同渠道加了applicationIdSuffix，这就意味着不同渠道包的包名不一样。包名不一样，在后台就是不同的应用，需要分别建档、分别登记指纹。

很多团队只给主包名建了档，渠道包用的是com.example.app.huawei这种带后缀的包名，SDK 拿着这个包名去后台查，查不到对应档案，或者查到的是另一个应用，于是校验失败。

识别特征：主渠道包正常，某个特定渠道包 6004。看一眼那个渠道的applicationId就知道了。

处置有两条路：给每个渠道包名单独建档并登记指纹；或者干脆去掉applicationIdSuffix，所有渠道共用一个包名，靠渠道参数区分。后者更省事，但如果你们有“同设备装多个渠道包”的测试需求，就只能走前者。

顺带说一句，包名改了之后agconnect-services.json也要跟着换。如果你的工程是多个 flavor 共用一份配置文件，那必然有一个渠道是错的。正确姿势是按 flavor 分目录放配置文件：

app/src/main/agconnect-services.json # 主渠道 app/src/huawei/agconnect-services.json # 特定渠道

Gradle 在构建时会自动按 sourceSet 合并，同名文件后者覆盖前者。

3.5 多人协作下 debug keystore 各不相同

这一条专门坑团队。Android 的调试签名默认使用用户目录下的~/.android/debug.keystore，这个文件是每台机器首次构建时自动生成的，密码固定、别名固定，但证书内容每台机器都不一样。

于是就出现了：A 同学在自己机器上跑得好好的，因为他的调试指纹早就登记过了；B 同学新入职，拉下代码一跑，6004。

识别特征：只有某几个人报错，且都是新环境。

处置方式有两种。省事的做法是把 B 同学的调试指纹也加进白名单，但人一多白名单就乱了。更规范的做法是团队统一使用一份调试证书：在工程里放一个debug.jks，通过signingConfigs.debug显式指定，所有人共用。这样调试指纹只有一份，登记一次全员受益。

android { signingConfigs { debug { storeFile file("../keystore/debug.jks") storePassword "统一密码" keyAlias "debug" keyPassword "统一密码" } } }

注意：调试证书提交到代码仓库这件事本身有争议，但只要它只用于调试、绝不用于发布，风险是可控的。关键是发布证书必须严格隔离，不能进仓库，走环境变量或者密钥管理服务注入。

3.6 配置写入后的生效延迟与本地缓存

指纹填进去，立刻测，还是报错，等几分钟再测，好了。这种情况我遇到过几次，属于后台侧的生效延迟，通常几分钟内完成，极端情况下更久。

还有一种“假性未生效”是本地造成的。设备上可能存在校验结果的缓存，SDK 也不会在每次调用时都重新拉配置。这时候单纯重启应用不够，需要卸载重装，让缓存彻底清掉。

判断方法：如果补登记指纹后等待一段时间仍然稳定报错，就不是延迟问题，要回去检查是不是填错了。如果报错变成偶发，那基本就是延迟，等等就好。我一般会把“补登记后等待 5 分钟再验证”写进排查笔记，避免自己在等待窗口内反复推翻正确结论。

4. 一次完整排查链路的复盘：从logcat关键字到修复验证

光知道原因还不够，实际排查时人是慌的，需要一个可执行的顺序。这一章我把一次完整排查的过程原样复现出来，包括我当时判断错的弯路，你可以照着这个顺序走一遍。

4.1 先切分问题域：网络、初始化、指纹

拿到 6004 的第一件事不是查代码，是抓日志。日志能告诉你的信息量远超想象。

# 通用关键字过滤，一次抓全 adb logcat -v time | grep -iE "6004|agconnect|hmscore|hms-" # Windows 环境 adb logcat -v time | findstr /I "6004 agconnect hmscore hms-"

抓日志的时候，从冷启动开始抓。因为很多校验发生在应用初始化阶段，你等应用起来了再抓，关键日志已经滚过去了。正确操作是：adb logcat -c清空缓冲，启动应用复现问题，然后停掉抓取。

日志到手之后，按三个阶段切分：

第一阶段：SDK 有没有初始化成功。找初始化相关的日志，看看配置文件有没有被读到、应用 ID 有没有解析出来。如果这一阶段就有异常，说明agconnect-services.json缺失或者包名不匹配，问题在第二段链条，不是指纹。

第二阶段：校验请求有没有发出去。找握手、鉴权相关的日志。如果看到请求发出去了、有响应回来、响应里带 6004，那就坐实了指纹问题。

第三阶段：业务接口有没有被调用。如果日志里压根没有业务请求的痕迹，说明请求在校验阶段就被拦下了，进一步印证第二阶段。

这三步做完，你基本可以确定问题域了。我第一次排查时跳过了这一步，直接去读业务代码，在onActivityResult里翻来覆去看参数，浪费了大半个小时。

4.2 逐层排除的具体动作与判据

确定是指纹问题之后，按下面的顺序排除，每一步都有明确判据，不通过就停下来处理，通过了再往下走。

第一层：确认当前装的包的指纹。从已安装的设备上直接读，这是最不容易出错的：

adb shell pm path com.example.app adb pull /data/app/.../base.apk ./installed.apk apksigner verify --print-certs ./installed.apk

这一步比读本地构建产物更可靠，因为它读的是设备上真正在运行的那个包。我遇到过本地构建产物指纹正确、但安装过程中因为包名冲突装了个旧包上去的情况，用这条命令一秒识别。

第二层：确认后台登记。后台控制台里找到对应的应用档案，看证书指纹列表。注意确认你看的是不是正确的应用——尤其是有多个应用、多个项目的情况下，很容易点错。

第三层：确认配置文件版本。把agconnect-services.json打开，看里面的包名、应用 ID 和后台是否一致。如果后台最近改过配置而文件没更新，这里就能看出来。

第四层：确认代码里的初始化。早期版本的 SDK 需要显式初始化，如果初始化时机不对（比如在Application.onCreate之前被调用），也可能导致校验信息不完整。这一层出问题的概率不高，但前面三层都通过还报错的话，值得看一眼。

这四层走完，问题必然暴露。我用这套流程帮别人排查过几次，从拿到日志到定位根因基本都在二十分钟以内。

4.3 修复后的回归验证清单

改完配置不是结束，还得验证。我给自己定的验证清单是这样的：

关键在于**“全新设备”和“商店渠道包”这两行**，它们分别能抓出缓存假象和改签问题。很多人验证时用的是自己那台已经装过无数次的设备，自动登录状态早就存在，测出来的“正常”是不可信的。

另外提醒一句：修完别忘了在团队里同步。6004 这类问题最怕的是“某个人知道了但没说出来”，过两周换个人接手，同样的坑再踩一遍。

5. 把6004拦在提测之前：工程化预防

靠人肉排查终究是治标。既然这个错误的根因如此明确——就是指纹不一致——那完全可以在构建阶段自动发现。这一章讲三个层次的预防手段，从轻到重，按团队规模选。

5.1 让构建脚本自己打印指纹

最轻量的手段，成本不到十分钟，收益立竿见影。把前面那个printSigningFingerprinttask 挂到assembleRelease前面，每次打正式包时在控制台打出指纹：

tasks.register("printSigningFingerprint") { /* 见 2.1 节 */ } tasks.matching { it.name == "assembleRelease" }.configureEach { dependsOn("printSigningFingerprint") }

这样每次构建日志里都会出现一行指纹，开发同学不需要额外操作，肉眼扫一眼就能发现是不是自己熟悉的那个值。如果哪天构建脚本被人改动了签名配置，这行输出会立刻变化，形成一种“无意识的告警”。

我现在的做法更粗暴一点：把这个 task 的输出写进一个固定文件，构建完成后直接cat一下。

5.2 CI流水线里的指纹一致性检查

再往上一个层次，是在 CI 里做断言：构建产物的指纹必须等于预期值，不等就让流水线失败。

#!/usr/bin/env bash set -euo pipefail APK="app/build/outputs/apk/release/app-release.apk" EXPECTED="ab12cd34..." # 小写、无冒号，与后台登记保持一致 ACTUAL=$(apksigner verify --print-certs "$APK" \ | grep -i "SHA-256 digest" \ | head -n1 \ | awk -F': ' '{print $2}' \ | tr -d ':' \ | tr 'A-F' 'a-f') if [ "$ACTUAL" != "$EXPECTED" ]; then echo "签名指纹不一致" echo " expected: $EXPECTED" echo " actual : $ACTUAL" exit 1 fi echo "签名指纹校验通过"

这段脚本放在打包任务的最后一步。它的价值在于把问题挡在提测之前，而不是等测试同学装上去报 6004 再回头查。上线前最怕的就是“明明测过了怎么又不对”，多半就是某次构建悄悄换了签名。

预期值怎么维护？我建议放进 CI 的环境变量或者流水线配置里，而不是硬编码在脚本中。这样改指纹时只改一处，所有流水线自动生效。

5.3 多环境配置的隔离姿势

最后一个层次是配置管理。多环境（开发、预发、生产）工程最容易出现“配置串了”的问题，这里的配置既包括后台应用，也包括签名证书。

我的做法是三者严格绑定：一个环境 = 一个应用档案 = 一套签名证书 = 一份配置文件。在 Gradle 里用 flavor 把它们绑在一起：

android { flavorDimensions "env" productFlavors { dev { dimension "env" applicationId "com.example.app.dev" signingConfig signingConfigs.debug } prod { dimension "env" applicationId "com.example.app" signingConfig signingConfigs.release } } }

配置文件按 flavor 分目录放，签名配置按 flavor 指定。这样一来，“装错包”在物理上就不可能发生——不同环境的包连包名都不一样，装到同一台机器上可以共存，测试同学一眼就能看出自己装的是哪个。

这套做法的额外好处是排查时省事。以前遇到 6004，要先问“你装的是哪个环境的包”，现在看一眼包名就知道了。别小看这个细节，团队里沟通成本最高的往往不是技术问题，而是“你说的和我说的不是同一个东西”。

6. 几个不常见但会咬人的边界场景

前面的内容覆盖了绝大多数情况。剩下这几种场景出现频率不高，但一旦遇上就很费时间，因为特征不明显，容易往错误方向查。我把它们单独列出来，你遇到“该查的都查了还是 6004”的时候，可以对着这里过一遍。

6.1 老版本核心服务与设备差异

HMS 的能力是通过设备上的核心服务组件提供的。如果设备上的组件版本过老，校验逻辑可能和当前 SDK 期望的不一致，表现出来的错误码也可能是 6004。这种情况的特征是：同一份包，在大部分设备上正常，在少数特定设备上失败。

排查方法是看一下失败设备上的核心服务版本，和在正常设备上对比。如果差异明显，那就是它了。处置方式是引导用户升级核心服务，或者在应用内做好版本判断和降级提示。

还有一种情况是海外机型。部分海外销售的设备没有预装完整的 HMS 核心服务，SDK 调用会走失败分支。这类设备上你看到的错误码可能五花八门，6004 只是其中一种。正规做法是在调用前先判断环境可用性，不可用就走自己的备用方案，而不是让用户看到错误码。

6.2 覆盖安装、多包名与拆分包

最后说几个安装层面的边界情况。

覆盖安装。如果设备上已经装了同包名但不同签名的应用，系统会拒绝安装。但有些场景下（比如通过某些测试分发渠道）可能会出现签名不一致但安装成功的情况，这时候运行起来就会出现校验异常。判断方法是先卸载再装，问题消失的就是这个原因。

多包名共存。一个设备上装了同一应用的多个包名版本（比如正式版和某个渠道版），如果这些包名在后台对应的是不同应用档案，但用户在里面切换账号，可能会出现校验信息串扰。这种场景比较极端，实际遇到时优先检查是不是装错了包。

拆分包。使用了 App Bundle 分发时，用户下载到的是拆分后的产物，签名信息和完整包是一致的，通常不会因此报 6004。但如果分发链路中间做了二次处理，就要按 3.2 节的方法验证。

我在实际处理这类问题时，体会最深的一点是：6004 本身是个好消息。它明确告诉你问题在签名身份这一层，范围极小，比那些只给你一个“未知错误”的场景友好太多。真正浪费时间的从来不是错误码本身，而是我们不愿意相信问题会这么简单，于是绕着它查了一大圈。踩过几次之后，我现在的习惯是看到 6004 先做指纹比对，五分钟解决战斗，比任何猜测都靠谱。

如果你手上正好有个项目卡在这个错误上，建议先别改代码，把apksigner verify --print-certs跑一遍，把输出和后台登记的值并排放着看一眼。多数情况下，答案就在那两行十六进制里。