鸿蒙缓存逻辑

1. 个人怎么用好git。
2. 团队配合怎么分支，怎么合并，怎么约束等。
3. git 自动化构建项目。

这种情况我一般会先怀疑“构建产物缓存”，不一定是手机里的应用缓存。

因为你在 IDE 里直接构建到真机已经验证 bug 消失，但 Git 提交后统一打包又出现，说明两条构建链路很可能拿到的代码或产物不完全一样。

重点排查这几个地方：

1. 统一打包机器有没有 build、hvigor、模块产物缓存，增量编译可能继续用了旧产物。可以先做一次 clean build 验证。
2. 检查统一打包实际 checkout 的 commit，确认修复代码真的已经包含进去，尤其是多分支、子模块或者 cherry-pick 的情况。
3. 看统一打包的构建参数。比如 build profile、product、模块配置不同，可能实际编译的不是 IDE 测试的那套代码。
4. 如果使用了三方库、HAR/HSP，重点检查有没有引用旧版本产物。源码已经改了，但依赖仍然指向旧 HAR/HSP，也会出现“本地好了，统一打包还是有问题”。
5. 最后再查设备侧缓存。统一打包出来的新包安装时如果没有彻底覆盖旧数据，像数据库、Preferences、文件缓存这些业务数据仍然会保留。不过这种情况通常不会导致“代码 bug 又回来”，除非 bug 本身和持久化数据有关。

可以让 CI 每次正式构建先执行一次完整 clean，然后把最终产物的 commit ID、版本号、构建时间打印到日志里。这样很快就能判断到底是“打包用了旧代码/旧产物”，还是“新代码读取了旧业务数据”。

按照你描述的“IDE 构建已经修复，Git 统一打包又复现”来看，我会优先查 CI 的增量构建缓存和 HAR/HSP 等依赖产物。

清理下编译缓存跟构建包缓存试试看

问题本质：很多人把"缓存"和"持久化"混为一谈。鸿蒙里：

• @StorageLink / Preferences 是同步落盘的小 KV，适合配置项，不适合大对象；
• 大文件/图片缓存应放 cacheDir，且系统低内存时会被清；
• 网络层缓存要自己控制有效期。

常见"缓存逻辑不生效"根因：

1. Preferences 写完必须 flush() 才真正写盘，否则只在内存在。

const pref = dataPreferences.getPreferences(this.context, 'app');
pref.put('token', value);
await pref.flush();   // 关键标记：PreferenceCacheV2 的落盘动作

2. cacheDir 里的文件不保证长期存在，别用它当持久存储；要持久用 filesDir。

3. 想做"内存+磁盘"二级缓存，推荐 @StorageProp 配合手动写 filesDir，或在 API 12+ 用 cached 装饰的状态。

验证：改完杀进程再进，能读回说明落盘成功；读不回说明只写了内存（漏 flush 或写到了 cacheDir）。

这个有可能是构建的时候有缓存残留问题。

如果是通过 IDE 直接构建到真机时，DevEco Studio 通常会自动处理增量编译缓存，确保最新代码生效。

但通过 CI/CD 流水线或命令行统一打包时，如果构建环境中的缓存未被正确清理，hvigor 的增量编译机制可能会复用旧的编译产物，导致新代码没有被真正编译进最终包中。

推荐方案：在 CI/CD 流水线的打包步骤前，增加清理操作进行强制清理。

本地 IDE → 真机时，DevEco 一般会检测代码和资源变化，只重编有改动的文件；但 CI 为了提速，可能缓存了 `.hvigor/`、`build/`、`oh_modules/`，甚至复用了旧的 HAR/HSP 产物，导致最终 HAP 中的 `.abc` 或资源文件没有更新。

建议按下面方式排查和处理：

rm -rf .hvigor/ build/ oh_modules/
hvigorw --no-daemon clean
hvigorw --no-daemon assembleHap --mode release

如果项目包含多个本地模块，还要确认上游 HAR/HSP 已重新构建；发版构建建议固定使用 `clean + build`，不要直接依赖增量缓存。构建完成后，也可以解包 HAP，检查其中的 `.abc`、`resources.index` 等文件是否包含最新代码和资源。

如有帮助，欢迎给个采纳。