上周陪一个团队排查HarmonyOS应用的更新问题，他们的应用还没上架，测试在“检查更新”上点了半天，页面纹丝不动。负责产品的同事问我：更新功能是不是必须上架才能调试？我说不是，更新链路拆开看，真正要验证的东西和上不上架没有必然关系。真正需要解决的是“未上架时没有应用市场帮你分发新版本”，但你完全可以用一个本地服务模拟这个分发动作，把整个流程测通。这篇就记录一下我怎么在应用未上架的情况下，完整调试和检测HarmonyOS应用更新功能是否正常的。
先说结论：未上架不影响你验证“检查更新逻辑是否正确、下载流程是否通、安装拉起是否顺利”这三件事。应用市场在上架后只是多了一个官方分发渠道，而我们在调试阶段需要的只是一个可控的“更新源”。
1. 更新链路拆开看：未上架时真正要验证的是哪三件事
很多团队一听到“未上架”就觉得更新功能没法测，其实是把“应用市场能力”和“应用自身逻辑”混在一起了。应用更新功能在代码层面只做三件事：对比版本、取回新包、交给系统安装。这三件事运行在应用内，不依赖应用市场。
1.1 更新不是“点个按钮”，而是三段链路
第一段是检测更新。应用启动或者用户点击检查更新时，客户端把当前版本号发给服务器，服务器返回“有没有新版本、新版本号、下载地址、包大小”等信息。这一段的核心是版本号读取和网络请求，只要服务器接口可控，没上架也一样能测。
第二段是下载新包。确认有新版本后，客户端把hap包下载到应用自己的沙箱目录里。这段的核心是下载任务调度、进度回调和异常处理，和上架不上架没有半点关系。实际调试时你会发现，下载阶段最容易出问题的是路径写错、权限没配、防火墙拦截。
第三段是拉起安装。下载完成后，应用需要调用系统安装能力，把hap包路径通过Intent传给系统，由系统弹窗让用户确认安装。这一段的重点是“系统是否接受这个包”，安装成功与否取决于包签名、版本号和系统安装策略，这些和上架状态也无关。
所以你看，整个更新功能能不能跑通，取决于你写的代码和测试服务器的配合，而不是应用市场。未上架唯一的影响是：你拿不到AppGallery Connect那边托管的“正式更新源”，需要自己搭一个。
1.2 未上架到底缺了什么：应用市场通道与本地自建通道的差异
如果用了华为应用市场提供的“应用内更新”SDK，那确实要上架后在AGC后台配置版本才能分发。SDK会去应用市场后台拉取升级包列表，应用没上架时这个列表根本不存在，自然返回不了任何更新信息。所以如果你走的是官方SDK路线，未上架阶段测不出来是正常的，这是第一个必须认清的差异。
但自建更新通道是完全绕开应用市场的，服务器地址、版本规则、包分发全由你自己控制。未上架阶段你完全可以搭一个临时的HTTP服务，放一个测试hap包，让手机走局域网访问这个服务来完成整个更新闭环。这个闭环一旦跑通，等上架后再切到官方SDK，逻辑验证成本会低很多。
另外还要提醒一点：AppGallery的“应用内更新”SDK在应用未上架时，有时会返回特定的错误码（比如未配置或未授权）。如果你在未上架阶段看到这类错误，不要慌，不代表代码写错了，只是渠道还没激活。
1.3 先定验收标准：什么样的状态才算“更新功能正常”
调试之前先明确“正常”的含义，后面才不会测了个寂寞。我的验收标准很简单，四个钩子全打上就算通过：
- 老版本启动后能正确触发检查更新，服务器日志能看到请求，返回数据能被解析。
- 检测到新版本后，提示语、版本号、包大小展示正确，用户点击确认后开始下载。
- 下载过程有进度反馈，下载完成后文件确实落在沙箱目录里，大小和服务器一致。
- 系统安装页面能正常拉起，用户确认后安装成功，重新打开应用显示的是新版本号。
这四条听起来朴素，但真跑起来你会发现，卡在第二条和第四条的情况最多。后面我会按这个标准铺开讲怎么操作。
2. 版本读取、下载与安装拉起：HarmonyOS更新链路的核心API
进入实操前，先把更新链路涉及的HarmonyOS API过一遍。这部分我不打算贴一堆官方文档，只挑你写代码时真正会用到的东西讲，顺便说说容易踩的坑。
2.1 拿当前版本号：versionCode 与 versionName 别混淆
更新检测的第一件事就是知道自己当前是什么版本。HarmonyOS应用的版本信息有两个字段：versionCode是整数，必须递增，机器比较用它；versionName是字符串，给用户看的，比如“1.0.2”。很多新手用versionName比较大小，写过一次就知道有多坑，这个我放到第五章再说。
读取版本号的代码框架大概是这样的：
// 示意代码，不同SDK版本的导入路径略有差异 import { bundleManager } from '@kit.AbilityKit'; let bundleInfo = bundleManager.getBundleInfoForSelfSync( bundleManager.BundleFlag.GET_BUNDLE_INFO_WITH_APPLICATION ); let currentVersionCode = bundleInfo.versionCode; // 整数，用于逻辑比较 let currentVersionName = bundleInfo.versionName; // 字符串，用于界面展示注意一点：在API 12（HarmonyOS NEXT）的Kit化写法里，模块导入路径可能和API 9时代的@ohos.bundle.bundleManager不同。你自己工程里按SDK文档确认即可，重点是拿到versionCode和versionName这两个字段。
我在实际项目里习惯把这两个值在应用启动时打一条日志，这样后面用hdc看日志时，第一件事就能确认当前装的到底是哪个版本，排查问题不必靠猜。
2.2 检查更新：用 http 请求问服务器要版本信息
检查更新本质就是一个GET请求。客户端把当前versionCode带给服务器，服务器返回有没有新版本。HarmonyOS上标准的做法是使用@ohos.net.http模块，大致写法如下：
import { http } from '@kit.NetworkKit'; let httpRequest = http.createHttp(); httpRequest.request( 'http://192.168.1.100:8080/api/update?versionCode=' + currentVersionCode, { method: http.RequestMethod.GET, connectTimeout: 10000, readTimeout: 10000 } ).then((response) => { if (response.responseCode === 200) { // 解析JSON，判断 hasUpdate 和 serverVersionCode let result = JSON.parse(response.result as string); // 先判断网络层再判断业务层 } }).catch(() => { // 断网、超时、地址不可达都会走到这里 });这里我强烈建议把超时时间设置好，不要依赖默认值。我在真机调试时遇到过一种情况：电脑开了防火墙，手机访问不到本地服务，结果客户端一直转圈不报错，后来才发现是超时时间设得太长，体验上像“卡死”。
服务端返回的数据结构建议固定一套，至少要包含hasUpdate、versionCode、versionName、downloadUrl、size这几个字段。后面章节我会给一个可以直接跑的本地服务示例，字段就是按这套来的。
2.3 下载新包：官方下载任务与本地路径选择
下载hap包推荐用@ohos.request模块的下载任务，而不是自己拿HTTP流一段段写文件。理由很简单：官方下载任务自带进度回调和断点续传能力，代码量少，稳定性高。
import { request } from '@kit.BasicServicesKit'; let downloadTask = await request.downloadFile(context, { url: 'http://192.168.1.100:8080/app-1.0.2.hap', filePath: `${context.cacheDir}/update/app-1.0.2.hap` }); downloadTask.on('progress', (data) => { console.info(`UpdateManager progress: ${data.receivedSize}/${data.totalSize}`); });文件路径这块是个隐性坑。我见过不少人把更新包直接写到filesDir，结果安装时会遇到沙箱路径传参问题。我的建议是下载到cacheDir/update/下面，原因有两个：一是更新包属于临时数据，装完就应该清理；二是cacheDir空间被系统清理不影响用户业务数据，即使更新包残留，也不会白白占用用户手机空间。
下载完成后什么算成功？标准有两层：下载任务状态正常返回，且落盘文件大小与服务器返回的size一致。如果服务器能提供MD5，建议再校验一遍，调试阶段可以省掉，但正式上线最好加上。
2.4 拉起安装：把 hap 交给系统，让用户确认
下载完成后就是拉起系统安装页面。HarmonyOS里应用自身不能静默安装，必须通过系统安装能力，最终由用户点击确认。代码结构如下：
// 示意代码：具体action与参数名以当前SDK文档为准 let want = { action: 'ohos.intent.action.INSTALL_PACKAGE', parameters: { path: `${context.cacheDir}/update/app-1.0.2.hap` } }; context.startAbility(want).then(() => { console.info('UpdateManager: install page launched'); }).catch((err) => { console.error(`UpdateManager: startAbility failed, ${JSON.stringify(err)}`); });这一段在API 12（HarmonyOS NEXT）上行为会比旧版严格很多。系统会强制校验hap包的签名和来源，如果签名不一致，安装页面会直接拒绝，或者安装到一半报“安装失败”。这也是我说未上架调试时最容易碰壁的点，具体原因在第五章展开。
另外，安装结果不在startAbility的返回值里，因为拉起安装页后用户可能确认、取消、也可能因为签名问题直接失败。你需要通过“安装后重查版本号”来验证是否真的装上了，这个检测方法我放在第四章第4节。
3. 把“远端更新源”搬到本地：搭建调试版本服务与测试包
如果你已经有一个测试服务器，可以跳过本章，直接看第四章的检测清单。如果和我一样平时主要用DevEco Studio本机调试，那这一章就是为你准备的——十分钟搭一个本地更新源，让手机和平板能访问到。
3.1 准备两个版本的测试 hap
更新链路要跑通，至少需要两个不同versionCode的包：一个当当前安装的老版本，一个当服务器上的新版本。
操作上很简单：在DevEco Studio里把app.json5的versionCode先设成1000001，打一个包安装到手机；然后把versionCode改到1000002，再把versionName改成1.0.2，打出的这个包放到你的更新服务器目录下。
有一个细节要注意：调试阶段建议都用同一个签名来打这两个包。如果你用DevEco Studio的自动签名（Debug签名）装老版本，但塞到服务器上的新版本换了上传签名或Release签名，那安装环节会报签名不一致，干扰你判断“工期是不是真的通了”。
还有一个技巧：为了让下载进度看得清楚，你可以在新版本里随便塞一个几MB的素材，让hap包大一点，这样下载进度条变化明显，不会一两秒就闪过去。
3.2 一个十分钟就能跑起来的本地更新服务
我一直觉得调试阶段没必要上个完整后端，Python的标准库就能搞定更新接口和文件托管。下面这个脚本可以直接保存为update_server.py运行：
# update_server.py -- 本机调试用，不建议直接上生产 import json import os from http.server import BaseHTTPRequestHandler, HTTPServer from urllib.parse import urlparse, parse_qs HAP_FILE = "app-1.0.2.hap" # 与脚本放同一个目录 CURRENT_CODE = 1000002 # 服务器认为的最新版本号 PORT = 8080 class UpdateHandler(BaseHTTPRequestHandler): def log_message(self, fmt, *args): pass # 去掉默认的访问日志噪音 def do_GET(self): url = urlparse(self.path) if url.path == "/api/update": current = int(parse_qs(url.query).get("versionCode", ["0"])[0]) if current < CURRENT_CODE: data = { "code": 0, "data": { "hasUpdate": True, "versionCode": CURRENT_CODE, "versionName": "1.0.2", "downloadUrl": "http://<电脑局域网IP>:8080/app-1.0.2.hap" } } else: data = {"code": 0, "data": {"hasUpdate": False}} body = json.dumps(data).encode("utf-8") self.send_response(200) self.send_header("Content-Type", "application/json; charset=utf-8") self.send_header("Content-Length", str(len(body))) self.end_headers() self.wfile.write(body) elif url.path == f"/{HAP_FILE}": if not os.path.exists(HAP_FILE): self.send_error(404) return self.send_response(200) self.send_header("Content-Type", "application/octet-stream") self.send_header("Content-Length", str(os.path.getsize(HAP_FILE))) self.end_headers() with open(HAP_FILE, "rb") as f: self.wfile.write(f.read()) else: self.send_error(404) if __name__ == "__main__": HTTPServer(("0.0.0.0", PORT), UpdateHandler).serve_forever()启动后先用电脑浏览器验证一下：访问http://127.0.0.1:8080/api/update?versionCode=1000001，应该能看到JSON返回hasUpdate: true。再把versionCode=1000002传一次，应该返回hasUpdate: false。接口通了这个服务就跑起来。
这里那个<电脑局域网IP>需要你换成实际的IP，不要照抄。真机访问时不能填127.0.0.1，那是手机自己。
3.3 让手机/平板找到开发电脑
最省事的方案是让手机和电脑连同一个WiFi，然后给手机一个局域网IP下的下载地址。电脑IP怎么查？Windows下在命令行敲ipconfig，找“无线局域网适配器 WLAN”下面的IPv4地址；Mac下在终端敲ipconfig getifaddr en0；Linux桌面用ip addr。
查到IP后，先做两件事验证连通性：
- 手机浏览器直接访问
http://电脑IP:8080/app-1.0.2.hap，能看到下载动作就是通的。 - 如果打不开，九成是电脑防火墙拦了8080端口。Windows在“允许应用通过防火墙”里放行Python，或者在入站规则里临时放行8080，然后重试。
如果你用的是DevEco Studio的模拟器，就不存在局域网IP的问题，但模拟器访问宿主机通常有专用的映射地址，查一下当前模拟器的网络说明就行，不要照搬真机的IP方案。
3.4 权限与明文HTTP：调试期的小配置
HarmonyOS应用要访问网络，必须先在module.json5里申请ohos.permission.INTERNET权限。忘了这一步，请求会直接失败，而且有时候日志不直观。
{ "module": { "name": "entry", "type": "entry", "requestPermissions": [ { "name": "ohos.permission.INTERNET" } ] } }还有一个隐形问题：本地调试时服务器地址是http://明文，而HarmonyOS从某个版本开始对明文流量有限制。如果请求发起后一直报错提示不安全连接，要么临时在网络配置里放行明文流量，要么干脆把本地服务套一层HTTPS（开发环境也可以用openssl生成自签名证书，但真机上还要处理证书信任，比较麻烦）。
我的经验是：调试期优先处理明文HTTP的放行，把链路跑通，正式上线再统一换HTTPS，不要一上来就纠结证书。
4. 从触发更新到安装成功：调试检测的完整操作清单
环境搭好了，代码也写得差不多了，接下来按步骤把整个更新功能从头到尾测一遍。这一章我给出一套可复用的操作清单，每一步都带预期结果，方便自测也方便团队内部转交。
4.1 确认当前版本：先排除“装的不是你以为的包”
调试最怕的是你辛辛苦苦测了半小时，最后发现手机上装的包根本不是你以为的那个版本。所以第一步永远是把当前版本确认清楚。
手机上可以直接看应用“关于”页里的版本号，但更可靠的方式是用hdc命令行工具：
hdc shell bm dump -n 你的包名 | grep -E "versionCode|versionName"bm dump是鸿蒙设备侧的包管理命令，能直接看到已安装应用的版本信息。hdc工具在DevEco Studio的toolchains目录下，把它的路径加到环境变量里，或者直接在DevEco终端里执行。
这一条命令应该出现在你的调试肌肉记忆里，因为它能同时验证两件事：应用装没装上、装的是哪个版本。
4.2 触发更新并验证请求与返回
版本确认后，进入应用，执行检查更新的动作（点按钮或等自动触发）。此时打开本地更新服务器的终端窗口，应该能看到客户端发来的请求记录。我脚本里屏蔽了默认日志，如果你想观察请求，可以临时在do_GET里加一行print(self.path)。
这一步的验证点有三个：
- 客户端确实发出了带
versionCode参数的请求。 - 服务器返回的JSON能被客户端正确解析，没有类型转换之类的崩溃。
- 返回
hasUpdate: true时，界面弹出了更新提示框，版本号、更新说明文案和服务器返回一致。
如果提示框没弹出来，优先看客户端日志里解析是否异常，再看服务器返回的JSON格式是否符合预期。我遇到过一种情况：服务器返回的versionName是"1.0.2"，但客户端代码用了parseInt去转换，直接导致提示框崩溃，这种小问题在联调阶段特别容易发生。
4.3 下载阶段的进度与异常验证
提示框弹出后，点击“立即更新”，进入下载阶段。这时候你的本地服务器会开始传输hap文件。正常的现象是客户端出现进度条，或者通过日志能看到progress回调的receivedSize在增长。
建议刻意做两次异常测试：
- 测试一：下载过程中把手机WiFi断掉，观察客户端有没有走到失败分支，有没有给出“下载失败，请重试”之类的提示。很多团队只测顺风路，断网场景根本没人看。
- 测试二：服务器返回的
size字段故意写成错误的（比如比真实大小大很多），看客户端下载完成后会不会做大小校验。如果代码里直接跳过校验，这个问题会在用户身上以“下载完成但安装失败”的形式暴露。
下载完成的正常标准：日志看到progress达到totalSize，然后应用跳转到拉起安装的逻辑。你还可以在下载完成后用hdc进文件目录看一眼：
hdc shell "ls -l /data/app/el2/100/base/你的包名/haps/entry/cache/update/"注意不同SDK版本的沙箱路径规则可能不一样，最简单的是在代码里把下载路径打日志，然后用日志里的路径去查文件。
4.4 安装拉起、覆盖安装与结果确认
下载完成后的动作是拉起系统安装页面。操作到这一步，观察点有三个：
- 是否弹出了系统安装确认窗口。
- 点击确认后，安装是否报错（签名不一致、包已损坏等都会在这里暴露）。
- 安装完成后重新打开应用，显示的版本号是不是新版本。
重开应用后不要急着点“检查更新”，先用前面提到的bm dump确认版本号确实切换到了新版本，然后再点一次检查更新，此时服务器应该返回hasUpdate: false，界面提示“已是最新版本”。这一条闭环走完，整个更新功能才算真正合格。
这里再提醒一句：安装结果不要依赖startAbility返回的Promise，因为用户可能取消、也可能安装失败。一定要靠“安装后重查版本号”来判定结果，这是最稳的检测方式。
4.5 全程日志观测：DevEco Log 和 hdc/hilog 双管齐下
调试全程建议开两个日志通道：
- DevEco Studio的Log面板，优点是可以直接看到
console.info日志和崩溃堆栈，适合在开发调试期看业务逻辑。 - 命令行
hdc shell hilog，优点是不受DevEco运行状态影响，即使应用是手动安装的也能看到系统侧日志。
常用命令大概是：
hdc shell "hilog | grep UpdateManager"我习惯在代码里把每个阶段的关键日志都加上UpdateManager前缀，这样排查问题时一行命令就能过滤出完整链路。日志一定要舍得打，更新功能本身不复杂，怕的是故障时靠猜。
5. 未上架调试特有的大坑：签名、版本号、路径与日志断连
这一章是干货中的干货，全是我自己或团队在未上架状态下调试更新功能时真实踩过的坑。每一个都足以让半天调试时间白费，希望你提前绕开。
5.1 签名不一致：调试包与发布包泾渭分明
现象很典型：下载进度100%，系统安装页面也弹了，点确认之后直接报“安装失败”。看日志，多半是签名校验失败。
根因在于：你用DevEco Studio的自动签名打了一个Debug包安装到手机，但服务器上放的新版本hap用了上传签名或者别的证书签名。两个包签名不一致，系统拒绝覆盖安装。
这类问题在未上架调试阶段特别容易踩，因为你根本不会去注意签名。解决方案有两个：
- 整个调试期统一签名。Debug包和测试包都用DevEco的自动签名，保证覆盖安装能过。
- 如果就是要验证“签名不一致”时的表现，那就把这次当成一个独立的测试用例，明确预期结果就是安装失败，而不是让它混在正常链路测试里干扰判断。
另外要记住：真机连DevEco调试时，每次Run都相当于重新安装。如果你在设备上手动装了一个测试包，再点DevEco的Run，它会先卸载再安装，这是正常的，不要当成更新功能的问题。
5.2 版本号比较：字符串排序坑了所有人
检查更新时最常见的低级bug就是用versionName做比较。字符串比较有一个人尽皆知的坑："1.0.9" > "1.0.10"，因为按字典序比较时，"9"比"1"大。
所以再次强调：逻辑判断只认整数versionCode，versionName只做展示。服务器返回的字段要设计成同时给versionCode和versionName，客户端判断用前者，展示用后者，两不耽误。
还有一个细节：versionCode在HarmonyOS里是整数，不要用负数，不要用超长数字。我曾见过一个团队为了配合灰度策略把版本号写成1000000321这种很长的大数，虽然没出事，但完全没有必要，版本号只要保证单调递增就行。
5.3 文件路径与 URI：拉到安装界面却找不到文件
下载是成功的，文件也确实写进去了，但拉起安装时系统提示“找不到文件”。这种情况多半是传给startAbility的参数不对。
HarmonyOS的沙箱机制下，应用能访问的是自己的filesDir、cacheDir等目录。如果你把更新包下载到了这些目录之外，或者构建Intent时用了不正确的路径格式，系统侧自然找不到。调试时我的做法是：
- 下载完成后立刻打一条日志，打印完整路径和文件大小。
- 用hdc进沙箱目录实际看一眼文件是否存在。
- 确保传给系统的路径和日志里打印的完全一致。
另外，不同SDK版本对打开文件的协议支持可能不同，有的版本要求传file://协议，有的直接传绝对路径就行。这个以你工程对应的SDK文档为准，不要盲抄网上旧代码。
5.4 DevEco 重新 Run 打断沙箱：更新测到一半就清场
这个坑尤其隐蔽。你正在真机上测更新，下载完了，准备点系统安装页面。这时候如果你不小心在DevEco Studio里点了Run，或者手机上重新装了应用，沙箱目录会被系统清理，刚才下载的hap包直接没了。安装页面即使弹出来，也找不到目标文件。
解决办法是：测更新链路时，不要中途重新Run工程。如果需要重装，用hdc install -r覆盖安装，避免清空沙箱。我自己还养成了一个习惯——下载下来的更新包文件名带版本号，比如app-1.0.2.hap，这样就算文件真的被清了，日志里也能明确看到是谁清掉了链路。
5.5 “已是最新”测不出来：等于号语义要提前定
更新检测逻辑里有一个产品层面容易忽略的点：当客户端版本号等于服务器版本号时，到底显示什么？大多数实现是if (serverVersionCode > currentVersionCode) 有更新 else 无更新，所以等于时显示“已是最新”。
但在调试阶段，你为了验证“已是最新”的展示，必须把服务器版本号改成和你当前安装版本一致。很多团队只准备了“有更新”的包，一测到“已是最新”就被卡住，以为功能坏了。其实不是，是测试数据没设计好。
我建议准备三组测试数据：服务器版本号大于当前（有更新）、等于当前（已是最新）、小于当前（异常场景，验证客户端能兜住）。三组都过，才说明版本比较逻辑是真的稳了。
6. 调试环境回归上线：更新策略的取舍与收尾建议
本地链路完全跑通只是第一步。真要上架，你还需要面对“官方应用市场通道”和“自建通道”的取舍。这里我给一点实际建议。
6.1 上架前用官方更新通道回归一遍
如果正式产品打算走AppGallery的应用内更新SDK，上架前必须用官方SDK完整回归一遍更新流程。注意这时候你已经上架或者在AGC后台配置了灰度版本，SDK才能拉到列表。
回归时重点验证三件事：
- SDK的更新策略（强制更新、非强制更新）是否符合产品定义。
- 权限弹窗和隐私说明是否合规，应用市场审核对这部分很敏感。
- 从旧版本升到新版本后，应用数据是否保留。更新不同于卸载重装，用户数据应该原样保留，这一点在自建通道里可能靠覆盖安装天然成立，但在官方SDK里也需要确认一次。
不要以为本地自建链路测通了官方SDK就一定通，API不同、鉴权方式不同、版本分发策略也不同，花半天时间回归是值得的。
6.2 自更新通道要不要保留：我的取舍建议
很多团队因为要做灰度、要绕开市场审核周期，倾向于保留自建更新通道。我的看法是：调试期用自建通道没问题，但正式环境优先走官方应用内更新，除非你能保证自建通道的签名校验、HTTPS传输、包源安全都做到位。
自建通道最大的风险不是技术上跑不通，而是用户从“应用市场版”升级时，道德信任和安全感知很微妙。万一自建通道被中间人攻击或者包源被污染，影响的是整个应用的口碑。应用市场审核看到应用有自更新逻辑，也会重点检查，这是另一个不可控因素。
如果你最终还是决定保留自更新，至少做到三点：下载URL一律HTTPS、安装前校验文件MD5或签名、每次更新前弹明确说明。这三点能帮你规避九成风险。
6.3 最后小技巧：把更新地址做成构建期可配置
调试期你用的服务器地址是http://192.168.1.100:8080，上线时要改成正式域名。最怕的是开发人员上线时忘了改地址，导致正式用户全部连到内网IP。我建议把更新接口地址做成按构建类型配置：
- Debug构建：读本地环境里的配置，指向本地或测试服务器。
- Release构建：只允许读正式域名，调试地址硬编码不进Release逻辑。
实现方式很简单，在工程里用一个常量文件区分buildMode，或者在CI/CD环境变量里注入地址。这个改动成本不大，但能彻底杜绝“上线忘改地址”这种低级事故。
整个流程测下来你会发现，HarmonyOS应用更新功能的调试难点不在“上架”，而在你对签名、沙箱路径、网络策略这些基础工作的熟悉程度。把这些基础打牢，未上架阶段测出来的结果，基本就能代表线上行为。以后不管产品怎么变，只要版本号管理和签名策略不乱，更新功能这道关就守得住。
