7.4 KiB
Continental Retail APP | uni-app / uni-app x PoC 验证结论
1. 验证说明
本文档记录经典 uni-app 与 uni-app x（蒸汽模式）在同一业务范围下的 PoC 结果，重点判断：
- 三端工程是否能构建、安装和运行
- 常用业务能力是否可接入
- 鸿蒙平台的问题能否被复现和定位
- 一名前端能否独立完成维护和发布
验证环境：App-Android、App-iOS、App-鸿蒙；本文当前重点记录 uni-app x 鸿蒙结果。
2. 验证结果
2.1 三端工程
结论：通过。
鸿蒙本地打包、unsigned 包构建、DevEco Studio 安装启动均已跑通，构建链路无阻塞。
证据：
2.2 登录与会话
结论：通过。
鸿蒙下 Storage 读写稳定；onShow/onHide 生命周期可用；App 从后台恢复后能够刷新过期会话，退出登录可清理存储。
证据：
注：当前 PoC 使用普通 Storage，正式版仍需评估鸿蒙加密存储能力。
2.3 扫码与权限
结论：部分通过。
uni.scanCode 可以拉起鸿蒙扫码界面，说明扫码 API、页面调用链和相机能力接入基本可用。系统出现 Limited access to camera，表明相机处于受限授权状态；当前截图尚未证明二维码/条码结果回传成功，权限被回收后的二次申请也未完成验证。
证据：
2.4 定位
结论：失败/受阻。
uni.getLocation({ type: 'wgs84' }) 调用后返回：
getLocation:fail Failed to get provider
虽然工程已声明 uni-location 和 ohos.permission.LOCATION，但当前 Harmony 环境没有返回可用定位 provider，未获得经纬度和精度。因此目前不能确认 uni-app x 鸿蒙定位能力可用于正式业务，需要在具备定位服务的真机上复测，并继续核对框架、插件和 Harmony 版本兼容性。
证据：
2.5 推送与深链
结论：推送受阻，应用内深链可单独验证。
调用 getPushClientId 返回：
getPushClientId: fail
errCode: 15032
未获得有效 Push Client ID，因此 onPushMessage、前后台到达、关闭态通知点击和通知深链无法形成完整验证。页面内的 query 参数跳转只能验证应用内路由承接，不能替代真实通知点击测试。
证据：
2.6 文件链路
结论：基础链路通过。
相册选择能够返回临时文件路径并在应用内预览；下载能够返回 HTTP 状态码和本地临时路径，下载结果也能正常渲染。拍照、PDF/Office 外部打开和复杂 URI 兼容性仍需真机复测。
证据：
2.7 ERP H5
结论：基础链路通过。
本地 H5 加载和 H5 -> Native JSBridge 通信已验证。鸿蒙 WebView 注入的是 window.__uniapp_x_，不是常见的 window.__uniapp_x_postMessage，因此需要按平台做兼容判断。真实 ERP、SSO、网络环境和长期后台恢复仍需复测。
证据：
2.8 维护演练
结论：需人工介入。
修改代码后重新本地打包鸿蒙工程，若上一次生成的工程目录仍存在，会出现无法删除旧工程的错误；必须手动清理后才能重新打包，增加了单人维护和发布成本。
证据：
3. 结论汇总
| 验证项 | uni-app x 鸿蒙结论 | 状态 |
|---|---|---|
| 三端工程 | 本地打包、unsigned 构建、DevEco 安装启动通过 | 通过 |
| 登录与会话 | Storage、生命周期、前后台会话恢复通过 | 通过 |
| 扫码与权限 | 可拉起扫码界面；相机为受限授权，结果回传和权限恢复待验证 | 部分通过 |
| 定位 | Failed to get provider，未获得定位结果 |
失败/受阻 |
| 推送与深链 | getPushClientId 返回 errCode: 15032；应用内深链可单独验证 |
受阻 |
| 文件链路 | 相册、下载、本地预览基础链路通过 | 基础通过 |
| ERP H5 | 本地 H5 与 JSBridge 基础通信通过 | 基础通过 |
| 维护演练 | 重复打包前需手动删除旧工程目录 | 需人工介入 |
总体判断： uni-app x 鸿蒙的工程构建、会话、文件和基础 WebView 链路可行；扫码已能进入系统能力，但结果和权限恢复仍需补测；定位和推送分别受到 provider 获取失败、Push Client ID 错误 15032 阻断，不建议在问题未明确前直接承诺正式业务可用。
4. Uni-app x 开发问题
以下问题不属于业务功能本身，但会直接影响开发效率、工具链选择和单人维护成本。
4.1 HBuilderX AI 工具模型支持有限
现象： HBuilderX 自带 AI 开发工具可选择的模型较少，目前主要只有 DeepSeek 和智谱两类模型，无法满足不同团队对模型能力、稳定性和部署方式的多样化需求。
影响： 团队难以统一接入现有模型账号或第三方模型服务，AI 编程工具的扩展性和可替代性有限。
证据：
4.2 HBuilderX AI 工具使用成本较高
现象： HBuilderX AI 工具采用订阅收费模式，套餐价格较高。
影响： 若团队多人长期使用，订阅费用会增加整体研发成本；正式引入前需要结合使用频率、额度和团队规模评估投入产出比。
证据：
4.3 鸿蒙工程重复打包需要人工清理
现象： 修改代码后重新打包鸿蒙工程时，可能无法自动删除上一次生成的工程目录；重新打包前有时需要手动删除旧工程或旧包目录。
影响： 重复构建流程不够顺畅，增加了构建失败排查和单人发布的额外操作成本。
证据：
4.4 打包过程反馈不清晰
现象： 打包出错时，HBuilderX 的过程反馈不够明确；有时不会清晰提示打包是否已经结束，进度展示也不明显。
影响： 开发者难以判断当前任务是在执行、等待还是已经失败，容易重复点击或误判构建状态，降低开发体验和问题定位效率。
证据：
4.5 本章结论
结论：开发工具链和鸿蒙打包体验存在明显改进空间。
HBuilderX 内置 AI 工具存在模型选择少、订阅成本较高的问题；鸿蒙重复打包存在旧工程清理问题，打包过程的进度和结束状态反馈也不够清晰。这些问题不会直接否定 uni-app x 的业务开发能力，但会增加团队工具成本、构建等待成本和单人维护成本，应在正式项目中纳入工具链和发布流程评估。