先说问题依赖版本漂移通常不是编译器突然坏了HarmonyOS 7 / API 26 项目升级时除了 SDK 和 build-profile依赖版本也很容易出问题。最常见的现象是A 电脑能构建B 电脑失败昨天 CI 通过今天同一分支突然失败本地删掉缓存后报错位置变了。这类问题不要一上来就怀疑业务代码。先查 oh-package.json5、oh-package-lock.json5 和依赖解析结果有没有漂移。环境和版本项目取值系统方向HarmonyOS 7.0.0 / API 26工程方向DevEco Studio、Hvigor、ohpm 依赖管理关注点依赖版本漂移、锁文件检查、CI 构建稳定性验证方式版本范围失败案例 锁文件通过案例问题是怎么发生的很多项目早期会在依赖里写版本范围看起来方便升级{dependencies:{ohos/some-lib:^1.2.0,ohos/ui-kit:2.0.0}}问题是版本范围会让“今天装出来的依赖”和“上次构建用的依赖”不一定完全一样。升级到 HarmonyOS 7.0.0 / API 26 后这种漂移会更难排因为你同时在改 SDK、改配置、改依赖。案例一先把风险版本找出来可以写一个提交前检查先把 ^、~、 这类范围版本找出来。typeDependencyMapRecordstring,stringfunctionfindFloatingVersions(dependencies:DependencyMap){constfloating:Array{name:string;version:string}[]for(const[name,version]ofObject.entries(dependencies)){if(/^[~^]/.test(version)||version.includes()||version.includes(*)){floating.push({name,version})}}returnfloating}把前面的依赖放进去constdependencies{ohos/some-lib:^1.2.0,ohos/ui-kit:2.0.0,ohos/safe-core:3.1.4}console.log(findFloatingVersions(dependencies))输出[ { name: ohos/some-lib, version: ^1.2.0 }, { name: ohos/ui-kit, version: 2.0.0 } ]这个输出能把风险点先圈出来。不是说所有范围版本都不能用而是发版、审核、活动 Demo、多人协作项目里关键依赖不要让它自己漂。案例二锁文件怎么参与验收只检查 oh-package.json5 还不够还要确认 lock 文件里解析出来的版本和期望一致。可以把关键依赖做成白名单。typeLockItem{name:string;resolved:string}functioncheckLockedVersions(lockItems:LockItem[],expected:DependencyMap){constproblems:string[][]for(const[name,version]ofObject.entries(expected)){constactuallockItems.find(itemitem.namename)if(!actual){problems.push(name 没有出现在锁文件里)continue}if(actual.resolved!version){problems.push(name 解析版本不一致actual.resolved ! version)}}returnproblems}测试一个通过案例constlockItems[{name:ohos/safe-core,resolved:3.1.4},{name:ohos/ui-kit,resolved:2.4.1}]console.log(checkLockedVersions(lockItems,{ohos/safe-core:3.1.4}))输出[]空数组表示关键依赖符合预期可以继续构建。CI 里怎么落地我会把检查分两步放到 CI 前面functionassertNoDependencyRisk(dependencies:DependencyMap,lockItems:LockItem[]){constfloatingfindFloatingVersions(dependencies)constlockProblemscheckLockedVersions(lockItems,{ohos/safe-core:3.1.4})constproblems[...floating.map(itemitem.name 使用了范围版本 item.version),...lockProblems]if(problems.length0){thrownewError(problems.join(\n))}}这段脚本不需要知道整个构建细节只负责在构建前挡住明显不稳定的依赖状态。几种方案怎么选方案优点问题适合场景允许范围版本升级快构建结果不够稳定个人 Demo手动检查 lock成本低容易忘临时排查CI 检查关键依赖稳要维护白名单正式项目全量依赖审计最严成本高大项目、发版前我的选择是第三种。关键依赖锁住其它依赖按风险逐步收紧。这样升级 API 26 时不会把依赖漂移和 SDK 兼容问题混在一起。最后怎么验收我会看四个结果范围版本能被发现关键依赖必须出现在 lock 文件里解析版本和期望不一致时 CI 失败报错信息能直接指出依赖名和版本。HarmonyOS 7.0.0 / API 26 升级不是只改一处版本号。SDK、工程配置和依赖解析要一起收住。依赖不稳定后面构建失败、审核复现失败、线上偶现问题都会变得更难查。