这一篇收尾不再只看代码而是看一个 App 从 Demo 走向交付还缺什么。构建配置、截图、商店文案、隐私说明、免责声明、上架前检查这些东西不写代码但决定项目能不能像产品一样交出去。项目落点构建配置build-profile.json5、entry/build-profile.json5模块配置entry/src/main/module.json5发布截图doc/release/screenshots商店文案doc/release/store-listing-draft.md隐私政策doc/release/privacy-policy.md预发布检查doc/release/prelaunch-checklist.md读完这一篇你可以复用一套 HarmonyOS 单机 App 的交付清单代码、资源、文案、隐私、免责声明和测试路径一起闭环。从 Demo 到可发布还差什么一个 App 能跑起来不等于能发布。《疆域纪行》作为离线旅行攻略 App除了页面和功能还准备了交付物解决的问题对应目录截图证明核心页面真实可用doc/release/screenshots商店文案让用户理解应用价值doc/release/store-listing-draft.md隐私政策说明本地数据边界doc/release/privacy-policy.md预发布清单防止漏测关键路径doc/release/prelaunch-checklist.md很多个人项目卡在“代码写完”这一步其实离可交付还差文案、截图、隐私和验证路径。应用介绍文档商店文案草稿隐私政策预发布检查清单应用截图release 包输出签名构建配置这篇不展开讲具体平台提交流程而是从工程角度复盘一个 HarmonyOS 单机 App 要走向可发布需要补齐哪些环节。构建配置先确认 Stage 模型和 SDKentry/build-profile.json5中可以看到{ apiType: stageMode, buildOption: { resOptions: { copyCodeResource: { enable: false } } } }这说明项目使用 Stage 模型。对于当前 HarmonyOS 应用开发Stage 模型是主流选择Ability、页面加载、上下文获取都围绕它展开。根目录build-profile.json5中还有产品配置products: [ { name: default, targetSdkVersion: 6.1.0(23), compatibleSdkVersion: 6.0.2(22), runtimeOS: HarmonyOS } ]写技术文章时可以说明目标 SDK 和兼容 SDK但不要把本机证书路径、证书密码、profile 路径等敏感信息贴出去。发布文章里如果要展示签名配置建议写成signingConfigs: [ { name: default, type: HarmonyOS, material: { storeFile: your-store-file, keyAlias: your-key-alias, profile: your-profile } } ]技术分享要讲方法不要泄露真实凭据。模块配置支持设备要和体验匹配module.json5中声明deviceTypes: [ phone, tablet, 2in1 ]这意味着商店材料和测试也应该覆盖这些设备形态。如果只在手机模拟器上看过就不要在文章或商店文案里过度强调平板深度适配。比较稳妥的表达是当前版本以手机竖屏体验为主布局已预留 tablet 和 2in1 设备支持后续会继续增强大屏分栏体验。技术复盘中诚实描述边界比夸大能力更专业。发布材料截图和文案都要准备项目已经有发布截图doc/release/screenshots/ ├── 01-home.jpeg ├── 02-explore.jpeg ├── 03-detail.jpeg ├── 04-route.jpeg └── 05-mine.jpeg这五张图覆盖了核心路径首页推荐探索筛选详情页路线规划我的 / 设置这也是写 CSDN 技术文章时很好的配图顺序。技术文章不是只能贴代码适当放页面截图能帮助读者理解代码背后的产品目标。商店文案草稿在doc/release/store-listing-draft.md隐私政策在doc/release/privacy-policy.md预发布检查在doc/release/prelaunch-checklist.md这些文档说明项目已经从“开发完成”往“交付完成”推进了。单机离线 App 的隐私表达《疆域纪行》的特点是无需登录无需联网即可浏览核心内容收藏、搜索历史、行程仅保存在本机这种 App 的隐私风险相对低但仍然应该说明清楚是否采集个人信息。是否上传收藏或搜索历史。是否请求定位、相机、相册等权限。本地数据如何保存。卸载 App 后本地数据会怎样。技术文章里可以强调这一点local-first 不只是技术架构也是一种隐私友好的产品设计。内容准确性和免责声明旅行攻略类 App 最容易踩的坑不是代码而是内容变化。项目里多处加入了类似说明本应用内容为离线旅行参考信息景区开放时间、门票、交通、餐厅营业状态等信息可能变化请以当地官方公告和实际情况为准。这非常必要。因为第一版内容是离线内置不能保证实时更新。尤其是景区开放时间门票价格路况餐厅营业状态边境线路规定都可能变化。对开发者来说免责声明不是“推卸责任”而是明确产品边界。上架前的功能检查建议至少覆盖这些路径冷启动进入首页。首页点击景点进入详情。详情页收藏再返回收藏页查看。详情页加入行程在路线页查看摘要。探索页搜索“喀什”“赛里木湖”“大盘鸡”。探索页切换景点、美食、路线、城市。筛选无结果时显示空状态。关闭并重启 App确认收藏和搜索历史仍在。系统返回键从详情页返回主页面。所有底部按钮不遮挡内容。这些测试不依赖后端很适合在发布前手动跑一轮。工程复盘这个项目最值得借鉴的点第一数据建模清楚。AtlasItem、RouteItem、CityItem、LocalAppState把内容和用户状态分开后续扩展有基础。第二页面主流程简单。activeTab控制主 TabdetailId/detailKind控制详情页没有过早引入复杂路由。第三本地持久化封装在服务层。页面不直接写 Preferences key而是通过LocalAppStore.ets读写状态。第四视觉完成度较高。大图、渐变、卡片、时间轴、空状态、启动页都已经具备产品感。第五发布意识比较完整。截图、商店文案、隐私政策、免责声明都已经准备。还可以继续优化的方向如果继续迭代我会优先做这些把硬编码颜色抽成主题常量。把大文件Index.ets拆成components和独立页面。为路线行程设计更完整的数据结构。增加内容版本号和迁移逻辑。支持平板左右分栏布局。搜索支持标签和拼音。本地数据支持导出备份。增加更多真实内容和图片来源说明。这不是因为当前版本不好而是从 MVP 到正式产品的自然演进。优化顺序也有讲究先拆主题常量和组件让维护成本降下来再增强搜索、路线编辑和导出让功能变强最后再考虑联网更新和离线包因为那会引入内容版本、同步和审核边界。按这个顺序走项目不会因为一次性升级过多而失控。验证清单检查项操作方式通过标准release 输出包存在且来源清楚对照项目文件或真机/模拟器操作结果符合文章描述商店截图覆盖首页、探索、详情、路线、我的对照项目文件或真机/模拟器操作结果符合文章描述隐私说明明确无登录和本地保存范围对照项目文件或真机/模拟器操作结果符合文章描述文章中的签名材料全部脱敏对照项目文件或真机/模拟器操作结果符合文章描述上架前手动路径已跑通对照项目文件或真机/模拟器操作结果符合文章描述常见问题和处理问题现象优先排查处理方式构建配置能跑但文章不能贴检查是否含证书路径和密码用脱敏示例讲方法审核关注内容时效在详情和关于页写免责声明动态信息统一描述为参考截图和功能不一致先更新截图再写文案截图覆盖核心用户路径本系列总结10 篇文章从一个真实 HarmonyOS 离线 App 出发完整覆盖了工程入口和 Stage 模型ArkTS 数据建模ArkUI 首页和底部导航本地搜索与筛选Preferences 持久化沉浸式详情页路线时间轴图片资源与启动体验适配和稳定性发布准备和项目复盘如果你正在学习 HarmonyOS不建议只停留在零散 API。选择一个真实小产品把数据、页面、状态、资源、发布都走一遍成长会快很多。《疆域纪行》这个项目的价值就在这里它不是最复杂的 App但它把一个内容型 HarmonyOS 应用从 0 到 1 的关键链路都串起来了。