我手机上的App图标颜色很杂乱，换什么壁纸都觉得不好看。

后来用这个生成了一张非常深的灰色壁纸，一下就显得所有图标都和谐了。

https://iris.findtruman.io/web/wallpaper_generator?share=L

我在抖音上看到很多超棒的旅游风景短片，想用来做动态壁纸。

用这个下载了高清无水印版，设置成壁纸后，手机屏幕都变得赏心悦目了。

https://iris.findtruman.io/web/dy-qsy?share=L

我在两个浏览器之间用它来传文件。比如在Chrome上登录了账号，想把下载的文件发到另一个没登录的浏览器里，用这个就特别快。

https://iris.findtruman.io/web/lan-drop?share=L

我用它给我的代码编辑器生成了一张深灰色的背景图，替换掉了默认的黑色。感觉长时间看屏幕，眼睛舒服多了，代码都看得更清楚了。

https://iris.findtruman.io/web/wallpaper_generator?share=L

基本背景

鸿蒙元服务不需要自己处理隐私弹窗，鸿蒙强制要求结束隐私协议托管，关联 client_id 之后会自动弹窗隐私协议，下面内容主要针对鸿蒙应用开发用户。

鸿蒙应用上架需要配置隐私协议、用户协议。这部分内容可参考 鸿蒙如何设置隐私协议弹窗

这里做技术实现说明。

内容已迁移到 鸿蒙如何设置隐私协议弹窗

补充：编写 uts 插件

如果应用需要提供不同意隐私协议也要提供基础内容浏览服务，可参考下面 uts 代码单独处理用户动态接受、拒绝隐私协议，主动唤起隐私协议相关逻辑。

编写 uts 插件，完成弹窗，这里提供代码片段。

新建 uts 插件，比如 hamrony-privacy-dialog ，编辑 uni_modules/harmony-privacy-dialog/utssdk/app-harmony/index.uts

填写下面代码，这段代码导出了三个方法，和官方的 ets 代码完全一致，检查隐私协议信息、获取签署状态、主动唤起隐私弹窗。页面中引入代码调用即可。

import { privacyManager } from '@kit.AppGalleryKit';  
// import { hilog } from '@kit.PerformanceAnalysisKit';  
import { BusinessError } from '@kit.BasicServicesKit';  

export const getInfo = () => {  
    let err = ''  
    try {  
        let appPrivacyManageInfo : privacyManager.AppPrivacyMgmtInfo = privacyManager.getAppPrivacyMgmtInfo();  
        console.info(0, 'TAG', "Succeeded in getting AppPrivacyManageInfo type: " + appPrivacyManageInfo["type"]);  
        let privacyLinkInfoArray : privacyManager.AppPrivacyLink[] = appPrivacyManageInfo.privacyInfo;  
        console.info(0, 'TAG', "Succeeded in getting AppPrivacyManageInfo size = " + privacyLinkInfoArray.length);  
        for (let i = 0; i < privacyLinkInfoArray.length; i++) {  
            console.info(0, 'TAG', "Succeeded in getting AppPrivacyManageInfo type = " + privacyLinkInfoArray[i]["type"] + ", version = " + privacyLinkInfoArray[i]["versionCode"] + ", url = " + privacyLinkInfoArray[i]["url"]);  
        }  
    } catch (error) {  
        err = error.message  
        console.error(0, 'TAG', "GetAppPrivacyManageInfoPublic exception code: " + error.code + ", exception message: " + error.message);  
    }  
    return err  
}  

export const getStatus = () => {  
    try {  
        let appPrivacyResults : privacyManager.AppPrivacyResult[] = privacyManager.getAppPrivacyResult();  
        console.info(0, 'TAG', "Succeeded in getting AppPrivacyResult size = " + appPrivacyResults.length);  
        for (let i = 0; i < appPrivacyResults.length; i++) {  
            console.info(0, 'TAG', "Succeeded in getting AppPrivacyResult type = " + appPrivacyResults[i]["type"] + ", version = " + appPrivacyResults[i]["versionCode"] + ", result = " + appPrivacyResults[i]["result"]);  
        }  
    } catch (error) {  
        console.error(0, 'TAG', "GetAppPrivacyResultPublic exception code: " + error.code + ", exception message: " + error.message);  
    }  
}  
export const requestPrivacy = () => {  
    try {  
        const uiContext = UTSHarmony.getUIAbilityContext()  
        // const uiContext = this.getUIContext().getHostContext() as common.UIAbilityContext;  
        privacyManager.requestAppPrivacyConsent(uiContext).then((consentResult : privacyManager.ConsentResult) => {  
            let appPrivacyResults : privacyManager.AppPrivacyResult[] = consentResult["results"];  
            for (let i = 0; i < appPrivacyResults.length; i++) {  
                console.info(0, 'TAG', "GetAppPrivacyResult type = " + appPrivacyResults[i]["type"] + ", version = " + appPrivacyResults[i]["versionCode"] + ", result = " + appPrivacyResults[i]["result"] + ", signingTimeStamp = " + appPrivacyResults[i]["signingTimeStamp"]);  
            }  
        }).catch((error : BusinessError<Object>) => {  
            console.error(0, 'TAG', `requestAppPrivacyConsent failed, Code: ${error.code}, message: ${error.message}`);  
        });  
    } catch (error) {  
        console.error(0, 'TAG', "requestAppPrivacyConsent exception code: " + error.code + ", exception message: " + error.message);  
    }  
}

4 页面中引入

    import {  
        getInfo,  
        getStatus,requestPrivacy  
    } from '@/uni_modules/harmony-privacy-dialog'

全职在家承接外包，多年外包经验，个人开发者，绝对实惠靠谱，有很多款线上应用(度是自己开发的，自己独立完成，可查)

可做商城类，社交类，工具类，任务平台类，mes 类，扫码收银/分账交易类 等，除了游戏和带颜色的，其他度可以开发

可承接安卓/IOS、各个端的小程序、H5网页、PC网页开发，从前端到后端，我全度会，一条龙服务

掌握技术
前端：uniapp 、uniappx、vue
后端：Golang 、php

uniapp 及 uniappx 开发的作品均有上架appstore

小程序方面也有很多

有需要开发的并能看得上我的请联系我哈

vx:wu1020yt

我用它制定了一个“搞钱计划”。

比如我今年想多存五万块，

它能帮我倒推出每个月需要增加多少收入或者减少多少开支，目标特别清晰。

https://iris.findtruman.io/web/fire_calculator?share=L

APP扫码识别区是正方形怎么修改成长方形，微信小程序是长方形的，扫码识别区太小了，很不方便

就当纪念一下抠了好几天的头。虽然实现了，也花了很多时间，但是没有什么成功了的实感，有种莫名其妙的感觉。
不论咋样，还是记录一下吧，百度之后竟然完全没有人用这个方式 在ios上登录，而ds和cursor一众ai费拉不堪，ds胡说八道的程度越来越严重了

oauth2的登录描述比较粗糙。

有一个最想知道的问题，想知道 ios中app和 webview 的 cookie传递。

过程：
1.根据文档设置 ios的schemes。注：urltypes 只能用string格式，不可用数组，否则打包 的link.info 中 没有 CFBundleURLTypes 的标签。
2.login接口后，后端会产生一个短暂的cookie会话，根据该会话证明过程中登录情况。若无法验证到该cookie会话，将直接跳回登录界面。
3.使用webview 打开 authorize 页面，如果验证成功，会通过schemes唤醒 app,接着验证获取token并跳转主页面。

其中遇到3个阻碍。

1. 在login接口后的 cookie会话，没有 设置 domain 时，webview 打开 authorize页面，一直都是cookie验证会话失败，直接跳转回登录界面。在设置 domain后，第一次 登录 cookie会话验证失败，而第二次继续登录的验证都通过了。
   询问了ds等ai，给出的解释是 在ios时，网络请求和Cookie存储与App本身不在同一进程，默认不共享NSHTTPCookieStorage。所以通过webview 后端会拿不到cookie从而导致失败。而安卓的cookie在uni-app底层已经同步过，所以不存在该问题。但问题是为什么设置了domain后，除了第一次失败，后续的登录都成功了？是不是底层也对ios同步过？但为什么第一次不成功？强制手动给webview注入cookie，没有一个方式成功。设置延时任务也没有用，设置多长也没有用，第一次就是不能通过。
   后续与后端沟通，通过 生成token附带在 authorize的path后，后端使用token来验证会话解决该问题。

2.page.json中 设置过 // "condition": {
// //模式配置，仅开发期间生效
// "current": 0, //当前激活的模式(list 的索引项)
// "list": [{
// "name": "", //模式名称
// "path": "", //启动页面，必选
// "query": "" //启动参数，在页面的onLoad函数里面得到
// }]
// }。

从而导致 schemes唤醒后，无法获取schemes携带的数据。安卓无此问题。

3.后端schemes因为ios的安全机制是无法自动唤醒app，除非用户手动点。Universal Links 也没办法在同域名下进行唤醒。但是，实际上 传递数据已经触发，在plus.runtiem.arguments中是有数据的。所以直接搞了一个 定时任务监听这个数据，一旦有数据就可以直接后续的步骤，不需要用户手动点击。安卓可以直接通过schemes唤醒app并直接拿到数据，所以也不需要这个定时任务

一款无广告重拾儿时趣味的古诗 App 的开发过程记录

一、🌈缘起：让古诗 “活” 起来，而非躺在角落🌈

做这款 App 的初衷，藏在三个真实需求里：
一次偶然的寻找碰上鸿蒙的星光闪烁：翻找学生时代的语文诗词，想重拾那份诗词氛围时，书本早已不见踪影，此时便想在手机上寻找这类APP，市面古诗 App 要么广告扎堆，要么功能枯燥，实在感受不到当年的那种氛围；
身边朋友想重拾古诗，却缺合适的背诵工具，也没有专属交流渠道（总不能天天在朋友圈发古诗）；
古诗的意境与字词之美，不该只靠 “死记硬背”—— 结合互动、朗读、释义，让大家 “懂了再背”，才是真正的文化传承。
所以核心需求很明确：做一款 “不枯燥、能互动、够纯粹” 的古诗工具。既要满足学习需求，又要兼顾趣味性，还得适配鸿蒙系统（毕竟鸿蒙用户越来越多，生态也日趋完善）。

二、💡技术选型：为啥 “锁死” UniAPP？💡

选技术栈时纠结了 3 天，最终敲定 UniAPP，全靠 “实用主义”：
排除鸿蒙原生开发：适配鸿蒙虽丝滑，但单人开发要重新学原生语法，还无法兼顾其他平台，效率太低；
排除其他跨平台框架：要么对鸿蒙适配不完善，要么插件生态薄弱，像诗词朗读、音频上传等功能得手动造轮子；

选择 UniAPP 的核心原因：
跨平台省心：一套代码可打包鸿蒙 App，后续扩展安卓、iOS 版本无需重构，对个人开发者极度友好；

• 鸿蒙适配 “自带 buff”：HBuilderX 提供现成打包模板和专属适配插件，不用手动修改大量配置；
• 生态够全：uniCloud 云开发、音频组件、数据库插件，刚好满足古诗存储、朗读上传、接龙匹配等核心需求；
• 学习成本低：有微信小程序开发基础，UniAPP 的 Vue 语法无缝衔接，1 周就能上手。
  简单说：用 UniAPP 开发鸿蒙，就像 “站在巨人肩膀上”—— 不用从零学鸿蒙原生，又能享受鸿蒙系统特性，对非专业开发者太友好了！

三、⚠️踩坑实录：鸿蒙适配那些 “磨人的小妖精”⚠️

开发前以为 “跨平台 = 一路顺畅”，结果真正适配鸿蒙时，还是踩了不少坑，分享 3 个最印象深刻的：

权限申请：鸿蒙的 “规矩” 和其他平台不一样
做朗读广场时，需要调用手机麦克风录音、存储音频文件。一开始直接复用了其他平台的权限代码，结果在鸿蒙上直接报错 —— 录音功能打不开！

• 坑点：鸿蒙的 “媒体权限” 需要单独申请，而且必须配置ohos.permission.READ_MEDIA和ohos.permission.WRITE_MEDIA，还得在代码里动态弹窗说明 “为啥要要权限”（比如 “需要录音才能上传你的朗读作品”），光说 “需要权限” 会被系统拒绝；而且必须在鸿蒙的AGC后台进行同步申请该权限，因为该权限属于受限权限；而且！！！如果是使用的鸿蒙自家的隐私托管服务，必须要在隐私托管服务中同步该权限的声明
• 解决：使用uts插件配置权限；然后在AGC后台同步申请该受限权限通过率直接 100%。

  // #ifdef APP-HARMONY  
  import "@/uni_modules/harmony-permissions"  
  // #endif 

 {  
  "module": {  
    "name": "uni_modules__harmony_permissions",  
    "type": "har",  
    "deviceTypes": [  
      "default",  
      "tablet",  
      "2in1"  
    ],  
    "requestPermissions": [  
      {  
        "name": "ohos.permission.INTERNET"  
      },{  
        "name": "ohos.permission.WRITE_MEDIA",  
        "reason": "$string:media_desc",  
        "usedScene": {"when": "inuse"}  
      },{  
        "name": "ohos.permission.READ_MEDIA",  
        "reason": "$string:media_desc",  
        "usedScene": {"when": "inuse"}  
      }  
    ]  
  }  
}

服务卡片适配：桌面卡片让古诗 “触手可及”
鸿蒙的桌面卡片是个大亮点，我想做个 “每日一句” 卡片，用户不用打开 App，桌面就能看到古诗。

• 坑点：UniAPP 打包鸿蒙应用时，卡片的尺寸适配很麻烦，比如 3x2、2x2 的卡片布局会错乱，而且卡片数据刷新需要和主 App 同步；
• 解决：用 UniAPP 提供的uni-app x编译模式（专门优化鸿蒙适配），卡片布局用flex弹性盒，固定宽高比；数据同步用uniCloud实时数据库，主 App 更新 “每日一句” 后，卡片自动刷新，不用用户手动操作 —— 现在不少用户说 “每天解锁手机先看一眼古诗，感觉很治愈”。

音频播放：后台播放老是 “断档”
朗读广场的核心是 “听别人读古诗”，但一开始用户反馈 “退到后台就停了”，体验很差。

• 坑点：鸿蒙对后台音频播放有严格限制，普通的audio组件在后台会被系统暂停；
• 解决：集成了鸿蒙的AVPlayer SDK（UniAPP 可以直接调用鸿蒙原生 SDK），在manifest.json里配置 “后台音频权限”，同时用 UniAPP 的onBackground生命周期监听，退后台时自动切换到鸿蒙原生播放器，现在后台播放能稳定运行，用户还能边听古诗边刷微信～

四、📦功能落地：每个模块都是 “心头好”📦

结合古诗的核心需求，几个功能模块都是 “边踩坑边优化” 出来的，挑 3 个重点说：

1. 背一背：用 “艾宾浩斯曲线” 让背诵不费脑
   一开始只是简单做了 “列表 + 背诵打卡”，但用户反馈 “背了就忘”。后来用 UniAPP 的storage存储用户背诵记录，结合艾宾浩斯遗忘曲线，在对应时间点推送提醒（比如第 1 天、第 3 天、第 7 天），还加了 “遮字默写” 功能 —— 点击诗句能隐藏关键字，像考试一样检验效果。

   • 小技巧：用 UniAPP 的uni.createPushMessage调用鸿蒙的通知权限，提醒文案特意用古诗意境，比如 “床前明月光，今天该复习啦～”，比干巴巴的 “请背诵” 更讨喜。

     <view class="poem-content">  
     <block v-if="poemStore.showFullContent">  
       <text v-for="(line, idx) in poemStore.currentPoem.content" :key="idx" class="full-line">{{ line }}</text>  
     </block>  
     <block v-else>  
       <text v-for="(line, idx) in poemStore.currentPoem.content" :key="idx" class="hide-line">□□□□□□□</text>  
     </block>  
     </view>  
     <button class="toggle-btn" @click="poemStore.toggleFullContent">  
     {{ poemStore.showFullContent ? '切换到背诵模式' : '查看完整诗句' }}  
     </button>

     <script setup lang="ts">  
     import { usePoemStore } from '@/stores/poemStore';  
     import { useRouter } from 'vue-router';  
     const poemStore = usePoemStore();  
     const router = useRouter();  
     const goBack = () => {  
     router.back();  
     };  
     const handleCollect = () => {  
     if (poemStore.currentPoem) {  
     poemStore.toggleCollect(poemStore.currentPoem.id);  
     }  
     };  
     </script>

2. 诗词 / 成语接龙：云开发让匹配更流畅
   接龙功能需要实时匹配用户输入的诗句 / 成语，还要校验是否正确、有没有重复。一开始用本地数据库，结果数据量太大（收录了 2 万 + 古诗、1 万 + 成语），App 启动变慢。

   export interface Poem {  
   id: number;  
   title: string; // 诗名  
   author: string; // 作者（含朝代）  
   content: string[]; // 诗句数组  
   category: string; // 分类（如山水、边塞）  
   isCollected: boolean; // 是否收藏  
   }

   • 优化：改用uniCloud云开发，把诗词库、成语库存到云端，用云函数做匹配校验（比如输入 “举头望明月”，云函数自动查询以 “月” 开头的诗句），App 端只负责展示和输入，启动速度从 3 秒降到 1 秒，接龙延迟也几乎感知不到。

3. 主题颜色：贴合古风的 “颜值小心思”
   考虑到用户可能在不同场景使用（比如晚上背古诗要护眼），做了 3 种古风主题：黛青（默认）、朱砂（暖调）、月白（护眼）。

   • 实现：用 UniAPP 的vuex管理主题状态，结合鸿蒙的 “系统深色模式”，用户切换系统主题时，App 自动适配对应的古风配色 —— 比如系统开深色模式，App 自动切月白主题，字体加粗，保护视力。

     import { defineStore } from 'pinia';  
     import { Poem } from '@/types/poem';  
     const mockPoems: Poem[] = [  
     {  
     id: 1,  
     title: '望庐山瀑布',  
     author: '唐·李白',  
     content: ['日照香炉生紫烟', '遥看瀑布挂前川', '飞流直下三千尺', '疑是银河落九天'],  
     category: '山水',  
     isCollected: false  
     },  
     {  
     id: 2,  
     title: '静夜思',  
     author: '唐·李白',  
     content: ['床前明月光', '疑是地上霜', '举头望明月', '低头思故乡'],  
     category: '思乡',  
     isCollected: false  
     },  
     {  
     id: 3,  
     title: '春晓',  
     author: '唐·孟浩然',  
     content: ['春眠不觉晓', '处处闻啼鸟', '夜来风雨声', '花落知多少'],  
     category: '春景',  
     isCollected: false  
     }  
     ];  
     export const usePoemStore = defineStore('poem', {  
     state: () => ({  
     poems: mockPoems as Poem[], // 古诗列表  
     currentPoem: null as Poem | null, // 当前选中古诗  
     showFullContent: false // 详情页是否显示完整诗句（背诵模式控制）  
     }),  
     actions: {  
     // 选中古诗  
     selectPoem(poemId: number) {  
     this.currentPoem = this.poems.find(poem => poem.id === poemId) || null;  
     this.showFullContent = false; // 进入背诵模式，默认隐藏完整诗句  
     },  
     // 切换收藏状态  
     toggleCollect(poemId: number) {  
     const poem = this.poems.find(poem => poem.id === poemId);  
     if (poem) poem.isCollected = !poem.isCollected;  
     },  
     // 切换完整诗句显示（背诵/查看模式）  
     toggleFullContent() {  
     this.showFullContent = !this.showFullContent;  
     }  
     }  
     });

五、✅ 后续功能想法 ✅

• “想要更多主题颜色”→ 新增 “竹绿”“藤黄” 2 种配色；
• “朗读广场想给作品点赞”→ 加了点赞功能，用uniCloud存储互动数据；
• “背古诗想有奖励”→ 做了 “背诵勋章”，集齐 5 个勋章能解锁古诗插画壁纸。

虽然还未成功上架市场，但在开发中寻找用户体验过程中，最让我感动的是一条评论：“我家娃以前不爱背古诗，现在每天打卡接龙，还会给同学分享自己的朗读作品，谢谢开发者让传统文化变有趣～” 这种时候，觉得熬夜改 bug、反复适配都值了！

六、🌟星光不负：技术与文化的双向奔赴🌟

从一开始的 “想做个古诗工具”，到现在的 “让自己更了解古诗并爱上它”，用 UniAPP 开发鸿蒙 App 的这 3 个月，不仅让我摸清了跨平台开发的套路，更懂了 “技术是为需求服务”—— 不是堆功能，而是让应用真正有用起来、用得爽。
回头看，选择 UniAPP 是最正确的决定：它让我不用纠结原生语法，能把更多精力放在 “怎么让古诗更有趣” 上；而鸿蒙的开放能力（云开发、云调试、HarmonyOS SDK、云测试）等，又让 App 的体验更上一层楼。就像古诗里说的 “行则将至”，技术之路没有捷径，但只要朝着目标一步步走，星光总会照亮前路。
接下来，我还想加 AR 功能（用鸿蒙的 AR SDK，扫描实景生成古诗意境）、古诗合唱（朗读广场支持多人合拍），让传统文化通过技术 “活” 起来、“火” 起来。如果你也在做 UniAPP + 鸿蒙开发，或者对古诗 App 有更多想法，欢迎一起交流～ 毕竟，码向未来的路上，有人同行更精彩！

vue3-tauri2.9-os：最新原创研发vite7.2+tauri2.9+vue3 setup+pinia3+arcoDesign+echarts高颜值轻量级仿macOS/windows风格桌面os模式管理后台系统模板。支持可拖拽栅格布局桌面、JSON格式配置桌面菜单/Dock菜单。

项目技术知识

• 跨平台框架：tauri^2.9
• 前端技术框架：vite^7.2.2+vue^3.5.24+vue-router^4.6.3
• UI组件库：@arco-design/web-vue^2.57.0
• 状态管理：pinia^3.0.4
• 拖拽插件：sortablejs^1.15.6
• 滑屏插件：swiper^12.0.3
• 图表组件：echarts^6.0.0
• markdown编辑器：md-editor-v3^6.1.1
• 模拟数据：mockjs^1.1.0

项目框架结构

使用最新版跨平台框架tauri2.9+vite7搭建项目模板，vue3 setup语法编码开发页面。

vue3-tauri2-os桌面版os系统已经更新到我的原创作品小铺。
tauri2.9+vite7+arco-design桌面端OS管理系统

热文推荐

Tauri2.8+Vue3聊天系统|vite7+tauri2+element-plus客户端仿微信聊天程序
Tauri2-Vite7Admin客户端管理后台|tauri2.9+vue3+element-plus后台系统
Electron38-Vue3OS客户端OS系统|vite7+electron38+arco桌面os后台管理
electron38-admin桌面端后台|Electron38+Vue3+ElementPlus管理系统
Electron38-Wechat电脑端聊天|vite7+electron38仿微信桌面端聊天系统
最新版uniapp+vue3+uv-ui跨三端短视频+直播+聊天【H5+小程序+App端】
最新版uni-app+vue3+uv-ui跨三端仿微信app聊天应用【h5+小程序+app端】
原创uniapp+vue3+deepseek+uv-ui跨端实战仿deepseek/豆包流式ai聊天对话助手。
vue3-webseek网页版AI问答|Vite6+DeepSeek+Arco流式ai聊天打字效果
uniapp-vue3-os手机oa系统|uni-app+vue3跨三端os后台管理模板
Flutter3-MacOS桌面OS系统|flutter3.32+window_manager客户端OS模板
最新研发flutter3.27+bitsdojo_window+getx客户端仿微信聊天Exe应用
最新版Flutter3.32+Dart3.8跨平台仿微信app聊天界面|朋友圈
Electron35-DeepSeek桌面端AI系统|vue3.5+electron+arco客户端ai模板

日记一：环境搭建——“Hello, World!” 前的下马威

坑点： 模拟器启动失败，报错 HAXM is not installed或 VT-x is not available。

踩坑过程：

信心满满地安装完 DevEco Studio，创建第一个 Hello World 项目，点击运行模拟器。结果，控制台报出一串红色错误，模拟器屏幕一片漆黑。心里“咯噔”一下，难道第一步就卡住了？

排查与解决：

1. 检查BIOS： 重启电脑，狂按 F2/Del 键进入 BIOS 设置。找到 Intel Virtualization Technology（或 AMD 的 SVM Mode）选项，确保其状态为 Enabled。这是最根本的原因。
2. 开启Windows功能： 在 Windows 搜索栏输入“启用或关闭 Windows 功能”，确保 Hyper-V 和 Windows 虚拟机监控平台 已被勾选。完成后需要重启电脑。
3. 选择正确的模拟器： 在 DevEco Studio 的设备管理器中，确保下载的是 API 9或更高版本的模拟器。低版本 API 的模拟器可能存在兼容性问题。

心得： 鸿蒙开发环境的搭建，第一步就是和硬件虚拟化打交道。这提醒我，移动开发生态已与 Web 开发那种“开箱即用”的体验截然不同。

日记二：UTS 类型系统 —— “像”TypeScript，但不是 TypeScript

坑点一：Map.forEach的消失

代码：

let myMap = new Map<string, number>();  
myMap.set('apple', 5);  
// 在 iOS 上运行良好，在鸿蒙上报错！  
myMap.forEach((value, key) => {  
  console.log(key, value);  
});

错误： TypeError: undefined is not callable

解决方案：

// 方案1：使用 for...of 循环  
for (let [key, value] of myMap.entries()) {  
  console.log(key, value);  
}  

// 方案2：更保险的做法，先判断平台或方法是否存在  
if (myMap.forEach) {  
  myMap.forEach((value, key) => { /* ... */ });  
} else {  
  for (let [key, value] of myMap.entries()) { /* ... */ }  
}

坑点二：隐式类型转换的终结

代码：

let data: string | null = getDataFromAPI();  
// Web 中常见的真值判断，在 UTS 中报错！  
if (data) {   
  processData(data);  
}

错误： The condition expression must be of boolean type.

解决方案：

// 必须进行显式的布尔判断  
if (data != null) {  
  processData(data);  
}  

// 或者判断字符串长度  
if (data?.length > 0) {  
  processData(data;  
}

心得： UTS 的强类型特性像一位严格的老师，逼着我写出更严谨、更少歧义的代码。虽然初期不适应，但从代码质量角度看，是件好事。

日记三：页面布局与样式 —— CSS 的“阉割版”体验

坑点一：100vh的陷阱与滚动失效

代码：

<template>  
  <view class="container">  
    <scroll-view scroll-y class="scroll-area">  
      <!-- 长内容 -->  
    </scroll-view>  
    <view class="fixed-bottom">我是一个底部固定栏</view>  
  </view>  
</template>  

<style>  
.container {  
  height: 100vh; /* 鸿蒙不支持 vh！ */  
}  
.scroll-area {  
  height: 100%; /* 继承自一个高度无效的容器，滚动失效 */  
}  
</style>

现象： 页面无法滚动，scroll-view区域高度为 0。

解决方案：

<template>  
  <!-- 关键：让 scroll-view 作为根节点或充满整个页面 -->  
  <scroll-view scroll-y class="page-root">  
    <!-- 所有内容，包括原本想固定的元素，都放在里面 -->  
    <view class="content">可滚动内容</view>  
    <view class="bottom-placeholder"></view>  
    <view class="fixed-bottom">利用 absolute 或 fixed 定位模拟固定</view>  
  </scroll-view>  
</template>  

<style>  
.page-root {  
  width: 100%;  
  height: 100%; /* 使用 100% 而不是 100vh */  
  position: relative; /* 为固定定位元素提供参考 */  
}  
.fixed-bottom {  
  position: absolute;  
  bottom: 0;  
  width: 100%;  
}  
.bottom-placeholder {  
  height: 100rpx; /* 为固定底部留出占位空间，避免内容被遮挡 */  
}

坑点二：Flex 布局的微妙差异

在 Web 中，display: flex的容器默认是 flex-direction: row。在鸿蒙的 text组件嵌套 span时，我发现 Flex 布局的表现有时与 Web 有细微差别，导致文字排版错乱。

解决方案： 尽量显式地写明 flex-direction，避免依赖默认值。对于复杂布局，多使用 align-items和 justify-content进行微调。

心得： 必须彻底抛弃 Web 的“文档流”思维，拥抱原生应用的“盒子模型”和明确的滚动容器概念。布局要更“笨拙”但更精确。

日记四：数据库操作 —— 最诡异的“数据隐身术”

坑点：查询结果对象“看起来有数据，却取不出来”

代码：

// 执行查询  
const result = db.query(‘SELECT name, count FROM ingredients’);  
const rows = result.maps;  
console.log(‘结果行数:’, rows.length); // 输出： 结果行数: 5  
console.log(‘第一行:’, JSON.stringify(rows[0])); // 输出： 第一行: {}  

// 以下代码在 iOS 上正常，在鸿蒙上为 undefined  
const name = rows[0][‘name’];

现象： 数据“幽灵”，日志显示有数据，但代码无法访问。

根源： 鸿蒙平台返回的 rows不是普通对象数组，而是 Map<string, any>[]！ JSON.stringify对 Map 序列化会得到空对象 {}。

解决方案：

// 封装一个强大的兼容性取值函数  
function getRowValue(row: any, key: string, defaultValue: any = null): any {  
  if (row == null) return defaultValue;  

  // 方法1：判断是否是 Map  
  if (row instanceof Map) {  
    return row.get(key) ?? defaultValue;  
  }  
  // 方法2：判断是否拥有 get 方法 (更通用)  
  else if (typeof row.get === ‘function’) {  
    return row.get(key) ?? defaultValue;  
  }  
  // 方法3：默认为普通对象  
  else {  
    return row[key] ?? defaultValue;  
  }  
}  

// 使用  
const name = getRowValue(rows[0], ‘name’);  
const count = getRowValue(rows[0], ‘count’, 0);

心得： 跨平台开发中，“数据序列化/反序列化”是头号隐形杀手。不能相信表面现象，必须对关键数据的实际类型进行运行时判断。

日记五：网络请求与生命周期 —— 异步世界的时序陷阱

坑点：onLoad中发起请求，在 onReady中访问数据却为 null

代码：

export default {  
  data() {  
    return {  
      recipeData: null  
    }  
  },  
  onLoad() {  
    uni.request({  
      url: ‘/api/recipe’,  
      success: (res) => {  
        this.recipeData = res.data; // 异步赋值  
      }  
    });  
  },  
  onReady() {  
    // 企图使用数据渲染视图，但 recipeData 很可能还是 null！  
    this.renderChart(this.recipeData); // 报错！  
  }  
}

解决方案：

1. 使用状态管理： 引入 Pinia，在请求成功的回调中提交 mutation 改变状态，组件通过 computed 属性响应式地获取数据。

2. 条件渲染： 在模板中根据数据是否存在进行判断。

   <template>  
    <view>  
      <chart v-if=“recipeData” :data=“recipeData”></chart>  
      <loading v-else>加载中…</loading>  
    </view>  
   </template>  

3. 使用 Promise/async-await： 确保在数据准备好后再执行后续操作。

   async onLoad() {  
    try {  
      this.recipeData = await this.fetchRecipeData();  
      // 数据获取成功后，再执行需要数据的操作  
      this.$nextTick(() => {  
        this.renderChart(this.recipeData);  
      });  
    } catch (error) {  
      console.error(‘数据加载失败:’, error);  
    }  
   }  

心得： 生命周期钩子和异步操作的配合，是前端开发永恒的课题。在鸿蒙这种更接近原生的环境中，对时序的控制要求更为严格。

总结：我的踩坑生存法则

1. 假设一切都有平台差异： 对任何 API、组件、样式属性，都抱有一丝怀疑，优先查阅鸿蒙专属文档。
2. 日志是最好（有时是唯一）的调试工具： 不仅要打印值，还要打印类型（typeof, instanceof）。
3. 封装兼容层： 将平台差异（如数据库取值、网络库）封装成统一的工具函数，是长期项目的必备架构。
4. 小步快跑，频繁测试： 每实现一个小功能，就在鸿蒙模拟器或真机上跑一遍，避免错误累积。
5. 拥抱社区： uni-app 的官方论坛、钉钉群和 GitHub issues 是解决问题的宝库，你踩的坑，大概率已经有人踩过并分享了解决方案。

踩坑虽苦，但每解决一个坑，对鸿蒙平台和跨平台开发的理解就加深一层。现在回头看，这些坑都成了我宝贵的经验财富。希望这份日记，能为你照亮前行的路，助你少走弯路！