本地构建流畅，CI却频繁失败，根源常在环境差异。排查应先对齐Node、Hvigor、SDK版本，检查环境变量与依赖锁（oh-package-lock.json5），确保--frozen-lockfile启用。统一build-profile.json5中签名与构建参数，避免Debug/Release差异。关键：将环境检查、双模式构建、输出验证写入CI脚本，实现自动化拦截，从“救火”到“预防”，让构建

某页面反复进出导致定时器与监听持续运行，日志刷屏且内存泄漏。根源在于任务创建（onPageShow）与清理（aboutToDisappear）生命周期不匹配，页面隐藏未销毁时任务未及时停止。修复方案是将所有定时器与监听统一交由TaskRegistry管理，页面hide时调用stopAll()集中清理，避免重复注册，并通过日志、内存监控验证清理效果。关键在于任务生命周期与页面生命周期对齐，收口管理提

项目初期使用Preferences存储数据虽便捷，但随着收藏、草稿等业务复杂化，其全量读写与逻辑散落问题凸显。为解决数据层职责不清、查询维护困难等问题，转向使用HarmonyOS的RelationalStore（基于SQLite）管理结构化数据。通过合理设计表结构、引入Repository模式封装数据库操作，实现页面与数据访问解耦。同时注重异常处理、初始化顺序与资源管理，确保稳定性。后续需关注分页

本文分享了在应用数据库升级中应对表结构变更的实战经验，强调在不丢失用户数据的前提下，通过版本号机制实现渐进式迁移，确保从任意旧版本升级均无遗漏。关键措施包括：使用onUpgrade按版本逐步迁移、所有变更在事务中执行以保障一致性、加字段后立即回填默认值、批量操作采用事务提升性能与原子性，并通过异常捕获与回滚机制防止数据损坏。同时提醒注意大表迁移性能、并发写冲突、事务嵌套及数据库损坏恢复等边界问题，

上一篇把后台下载跑起来了，Wi-Fi 环境下一切正常。结果一放到真实手机上测，问题就全来了——用户在地铁里下载，信号忽强忽弱；出门的时候 Wi-Fi 断了切到 4G；网络抖一下任务就失败了，用户还得手动点重试。正常网络下基本看不出问题，一切到弱网就暴露出来了。这篇就讲讲真实网络环境下，下载任务怎么扛住断网、切网、失败重试这些乱七八糟的情况。说白了，这里要解决的就是两件事：网络不好的时候任务别丢，网

之前做了个应用，要下载一些离线资源包。文件不大的时候，直接用 http 请求下，切个后台也没事。后来换成 500MB 的资源包，问题就全出来了——用户切到后台，下载直接停了；锁屏之后再回来，连接断了；网络抖一下，整个下载任务就挂了，得从头再来。普通的 http 请求跑前台没问题，真要跑大文件后台下载，根本扛不住。后来换了 RequestAgent，把下载任务交给系统管理，才算是把这件事真正做稳了。