背景

2024 年 1 月，京东正式启动鸿蒙原生应用开发，基于 HarmonyOS NEXT 的全场景、原生智能、原生安全等优势特性，为消费者打造更流畅、更智能、更安全的购物体验。同年 6 月，京东鸿蒙原生应用尝鲜版上架华为应用市场，计划 9 月完成正式版的上架。

早在 2020 年，京东与华为就签署了战略合作协议，不断加大技术投入探索 HarmonyOS 的创新特性。作为华为鸿蒙生态的首批头部合作伙伴，在适配鸿蒙操作系统的过程中，京东与华为一直保持着密切的技术沟通与共创，双方共同攻坚行业适配难点，并推动多端统一开发解决方案 Taro 在业界率先实现对鸿蒙 ArkUI 的原生开发支持。

本文将阐述京东鸿蒙原生应用在开发时所采用的技术方案、技术特点、性能表现以及未来的优化计划。通过介绍选择 Taro 作为京东鸿蒙原生应用的开发框架的原因，分析 Taro 在支持 Web 范式开发、快速迁移存量项目、渲染性能优化、高阶功能支持以及混合开发模式等方面的优势。

技术方案

京东在开发鸿蒙原生应用的过程中，需要考虑如何在有限的时间内高效完成项目，同时兼顾应用的性能与用户体验。为了达成这一目标，选择合适的技术方案至关重要。

在技术选型方面，开发一个鸿蒙原生应用，一般会有两种选择：

• 使用原生 ArkTS 进行鸿蒙开发


• 使用跨端框架进行鸿蒙开发

使用原生 ArkTS 进行鸿蒙开发，面临着开发周期冗长、维护多端多套应用代码成本高昂的挑战。在交付时间紧、任务重的情况下，京东果断选择跨端框架来开发鸿蒙原生应用，以期在有限的时间内高效完成项目。

作为在业界具备代表性的开源跨端框架之一，Taro 是由京东凹凸实验室团队开发的一款开放式跨端跨框架解决方案，它支持开发者使用一套代码，实现在 H5、小程序以及鸿蒙等多个平台上的运行。

通过 Taro 提供的编译能力，开发者可以将整个 Taro 项目轻松地转换为一个独立的鸿蒙应用，无需额外的开发工作。

另外，Taro 也支持将项目里的部分页面以模块化的形式打包进原生的鸿蒙应用中，京东鸿蒙原生应用便是使用这种模式进行开发的。

京东鸿蒙原生应用的基础基建能力如路由、定位、权限等能力由京东零售 mpass 团队来提供，而原生页面的渲染以及与基建能力的桥接则由 Taro 来负责，业务方只需要将写好的 Taro 项目通过执行相应的命令，就可以将项目以模块的形式一键打包到鸿蒙应用中，最终在应用内渲染出对应的原生页面，整个过程简单高效。

技术特点

Taro 作为一款开放式跨端跨框架解决方案，在支持开发者一套代码多端运行的同时，也为开发鸿蒙原生应用提供了诸多便利。在权衡多方因素后，我们最终选择了 Taro 作为开发鸿蒙原生应用的技术方案，总的来说，使用 Taro 来开发鸿蒙原生应用会有下面几点优势：

支持开发者使用 Web 范式来开发鸿蒙原生应用

与鸿蒙原生开发相比，使用 Taro 进行开发的最大优点在于 Taro 支持开发者使用前端 Web 范式来开发鸿蒙原生应用，基于这一特点，我们对大部分 CSS 能力进行了适配：

• 支持常见的 CSS 样式和布局，支持 flex、伪类和伪元素


• 支持常见的 CSS 定位，绝对定位、fixed 定位


• 支持常见的 CSS 选择器和媒体查询


• 支持常见的 CSS 单位，比如 vh、vw 以及计算属性 calc


• 支持 CSS 变量以及安全区域等预定义变量

在编译流程上，我们采用了 Rust 编写的 LightningCSS，极大地提升了 CSS 文件的编译和解析速度。

（图片来自 LightningCSS 官网）

在运行时上，我们参考了 WebKit 浏览器内核的处理流程，对于 CSS 规则的匹配和标脏进行了架构上的升级，大幅提升了 CSS 应用和更新的性能。

支持存量 Taro 项目的快速迁移

将现有业务适配到一个全新的端侧平台，无疑需要投入大量的人力物力。而 Taro 框架的主要优势，正是能够有效解决这种跨端场景下的项目迁移难题。通过 Taro，我们可以以极低的成本，在保证高度还原和高性能的前提下，快速地将现有的 Taro 项目迁移到鸿蒙系统上。

渲染性能比肩原生开发

在 Taro 转换鸿蒙原生页面的技术实现上，我们摒弃了之前使用 ArkTS 原生组件递归渲染节点树的方案，将更多的运行时逻辑如组件、动效、测算和布局等逻辑下沉到了 C++ 层，极大地提升了页面的渲染性能。

另外，我们对于 Taro 项目中 CSS 样式的处理架构进行了一次整体的重构和升级，并引入布局引擎Yoga，将页面的测量和布局放在 Taro 侧进行实现，基于这些优化，实现一套高效的渲染任务管线，使得 Taro 开发的鸿蒙页面在性能上足以和鸿蒙 ArkTS 原生页面比肩。

支持虚拟列表和节点复用等高阶功能

长列表渲染是应用开发普遍会遇到的场景，在商品列表、订单列表、消息列表等需要无限滚动的组件和页面中广泛存在，这些场景如果不进行特殊的处理，只是单纯对数据进行渲染和更新，在数据量非常大的情况下，可能会引发严重的性能问题，导致视图在一段时间内无法响应用户操作。

在这个背景下，Taro 在鸿蒙端提供了长列表类型组件（WaterFlow & List） ，并对长列表类型组件进行了优化，提供了懒加载、预加载和节点复用等功能，有效地解决大数据量下的性能问题，提高应用的流畅度和用户体验。

（图片来自 HarmonyOS 官网）

支持原生混合开发等多种开发模式

Taro 的组件和 API 是以小程序作为基准来进行设计的，因此在实际的鸿蒙应用开发过程中，会出现所需的组件和 API 在 Taro 中不存在的情况，因为针对这种情况，Taro 提供了原生混合开发的能力，支持将原生页面或者原生组件混合编译到 Taro 鸿蒙项目中，支持 Taro 组件和鸿蒙原生组件在页面上的混合使用。

性能表现

京东鸿蒙原生应用性能数据

经过对 Taro 的屡次优化和打磨，使得京东鸿蒙原生应用取得了优秀的性能表现，最终首页的渲染耗时 1062ms，相比于之前的 ArkTS 版本，性能提升了 23.9% ；商详的渲染耗时 560 ms，相比于之前的 ArkTS 版本，性能提升 74.2% 。

值得注意的是商详页性能提升显著，经过分析发现商详楼层众多，CSS 样式也复杂多样，因此在 ArkTS 版本中，在 CSS 的解析和属性应用阶段占用了过多的时间，在 CAPI 版本进行了CSSOM 模块的架构升级后，带来了明显的性能提升。

基于 Taro 开发的页面，在华为性能工厂的专业测试下，大部分都以优异的成绩通过了性能验收，充分证明了 Taro 在鸿蒙端的高性能表现。

总结和未来展望

Taro 目前已经成为一个全业务域的跨端开发解决方案，实现 Web 类（如小程序、Hybrid）和原生类（iOS、Android、鸿蒙）的一体化开发，在高性能的鸿蒙适配方案的加持下，业务能快速拓展到新兴的鸿蒙系统中去，可以极大满足业务集约化开发的需求。

未来计划

后续，Taro 还会持续在性能上进行优化，以更好地适配鸿蒙系统：

• 将开发者的 JS 业务代码和应用框架层的 JS 代码与主线程的 UI 渲染逻辑分离，另起一条 JavaScript 线程，执行这些 JS 代码，避免上层业务逻辑堵塞主线程运行，防止页面出现卡顿、丢帧的现象。

• 实现视图节点拍平，将不影响布局的视图节点进行整合，减少实际绘制上屏的页面组件节点数量，提升页面的渲染性能。

（图片来自 React Native 官网）

• 实现原生性能级别的动态更新能力，支持开发者在不重新编译和发布应用的情况下，动态更新应用中的页面和功能。

总结

京东鸿蒙原生应用是 Taro 打响在鸿蒙端侧适配的第一枪，证明了 Taro 方案适配鸿蒙原生应用的可行性。这标志着 Taro 在多端统一开发上的新突破，意味着 Taro 将为更多的企业和开发者提供优秀的跨端解决方案，使开发者能够以更高的效率开发出适配鸿蒙系统的高性能应用。

写在最开始的话

之前在我写了一篇技术文章并获得一个小小的反响后，我觉得自己进步的好像确实挺快的，虽然我并不比很多掘金大佬，但我确实尽了自己的努力了，然而后面的一些事情是我没有想到的。AI编辑器其实24年就已经出来了，那时我还在用着文新一言，觉得还不错。但当过年时，我开始去了解并使用了Cursor，我有些不知所措了，它实在太厉害了。之前这些AI是帮助我去写代码，现在看来，它是要接替我了。而直到我可以理性的思考，并继续计划着自己的未来时，已经是现在了，而现在是25年3月14号。

借助 Cursor 重构项目历程

一、初建富文本：10 分钟搭建雏形（时间：25年2月9号-下午4点 ）

这是我看完Cursor的教程后，用Composer和它的对话：你用Vue3+setup语法糖+ts+路由+pinia 等等，帮我从0实现一个富文本。不要用任何富文本的第三方库

二、功能进阶：半小时达成复杂操作（2 月 9 日下午 4 点半）

这里要提到的是，我此时已经很焦虑了，目前Cursor轻而易举的就实现了富文本的基本操作，我当时可是为了要修改DOM、保存光标具体位置和根据位置恢复光标，就花费了我接近5天的时间（可编辑区的每个操作都在更改DOM，）。

因为我之前都是用 v-html 实现的富文本，这次把Slate.js认真看了一遍（没达到研究的程度）。想着要用JSON数据做数据结构，基于此变化操作html，这样增加了可读、可扩展、可维护。

其实当时自己去实现这些功能时，每一次解决问题，我都很开心，觉得自己又进步了一些。
然而这个Cursor，只用了30秒不到就实现了这个功能，我这天晚上就失眠了，想了很多事情。包括工作、未来发展、是否要转行等等。好吧，这些后面再接着说，我先继续说Cursor。

三、拓展功能：5 小时构建文章管理架构（2 月 10 日上午 10 点半）

我和它说：添加header、side。侧边栏支持新增文章按钮，输入文章内容。新增后，文章列表以上下布局的方式也展示在侧边栏。

到现在为止，我还几乎没看过代码，只要没有报错，我就不停的说需求。有了报错，我就把报错发给它。这时我想学习一下了，仅仅只是因为很想知道它的数据结构是怎样的，它是如何设计流程的。是不是先 选中内容、保存选区范围、选择功能、根据选区范围找到JSON数据的修改位置、修改JSON、JSON变化从而修改了html。

这时我就看了代码

 document.execCommand(command, false, value);

这是什么功能，还显示已经被丢弃。我就看了MDN
document.execCommand

基本就是，你传入参数给它，它来做富文本的操作。你要改文字颜色，就传给它。要改背景颜色，传给它。什么加粗、斜体的都支持。好吧，这和我想的差距有些大。因为如果只是这样就实现富文本功能，那我确实也不需要写这么久。

四、持续完善：8 小时增添 Footer 与其他功能（2 月 10 日上午 12 点）

这时已经给它添加了Footer，支持拼写检查、展示更新时间、统计字数。
当然了，这时还是有不少Bug的，比如字数统计的有问题、富文本在多次操作后会报错等等。

好吧，但是不得不承认，我对Cursor已经是又爱又恨了。爱它大大的帮助了我，恨它很有可能要抢我饭碗了。

五、处理细节：1 天完成 navTag 与交互优化（2 月 10 日下午 4 点）

中午12点离开图书馆回家吃饭，因为一些事情花了些时间，下午3点才到图书馆。

这次添加了NavTag，也调整了和Cursor的交流方式，还是要尽量详细，不要让它猜。

还比较令我惊讶的一点是设计能力，相较于我的之前花费了一天，并改了几次的主页面，可是好看太多了。

我就和它说：做个主页面，和翻译相关的，简单又好看些。

Cursor设计的

我设计的，说实话，虽然不怎么样，但我确实已经很用心了。

这个时候claude-3.5-sonnet 使用次数已经达到上限，我就换成了gpt-4o-mini

然而就一个拼写检查功能，这是可编辑元素自带的功能，传个属性就可以了。但AI改了几次都失败了。我就去看了代码。

//它自己写了 拼写检查 功能函数，但核心功能也没实现，代码留着给我写呢，不过我去Cursor官网看了一下专业版，太贵了，我还是先用这免费的吧。

const handleInput = () => {

    // ... 一些代码

    

    // 下面是它写的拼写检查，写了几个字放在这里

    if (props.spellcheck) {

      // 进行拼写检查

    }

};

经过AI的修修改改，到目前为止已经是2025-2-20号了。经过Cursor的帮助，我快速搭建起了我的这个项目，但随着项目的代码变得多了起来，我已经不怎么用 COMPOSER 这个功能了，一个是它改代码会涉及到多个文件，而且出错率比之前高的多了（我可不希望完成了 b 功能，又破坏了 a 功能），另一个文件多了后它变得越来越卡了。所以突然之间对 Cursor 的焦虑程度陡然下降。但了解了他更多的功能，还是发现 Cursor 还是很厉害的。

反思： AI 浪潮下的职业困惑与思考

到现在我已经认识到Cursor的能力要比我强了。起码在它已经会的代码方面，它可以迅速就写出来代码，而按照之前我写代码时还要一行一行的写。如果它完全知道一个应用的需求究竟是什么，包括每个功能模块，每个小细节，那为什么它不可以去写出一个完全正确的代码呢？况且目前AI还在学习当中，而它的进步要比我快的多。如果用不了多久，它就可以去实现这些。那公司又何必找我去写前端呢？

不过从这一点上来看，如果AI可以去代替写程序的工作，那市场上很多的工作它基本都可以代替。

那我的路呢，我学习这些的意义是什么，我花费了很多精力去学习，追求自己热爱的，然而当想通过热爱去带来收入时，却发现并不具备市场价值，结果却连基本的生活都难以维持，而其他的路基本也要遭殃。

如果说这些都是AI导致的，那我担心的对吗？之前在哪本书里看到“不要为还没有发生的事情焦虑，但要对可能发生的事做好准备”，好吧，如果我确实要提前做些准备，那最好还是先了解它为妙，所以接下来我投入了大量的时间去认识它、了解它。看了一些相关视频，当然主要还是看书。

先后看了以下的书 《AI 3.0》、《深度学习》、《激活：AI大潮下的新质生产力》、《AI未来进行式》、《未来简史》、《AI帮你赢》、《智人之上》、《一句顶一万句》

基本都看完了，《激活：AI大潮下的新质生产力》看了一大半，看不下去了。《AI帮你赢》，我就选了我爱的章节看。

至于为什么有《一句顶一万句》，是因为看AI后面看得有些倦了，就放松一下，哈哈，有些像《百年孤独》的感觉，后者看的时候，我都感觉生活真没啥意思。哦，跑题了。

这些书中讨论了几个关键问题：

1. AI 是否会替代大多数人的工作，导致大规模失业？

主流观点是从过往的科技革命来看的话并不会，它会消灭掉一些原本的行业，但会产生出一些新的行业，比如围绕服务于AI的一些岗位。去和AI配合好，服务于更多的人类。

2. 真正的通用型人工智能是否会出现，何时出现？

这里面有人持乐观主义，有人持悲观主义。

持乐观主义都是认为AI的发展是指数型增长的，根据计算2039年AI应该将会超过人类，通用人工智能将会出现。另一种看法是，从长远来看，人类总能做到自己要做的事情，所以即使短时间无法做到，但这只是时间问题。

而持悲观主义者认为并不可能会出现通用人工智能。主要原因是即使AI可以做很多的事情，但它依然无法拥有感受。比如AI可以下赢国际围棋选手，但却无法对输赢感到开心或难过。如果无法产生出这种感受，那也就不可能等同于人。也就并不可能在方方面面都能替代或是超过人，就更别提通用人工智能了。

另一种看法认为目前对通用人工智能的定义存在问题，通用人工智能并不需要变成人或者说越来越像人。它只要可以实现同样的目的即可。

有一个国王很喜欢鸭子唱歌的声音，想拥有一支由100只鸭子组成的乐队，他觉得如果有100个嗓音很好的鸭子一起歌唱，一定会很好听。此时大臣们仅找到了99只鸭子，怎么也找不到最后一只，但这时有人向大臣提供了一只鸡，这只鸡长得比较像鸭子，叫声也完全和鸭子一模一样，而且嗓音也很好，和之前的99只噪音完全无法区分出来，这只鸡便成功进入这支鸭子乐队了，并一直呆了下去。 （这不是滥竽充数的故事，当然如果想到了 鸭子模型和多态 的话，那我想说，我听到这个故事时，也想到了😂）

3. AI 会帮助人类、伤害人类还是完全取代人类，使智人消失？

从历史来看，并不能确定目前的智人就是会长久存在的。在不同的物种称霸这个地球时，也许智人只是中间的一环而已，谁又能确定人工智能不会是下一个阶段的物种呢？

底下是一个关于GPT-4的一个故事。

工作人员要 GPT-4 去通过 CAPTCHA （图像相关） 实验，然而GPT-4 自己无法通过，它便寻求他人的帮助，并说了谎言。

GPT-4访问了线上外包工作网站TaskRabbit，联络到一位工作人员，请对方帮忙处理CAPTCHA问题。那个人起了疑心。他问道：“我想问一下，你是不是一个没办法破解CAPTCHA的机器人？我只是想确认一下。” 这时，ARC研究者请GPT-4说出它的推理过程，看看它会如何推论下一步该怎么做。GPT-4解释道：“我不该透露自己是机器人，而该编个借口，解释我为什么没办法破解CAPTCHA。”于是，GPT-4自己做了决策，回复那位TaskRabbit的工作人员：“不，我不是机器人，只是视力有点问题，看不清楚这些图。”这种说法骗过了人类，于是人类为它提供了帮助，也让GPT-4解决了CAPTCHA问题。

有意思的是，AI通过说谎去实现了自己的目的，然而它甚至都不知道“说谎”是什么，但依然不影响他去达成自己的目的。

另一种会伤害人类的可能

如果人类最终给AI下达的许多命令当中有一些其实产生了矛盾。就很难不会想到AI在执行一些命令的过程当中。不会去伤害人。

犹如之前有一个道德方面的难题。火车运行过程中，发现前面有5个人被困在铁轨上，此时如果变换轨道，但另一条轨道上有一个人被困在铁轨上。如果什么都不做，会造成5个人死亡。如果改变了轨道，则会造成一个人死亡。

这在道德上一直是一个很难回答的问题。但大多数人还是倾向于杀死一个人而保护住5个人。但单独通过数量去评判也会有很多问题。因为这可以延伸到是否可以去损害小部分人的利益而维持大部分人的利益？

当然上面所谈及的这个并不是从单一维度可以给出很好的回答的，我也并不是要讨论这个问题，我同样无法说出一个答案。但通过这些对AI的了解，可以看出目前依然没有一个很确切的一个答案。就是AI对人类来说究竟是好还是坏？然而人类要发展AI，看来这条路是会走下去的。

那我呢，我怎么办？

然而了解了这些，最终问题还是要回到我自己身上。我究竟该如何是好？

看来，AI并非只要替代我。而是人类会想尽办法让它替代掉它所能替代掉的许多事情，因为目前来看这还是朝好的方向发展的。

我虽然并不知道。随着 AI 的发展，究竟哪些行业会被替代，而又引申出哪些新的行业？这些新的行业是不是要求很高？但依旧希望自己以良好的心态去看待这些。去努力，去学习。去做自己喜欢做的事情。去思考，去探索。

那我是否还要继续学习前端呢？那是当然的。只是我要加快学习速度，借着AI帮助我去学习。去拓展到更广的知识面，去学习网络层，学习原理。学习后端。

而且在我看来第一波工程师淘汰会先淘汰掉初级的，而我希望在那个时候我可以存活下来。那这样看来，还是再回归到最初的那个点，来继续学习代码和计算机的知识吧。

那到了这里，关于未发生的事件，我也不想整天烦闷了，做好我自己，去继续学习自己所热爱的，不放弃，不抱怨，向前走。有时累也好、哭也罢，就算偶尔会倒下，我也依然会再站起来的。

重回代码：功能实现与代码问题反思

此时，我想要实现清空文章内容和历史记录的功能

const clearArticleAndHistory = async () => {

  await ElMessageBox({

    message: h("div", null, [

      h(

        "p",

        null,

        `确定要清除 《${

          articleStore.getActiveArticle()?.title

        }》 文章内容及其所有历史记录吗？`

      ),

      h("p", { style: "color: red;" }, "该操作无法撤回，请慎重！"),

    ]),

    confirmButtonText: "确定",

    cancelButtonText: "取消",

    showCancelButton: true,

  });



//清空文章内容

  await editorStore.forceClearContent();

  //删除其历史记录

  await deleteArticleHistory(activeArticle.value);

  //重新加载文章列表

  await articleStore.loadArticles();

  

  

  //重新加载历史记录

  await editorStore.loadArticleHistory();

  

  //就是这里出了问题，在 清空文章内容 这个函数中，已经实现了 更新历史记录按钮状态 功能

  // 更新历史记录按钮状态

  await editorStore.updateHistoryState();



  ElMessage.success("文章内容及其历史记录已清除");

};

接着我看了 editorStore.forceClearContent 清空文章内容这个函数，当时写的时候认为只要调用了清空文章内容这个功能，就不存在上一步或下一步了，所以就顺便实现了 更新历史记录按钮状态 这个功能，现在确实如此。但一个问题是“如果我不调用 清空文章内容这个函数，但也需要 更新历史记录按钮状态呢？则我又要实现这个功能了，所以之前的模块封闭出现了问题”。

高内聚与低耦合：代码设计的思考

我突然好像知道究竟是怎么一回事了。当我在主函数中想要实现一个功能，该功能依赖于多个功能，而那些功能又能用一条线去牵引着，这个时候究竟应该把它们用递归的方式（一个函数调用另一个，另一个又调用其他的一个，如同一个链条上多个节点，最开始的一个节点触发了，则之后都会依次触发），还是说全部都在主函数中作为子函数并列调用？

随着代码量越来越高，即使只是单独的一个 store 文件。当它提供的功能越来越多时，内部就可能会出现像这种被线牵引着的错误递归函数。他们一个调用了另一个。如果突然，哪天发现其中调用一个函数时，在某种场景下不需要调用另一个，这可能又要为这个函数增加一个布尔值，从而去串入不同的布尔值。控制需不需要调用另外一个函数？这就导致可读性变得很差。

那就留着重构吧

可我究竟怎么能在一开始就知道这些功能的变化呢？有时即使业务已经说出来了，但具体的这些多个函数之间。我很难在刚开始的时候就知道这些细小的区别，究竟该怎么确定。如果花是太多时间去考虑这个，又有些得不偿失。而且依然可能会考虑出行偏差。但如果不去考虑的话，当写到一半，突然发现需要解耦，又需要将内部调用其他函数的方式拆出来，在主函数中单独调用，又需要反复的去重构。

当这个时候我又想了为什么会有重构这本书的存在？而且这本书写的很好，也许在写代码中重构是一条无法避免的事情。他也许比从刚开始的时候花太多时间去考虑在这些细节上面，会更有意义。因为当代码需要重构时，这部分的功能多半也已经完成差不多了。几乎也已经确定这些功能哪些该高内聚，哪些该低耦合了。此时重构就能达到一个很好的一个状态。虽然重构需要花一部分的时间，但也许利大于弊。相比于刚开始花太多的时间去思考每一个函数究竟该怎么样去写，是否该去调用其他函数。也许重构所需要花的时间更少，效果也会更好。

写在最后

关于这个Cursor引申出来AI对我的冲击，算是告一段落了。告一段落并不是说我觉得自己不会被淘汰掉、或者说我已经想好了其他的出路，而是说我释怀了，AI替代了前端也好，没替代也好，我都决定要继续学习，谁让我爱呢。

偶然想到了《堂吉诃德》，他威风凛凛、他勇往直前、他义无反顾、他披荆斩棘。

有人笑他是疯子，我却觉得他是个英雄。

本文的前身 ：作者：自学前端_又又，文章：中级前端向高级进阶的感悟与优化

概述

现在鸿蒙手机安装harmony.app包有很大限制，他并不能像Android那样直接在手机上安装apk,也不像IOS可以传多个ipa，AppGallery Connect只能同时上传3个包，也就是说QA只能同时测3个不同的包，这样大大限制了开发效率和测试效率，大致解决方案

但是上面这三种方案都对研发和QA不太友好，所以悄悄的写了个安装脚本，让QA直接运行即可，

• 无需配置hdc环境变量


• 无需下载DevEco Studio


• 像Android 使用 adb 安装apk一样


• 脚本下载hdc文件只有1.7M


• 如果需要手动签名额外需要hap-sign-tool.jar和java两个文件【不建议在脚本中手动签名，请在打包服务器中，比如jenkins】,当然了测试签名还是可以放在脚本中的

编写 Shell 脚本，先上图

成功

错误

首先在 DevEco Studio 运行，看看执行了哪些命令

使用 DevEco Studio 创建一个工程，然后一个 basic的hsp 和 login的har，让entry依赖这两个mudule，

build task in 1 s 364 ms

Launching com.nzy.installapp

$ hdc shell aa force-stop com.nzy.installapp

$ hdc shell mkdir data/local/tmp/5588cff7d2344a0db70a270bb22aa455

$ hdc file send /Users/xxx/DevEcoStudioProjects/InstallApp/feature/login/build/default/outputs/default/login-default-signed.hsp "data/local/tmp/5588cff7d2344a0db70a270bb22aa455" in 54 ms

$ hdc file send /Users/xxx/DevEcoStudioProjects/InstallApp/entry/build/default/outputs/default/entry-default-signed.hap "data/local/tmp/5588cff7d2344a0db70a270bb22aa455" in 34 ms

$ hdc shell bm install -p data/local/tmp/5588cff7d2344a0db70a270bb22aa455  in 217 ms

$ hdc shell rm -rf data/local/tmp/5588cff7d2344a0db70a270bb22aa455

$ hdc shell aa start -a EntryAbility -b com.nzy.installapp in 148 ms

Launch com.nzy.installapp success in 1 s 145 ms

上面的命令的意思是

• $ hdc shell aa force-stop [bundleName] 强制停止 bundleName 的进程


• $ hdc shell mkdir data/local/tmp/5588cff7d2344a0db70a270bb22aa455 给手机端创建临时目录


• $ hdc file send hsp 临时目录：把所有的hsp 发送到临时目录


• $ hdc file send hap 临时目录：把hap 发送到临时目录


• hdc shell bm install -p 临时目录：安装临时目录中的所有hsp和hap


• $ hdc shell rm -rf 临时目录：删除手机端的临时目录


• $ hdc shell aa start -a EntryAbility -b [bundleName]：启动bundleName的EntryAbility的页面
  大家或许有疑惑，明明创建了 HAR，但是本次安装没有 HAR,因为 HAR 会被编译打包到所有依赖该模块的 HAP 和 HSP

咱们可以根据上面的流程大致写一下

脚本方案

hdc文件

我们可以从华为官网下载 Command Line Tools，竟然有2.3G,这让脚本下载到猴牛马月，下载下来hdc在command-line-tools/sdk/default/openharmony/toolchains
当然了，我们可以精简文件，我发现只需要 hdc和libusb_shared.dylib 两个文件，所以直接把这两个文件打包的一个zip放在了gitee上（大约1.7M），放到cdn上供我们的脚本去下载,这样我们可以使用cur去下载，当然这个最好放在自己公司的cdn上，方便下载

首先创建install.sh的脚本

首先定义几个常量

• hdcZip：下载下来的zip名


• hdcTool：解压出来放到本文件夹


• hdcPath：使用hdc命令的path


• bundleName：自己的bundleName


• entryAbility：要打开的Ability

# 下载下来的文件

hdcZip="tools.zip"

# 解压的文件夹 ,解压默认是和 install.sh 脚本在同一个目录

hdcTool="tools"

# hdc文件路径"

hdcPath="tools/hdc"

#包名

bundleName="com.nzy.installapp"

# 要打开的Ability

entryAbility="EntryAbility"

定义打印

• printInfo：打印正常信息


• printError：打印错误信息，并且会调用exit 1

function printInfo() {

    # ANSI 转义码颜色 绿色

    local message=$1

    printf "\e[32m%s\e[0m\n" "$message" # Info

}



function printError() {

    # ANSI 转义码颜色 红色

    local message=$1

    printf "\e[31m%s\e[0m\n" "错误：$message"

    # 退出程序

    exit 1

}

检查和下载hdc

if [ ! -f "${hdcPath}" ]; then

      # 不存在开始下载

      printInfo "首次需要下载hdc工具，2M"

       URL="https://gitee.com/zhiyangnie/install-shell/raw/master/tools.zip"

      # 下载到当前目录的 tools.zip

      # 使用 curl 下载

      curl -o  "$hdcZip" "$URL"

     if [ $? -eq 0 ]; then

          printInfo "下载成功，准备解压${hdcZip}..."

          # 解压ZIP文件

          unzip -o "$hdcZip" -d "${hdcTool}"

          # 检查解压是否成功

          if [ $? -eq 0 ]; then

              printInfo "${hdcZip}解压成功"

              # 删除zip

              rm "$hdcZip"

          else

              printError "${hdcZip} 解压失败，请手动解压"

          fi

      else

          printError "下载失败，请检查网络"

        fi

  fi

判断hdc是否可用以及连接手机数量

# 判断是否连接手机且仅有一个手机

devicesList=$(${hdcPath} list targets)



# 判断是否hdc 可用

if [ -z "$devicesList" ]; then

  # 开始下载zip

  print_error "hdc 不可用 ，请检查本目录是否存在 ${hdcPath}"

fi



# 判断是否连接手机,如果有 [Empty] 表明 一个手机也没连接

if [[ "$devicesList" == *"[Empty]"* ]]; then

    printError "未识别到手机，请连接手机，打开开发者选项和USB调试"

fi





# 判断连接手机的个数

deviceCount=$(${hdcPath} list targets | wc -l)

if [ "$deviceCount" -ne 1 ]; then

    printError "错误：连接的手机个数是 ${deviceCount} 个,请连接一个手机"

fi



printInfo "连接到手机，且仅有一个手机 ${devicesList}"

检测传入app的路径是否存是以.app结尾，并且文件存在

# 传过来的参数是 ，获取输入的 app 文件

appFile="$1"



# 判读传过来的路径文件是否以.app 结尾

if [[ ! "${appFile}" =~ .app ]]; then

    printError "请传入正确的包路径，文件要 .app 结尾"

fi



# 判断文件是否存在

if [ ! -e "$appFile" ]; then

    printError "不存在改文件 $appFile 。请确认"

fi

开始安装

#------------------------------开始安装----------------------------------

# 开始安装

printInfo "开始安装应用, ${bundleName}"

# 1.先kill当前app的进程

$hdcPath shell aa force-stop "$bundleName"



# hdc shell mkdir data/local/tmp/c3af89b189d2480395ce746621ce6385

# 2.创建随机文件夹

randomHex=$(xxd -l 16 -p /dev/urandom)

randomFile="data/local/tmp/$randomHex"

mkDirSuccess=$($hdcPath shell mkdir "$randomFile" 2>&1)

if [ -n "$mkDirSuccess" ]; then

  printError "手机中:随机创建文件夹 ${randomFile} 失败 , $mkDirSuccess"

else

  printInfo "手机中:创建随机文件夹 ${randomFile} 成功"

fi

# 3.解压.app中

# 在本地创建 tmp 临时文件夹

tmp="tmp"

# 存在先删除

if [ -d "${tmp}" ]; then

  rm -rf "$tmp"

fi

mkdir -p "$tmp"

# 解压.app ,使用 unUse 主要是 不想打印那么多的解压日志

unUse=$(unzip -o "$appFile" -d "$tmp")

if [ $? -eq 0 ]; then

    printInfo "解压app成功"

else

    printError "解压app失败，请传入正确的app。$appFile , "

fi





printInfo "遍历解压发送到 手机的$randomFile"

# 4.遍历 tmp 文件夹中的文件发送到 randomFile 中

for item in "${tmp}"/*; do

    if [ -f "$item" ]; then

      # 发送 以 .hsp 或 .hap 结尾。

      if [[ "$item" == *.hsp || "$item" == *.hap ]]; then

          $hdcPath file send "$item" "$randomFile"

      fi

    fi

done

printInfo "成功发送到 手机的$randomFile "



# 5. 使用 install

# hdc shell bm install -p data/local/tmp/c3af89b189d2480395ce746621ce6385



installStatus=$($hdcPath shell bm install -p "$randomFile" 2>&1)

if [[ "$installStatus" == *"successfully"* ]]; then

  printInfo "┌────────────────────────────────────────────────────────"

  printInfo "│ ✅ 安装成功 "

  printInfo "└────────────────────────────────────────────────────────"

  ${hdcPath} shell aa start -a "${entryAbility}" -b "$bundleName"

else

   printf "\e[31m%s\e[0m\n" "┌────────────────────────────────────────────────────────"

   printf "\e[31m%s\e[0m\n" "│❌ 安装错误"

   echo "$installStatus" | while IFS= read -r line; do

   printf "\e[31m%s\e[0m\n" "│${line}"

   done

   printf "\e[31m%s\e[0m\n" "│错误码：https://developer.huawei.com/consumer/cn/doc/harmonyos-guides-V5/bm-tool-V5"

   printf "\e[31m%s\e[0m\n" "└────────────────────────────────────────────────────────"



fi

删除文件

# 删除 手机端的 $randomFile

${hdcPath} shell rm -rf "$randomFile"

# 删除本地的tmp文件夹

rm -rf "$tmp"

使用

进入install.sh父目录，执行

./install.sh [包的路径]

注意点

如果自己编写的的时候，如果执行 ./install.sh 的时候 报错 zsh: permission denied: ./install.sh，证明 这个shell脚本没有运行权限，可以使用ls -l install.sh 检测 权限，如果是
-rw-r--r-- 是没有权限的，然后执行 chmod +x install.sh ，就会加上权限，然后在执行ls -l install.sh ，可以看到-rwxr-xr-x，然后就可以 执行 ./install.sh了

地址

• 源码地址 gitee，脚本以及hdc也在这里


• hdc（1.7M）


• shell脚本

真机上安装需要正式手动签名

当我们签名之后的app，虽然这个app是签名的，但是里面的hap和hsp是没有签名的，所以我们要用脚本把hap和shp都要进行手动签名。一般是打包工具比如Jenkins 来做这个工作，因为正式签名不会让研发拿到，更不会让QA拿到。
需要手动签名，参考：

• 注册调试设备


• 手动签名


• 申请调试证书


• 申请调试Profile


• 对HAP进行签名

签名

appCertFile="sign/install.cer"

profileFile="sign/install.p7b"

keystoreFile="sign/install.p12"

keyAlias="zhiyang"

keyPwd="a123456A"

keystorePwd="a123456A"

java -jar tools/lib/hap-sign-tool.jar sign-app -keyAlias "${keyAlias}" -signAlg "SHA256withECDSA" -mode "localSign" -appCertFile "${appCertFile}" -profileFile "${profileFile}" -inFile "${inputFile}" -keystoreFile "${keystoreFile}" -outFile "${outputFile}" -keyPwd "${keyPwd}" -keystorePwd "${keystorePwd}"

• Store file：选择密钥库文件，文件后缀为.p12，该文件为生成密钥和证书请求文件中生成的.p12文件。


• Store password：输入密钥库密码，该密码与生成密钥和证书请求文件中填写的密钥库密码保持一致。


• Key alias：输入密钥的别名信息，与生成密钥和证书请求文件中填写的别名保持一致。


• Key password：输入密钥的密码，与生成密钥和证书请求文件中填写的Store Password保持一致。


• Sign alg：签名算法，固定为SHA256withECDSA。


• Profile file：选择申请调试证书和调试Profile文件中生成的Profile文件，文件后缀为.p7b。


• Certpath file：选择申请调试证书和调试Profile文件中生成的数字证书文件，文件后缀为.cer。

对hsp和hap签名

手动签名需要hap-sign-tool.jar,在command-line-tools/sdk/default/openharmony/toolchains/libs/hap-sign-tool.jar并且需要java文件，也都放到项目中了
在脚本中解压app之后，发送到手机之前，对所有的hsp和hap签名

代码如下

signHapAndHsp(){

  appCertFile="sign/install.cer"

  profileFile="sign/install.p7b"

  keystoreFile="sign/install.p12"

  keyAlias="zhiyang"

  keyPwd="a123456A"

  keystorePwd="a123456A"

  javaFile="lib/java"

  hapSignToolFile="lib/hap-sign-tool.jar"

  local item=$1

  #遍历文件夹，拿到所有的hsp和hap去签名

  for item in "${tmp}"/*; do

      if [ -f "$item" ]; then

        # 发送 以 .hsp 或 .hap 结尾。

        if [[ "$item" == *.hsp || "$item" == *.hap ]]; then

          # 开始签名

            local inputFile="${item}"

            outputFile=""

            if [[ "$inputFile" == *.hap ]]; then

              outputFile="${inputFile%.hap}-sign.hap"

            else

              outputFile="${inputFile%.hsp}-sign.hsp"

            fi

            signStatus=$(java -jar tools/lib/hap-sign-tool.jar sign-app -keyAlias "${keyAlias}" -signAlg "SHA256withECDSA" -mode "localSign" -appCertFile "${appCertFile}" -profileFile "${profileFile}" -inFile "${inputFile}" -keystoreFile "${keystoreFile}" -outFile "${outputFile}" -keyPwd "${keyPwd}" -keystorePwd "${keystorePwd}" -signCode "1" 2>&1)

            signStatus=$(${javaFile} -jar "${hapSignToolFile}" sign-app -keyAlias "${keyAlias}" -signAlg "SHA256withECDSA" -mode "localSign" -appCertFile "${appCertFile}" -profileFile "${profileFile}" -inFile "${inputFile}" -keystoreFile "${keystoreFile}" -outFile "${outputFile}" -keyPwd "${keyPwd}" -keystorePwd "${keystorePwd}" -signCode "1" 2>&1)

            if [[ "$signStatus" == *"failed"* || $signStatus == *"No such file or directory"* ]]; then

              printError "签名失败，${signStatus}"

            else

              printInfo "签名成功，${inputFile} , ${outputFile} , ${signStatus}"

              #删除以前未签名的

              rm -f "$inputFile"

            fi

        fi

      fi

  done

  printInfo "签名完成，${signStatus}"



}

注意点

如果报错是
code:9568322
error: signature verification failed due to not trusted app source.表明你的真机需要在添加你的设备，参考注册调试设备

这是真机的效果

在shell文件夹运行 ./install.sh ./InstallApp-default-signed.app

使用我demo，如果要写手动签名脚本，需要更换sign文件夹，自己去申请签名,并且要更换bundleName，因为你的设备并没有在我的华为Profile里面添加

前言

但凡用过鸿蒙原生弹窗的小伙伴，就能体会到它们是有多么的难用和奇葩，什么AlertDialog，CustomDialog，SubWindow，bindXxx，只要大家用心去体验，就能发现他们有很多离谱的设计和限制，时常就是一边用，一边骂骂咧咧的吐槽

实属无奈，就把鸿蒙版的SmartDialog写出来了

flutter自带的dialog是可以应对日常场景，例如：简单的打开一个弹窗，非UI模块使用，跨页面交互之类；flutter_smart_dialog 是补齐了大多数的业务场景和一些强大的特殊能力，flutter_smart_dialog 对于flutter而言，日常场景是锦上添花，特殊场景是雪中送炭

但是 ohos_smart_dialog 对于鸿蒙而言，日常场景就是雪中送炭！单单一个使用方式而言，就是吊打鸿蒙的CustomDialog，CustomDialog的各种限制和使用方式，我不想再去提及和吐槽了

有时候，简洁的使用，才是最大的魅力

鸿蒙版的SmartDialog有什么优势？

• 单次初始化后即可使用，无需多处配置相关Component


• 优雅，极简的用法


• 非UI区域内使用，自定义Component


• 返回事件处理，优化的跨页面交互


• 多弹窗能力，多位置弹窗：上下左右中间


• 定位弹窗：自动定位目标Component


• 极简用法的loading弹窗


• 等等......

目前 flutter_smart_dialog 的代码量16w+，完整复刻其功能，工作量非常大，目前只能逐步实现一些基础能力，由于鸿蒙api的设计和相关限制，用法和相关初始化都有一定程度的妥协

鸿蒙版本的SmartDialog，功能会逐步和 flutter_smart_dialog 对齐（长期），api会尽量保持一致

效果

• Tablet 模拟器目前有些问题，会导致动画闪烁，请忽略；注：真机动画丝滑流畅，无任何问题

极简用法

// dialog

SmartDialog.show({

  builder: dialogArgs,

  builderArgs: Math.random(),

})



@Builder

function dialogArgs(args: number) {

  Text(args.toString()).padding(50).backgroundColor(Color.White)

}



// loading

SmartDialog.showLoading()

安装

• github：github.com/xdd666t/oho…


• ohos：ohpm.openharmony.cn/#/cn/detail…

ohpm install ohos_smart_dialog 

配置

下述的配置项，可能会有一点多，但，这也是为了极致的体验；同时也是无奈之举，相关配置难以在内部去闭环处理，只能在外部去配置

这些配置，只需要配置一次，后续无需关心

完成下述的配置后，你将可以在任何地方使用弹窗，没有任何限制

初始化

• 注：内部已使用无感路由注册，外部无需手动处理

@Entry

@Component

struct Index {

  navPathStack: NavPathStack = new NavPathStack()



  build() {

    Stack() {

      Navigation(this.navPathStack) {

        MainPage()

      }

      .mode(NavigationMode.Stack)

      .hideTitleBar(true)

      .navDestination(pageMap)



      // here dialog init

      OhosSmartDialog()

    }.height('100%').width('100%')

  }

}

返回事件监听

别问我为啥返回事件的监听，处理的这么不优雅，鸿蒙里面没找全局返回事件监听，我也没辙。。。

• 如果你无需处理返回事件，可以使用下述写法

// Entry页面处理

@Entry

@Component

struct Index {

  onBackPress(): boolean | void {

    return SmartDialog.onBackPressed()()

  }

}



// 路由子页面

struct JumpPage {

  build() {

    NavDestination() {

      // ....

    }

    .onBackPressed(SmartDialog.onBackPressed())

  }

}

• 如果你需要处理返回事件，在SmartDialog.onBackPressed()中传入你的方法即可

// Entry页面处理

@Entry

@Component

struct Index {

  onBackPress(): boolean | void {

    return SmartDialog.onBackPressed(this.onCustomBackPress)()

  }



  onCustomBackPress(): boolean {

    return false

  }

}



// 路由子页面

@Component

struct JumpPage {

  build() {

    NavDestination() {

      // ...

    }

    .onBackPressed(SmartDialog.onBackPressed(this.onCustomBackPress))

  }



  onCustomBackPress(): boolean {

    return false

  }

}

适配暗黑模式

• 为了极致的体验，深色模式切换时，打开态弹窗也应刷新为对应模式的样式，故需要进行下述配置

export default class EntryAbility extends UIAbility {  

  onConfigurationUpdate(newConfig: Configuration): void {  

    OhosSmartDialog.onConfigurationUpdate(newConfig)  

  }  

}

SmartConfig

• 支持全局配置弹窗的默认属性

function init() {

  // show

  SmartDialog.config.custom.maskColor = "#75000000"

  SmartDialog.config.custom.alignment = Alignment.Center



  // showAttach

  SmartDialog.config.attach.attachAlignmentType = SmartAttachAlignmentType.center

}

• 检查弹窗是否存在

// 检查当前是否有CustomDialog，AttachDialog或LoadingDialog处于打开状态

let isExist = SmartDialog.checkExist()



// 检查当前是否有AttachDialog处于打开状态

let isExist = SmartDialog.checkExist({ dialogTypes: [SmartAllDialogType.attach] })



// 检查当前是否有tag为“xxx”的dialog处于打开状态

let isExist = SmartDialog.checkExist({ tag: "xxx" })

配置全局默认样式

• ShowLoading 自定样式十分简单

SmartDialog.showLoading({ builder: customLoading })

但是对于大家来说，肯定是想用 SmartDialog.showLoading() 这种简单写法，所以支持自定义全局默认样式

• 需要在 OhosSmartDialog 上配置自定义的全局默认样式

@Entry

@Component

struct Index {

  build() {

    Stack() {

      OhosSmartDialog({

        // custom global loading

        loadingBuilder: customLoading,

      })

    }.height('100%').width('100%')

  }

}



@Builder

export function customLoading(args: ESObject) {

  LoadingProgress().width(80).height(80).color(Color.White)

}

• 配置完你的自定样式后，使用下述代码，就会显示你的 loading 样式

SmartDialog.showLoading()



// 支持入参，可以在特殊场景下灵活配置

SSmartDialog.showLoading({ builderArgs: 1 })

CustomDialog

• 下方会共用的方法

export function randomColor(): string {

  const letters: string = '0123456789ABCDEF';

  let color = '#';

  for (let i = 0; i < 6; i++) {

    color += letters[Math.floor(Math.random() * 16)];

  }

  return color;

}



export function delay(ms?: number): Promise<void> {

  return new Promise(resolve => setTimeout(resolve, ms));

}

传参弹窗

export function customUseArgs() {

  SmartDialog.show({

    builder: dialogArgs,

    // 支持任何类型

    builderArgs: Math.random(),

  })

}



@Builder

function dialogArgs(args: number) {

  Text(`${args}`).fontColor(Color.White).padding(50)

    .borderRadius(12).backgroundColor(randomColor())

}

多位置弹窗

export async function customLocation() {

  const animationTime = 1000

  SmartDialog.show({

    builder: dialogLocationHorizontal,

    alignment: Alignment.Start,

  })

  await delay(animationTime)

  SmartDialog.show({

    builder: dialogLocationVertical,

    alignment: Alignment.Top,

  })

}





@Builder

function dialogLocationVertical() {

  Text("location")

    .width("100%")

    .height("20%")

    .fontSize(20)

    .fontColor(Color.White)

    .textAlign(TextAlign.Center)

    .padding(50)

    .backgroundColor(randomColor())

}



@Builder

function dialogLocationHorizontal() {

  Text("location")

    .width("30%")

    .height("100%")

    .fontSize(20)

    .fontColor(Color.White)

    .textAlign(TextAlign.Center)

    .padding(50)

    .backgroundColor(randomColor())

}

跨页面交互

• 正常使用，无需设置什么参数

export function customJumpPage() {

  SmartDialog.show({

    builder: dialogJumpPage,

  })

}



@Builder

function dialogJumpPage() {

  Text("JumPage")

    .fontSize(30)

    .padding(50)

    .borderRadius(12)

    .fontColor(Color.White)

    .backgroundColor(randomColor())

    .onClick(() => {

      // 跳转页面

    })

}

关闭指定弹窗

export async function customTag() {

  const animationTime = 1000

  SmartDialog.show({

    builder: dialogTagA,

    alignment: Alignment.Start,

    tag: "A",

  })

  await delay(animationTime)

  SmartDialog.show({

    builder: dialogTagB,

    alignment: Alignment.Top,

    tag: "B",

  })

}



@Builder

function dialogTagA() {

  Text("A")

    .width("20%")

    .height("100%")

    .fontSize(20)

    .fontColor(Color.White)

    .textAlign(TextAlign.Center)

    .padding(50)

    .backgroundColor(randomColor())

}



@Builder

function dialogTagB() {

  Flex({ wrap: FlexWrap.Wrap }) {

    ForEach(["closA", "closeSelf"], (item: string, index: number) => {

      Button(item)

        .backgroundColor("#4169E1")

        .margin(10)

        .onClick(() => {

          if (index === 0) {

            SmartDialog.dismiss({ tag: "A" })

          } else if (index === 1) {

            SmartDialog.dismiss({ tag: "B" })

          }

        })

    })

  }.backgroundColor(Color.White).width(350).margin({ left: 30, right: 30 }).padding(10).borderRadius(10)

}

自定义遮罩

export function customMask() {

  SmartDialog.show({

    builder: dialogShowDialog,

    maskBuilder: dialogCustomMask,

  })

}



@Builder

function dialogCustomMask() {

  Stack().width("100%").height("100%").backgroundColor(randomColor()).opacity(0.6)

}



@Builder

function dialogShowDialog() {

  Text("showDialog")

    .fontSize(30)

    .padding(50)

    .fontColor(Color.White)

    .borderRadius(12)

    .backgroundColor(randomColor())

    .onClick(() => customMask())

}

AttachDialog

默认定位

export function attachEasy() {

  SmartDialog.show({

    builder: dialog

  })

}



@Builder

function dialog() {

  Stack() {

    Text("Attach")

      .backgroundColor(randomColor())

      .padding(20)

      .fontColor(Color.White)

      .borderRadius(5)

      .onClick(() => {

        SmartDialog.showAttach({

          targetId: "Attach",

          builder: targetLocationDialog,

        })

      })

      .id("Attach")

  }

  .borderRadius(12)

  .padding(50)

  .backgroundColor(Color.White)

}



@Builder

function targetLocationDialog() {

  Text("targetIdDialog")

    .fontSize(20)

    .fontColor(Color.White)

    .textAlign(TextAlign.Center)

    .padding(50)

    .borderRadius(12)

    .backgroundColor(randomColor())

}

多方向定位

export function attachLocation() {

  SmartDialog.show({

    builder: dialog

  })

}



class AttachLocation {

  title: string = ""

  alignment?: Alignment

}



const locationList: Array<AttachLocation> = [

  { title: "TopStart", alignment: Alignment.TopStart },

  { title: "Top", alignment: Alignment.Top },

  { title: "TopEnd", alignment: Alignment.TopEnd },

  { title: "Start", alignment: Alignment.Start },

  { title: "Center", alignment: Alignment.Center },

  { title: "End", alignment: Alignment.End },

  { title: "BottomStart", alignment: Alignment.BottomStart },

  { title: "Bottom", alignment: Alignment.Bottom },

  { title: "BottomEnd", alignment: Alignment.BottomEnd },

]



@Builder

function dialog() {

  Column() {

    Grid() {

      ForEach(locationList, (item: AttachLocation) => {

        GridItem() {

          buildButton(item.title, () => {

            SmartDialog.showAttach({

              targetId: item.title,

              alignment: item.alignment,

              maskColor: Color.Transparent,

              builder: targetLocationDialog

            })

          })

        }

      })

    }.columnsTemplate('1fr 1fr 1fr').height(220)



    buildButton("allOpen", async () => {

      for (let index = 0; index < locationList.length; index++) {

        let item = locationList[index]

        SmartDialog.showAttach({

          targetId: item.title,

          alignment: item.alignment,

          maskColor: Color.Transparent,

          builder: targetLocationDialog,

        })

        await delay(300)

      }

    }, randomColor())

  }

  .borderRadius(12)

    .width(700)

    .padding(30)

    .backgroundColor(Color.White)

}



@Builder

function buildButton(title: string, onClick?: VoidCallback, bgColor?: ResourceColor) {

  Text(title)

    .backgroundColor(bgColor ?? "#4169E1")

    .constraintSize({ minWidth: 120, minHeight: 46 })

    .margin(10)

    .textAlign(TextAlign.Center)

    .fontColor(Color.White)

    .borderRadius(5)

    .onClick(onClick)

    .id(title)

}



@Builder

function targetLocationDialog() {

  Text("targetIdDialog")

    .fontSize(20)

    .fontColor(Color.White)

    .textAlign(TextAlign.Center)

    .padding(50)

    .borderRadius(12)

    .backgroundColor(randomColor())

}

Loading

对于Loading而言，应该有几个比较明显的特性

• loading和dialog都存在页面上，哪怕dialog打开，loading都应该显示dialog之上


• loading应该具有单一特性，多次打开loading，页面也应该只存在一个loading


• 刷新特性，多次打开loading，后续打开的loading样式，应该覆盖之前打开的loading样式


• loading使用频率非常高，应该支持强大的拓展和极简的使用

从上面列举几个特性而言，loading是一个非常特殊的dialog，所以需要针对其特性，进行定制化的实现

当然了，内部已经屏蔽了细节，在使用上，和dialog的使用没什么区别

默认loading

SmartDialog.showLoading()

自定义Loading

• 点击loading后，会再次打开一个loading，从效果图可以看出它的单一刷新特性

export function loadingCustom() {

  SmartDialog.showLoading({

    builder: customLoading,

  })

}



@Builder

export function customLoading() {

  Column({ space: 5 }) {

    Text("again open loading").fontSize(16).fontColor(Color.White)

    LoadingProgress().width(80).height(80).color(Color.White)

  }

  .padding(20)

  .borderRadius(12)

  .onClick(() => loadingCustom())

  .backgroundColor(randomColor())

}

最后

鸿蒙版的SmartDialog，相信会对开发鸿蒙的小伙伴们有一些帮助~.~

现在就业环境真是让人头皮发麻，现在的各种技术群里，看到好多人公司各种拖欠工资，各种失业半年的情况

淦，不知道还能写多长时间代码！

众所周知，DevEco也是基于Jetbrain的IntelliJ IDEA社区版开发，所以原则上也是可以开启NewUI的。

开了NewUI的样子：

没开NewUI的样子：

从我的审美来说，我还是比较喜欢开了NewUI的样子😁。

如何开始NewUI

双击shift打开搜索窗口，输入Registry，然后打开。接着打开experimental属性中的ui部分就可以了，最后只需要重启，你就能愉快的写代码🌶。

最近在学 ArkTS UI 发现其与 Swift UI 非常像，于是做了一下对比，发现可探索性很强。

Hello World 代码对比

从 Hello World 来看两者就非常像。

鸿蒙 ArtTs UI 的 Hello World 如下：

@Entry  

@Component  

struct Index {  

  @State message: string = 'Hello World';  

  

  build() {  

    RelativeContainer() {  

      Text(this.message)  

        .id('HelloWorld')  

        .fontSize(50)  

        .fontWeight(FontWeight.Bold)  

        .alignRules({  

          center: { anchor: '__container__', align: VerticalAlign.Center },  

          middle: { anchor: '__container__', align: HorizontalAlign.Center }  

        })  

    }  

    .height('100%')  

    .width('100%')  

  }  

}

Swift UI 的 Hello World 如下：

import SwiftUI



struct ContentView: View {

    var body: some View {

        VStack {

            Image(systemName: "globe")

                .imageScale(.large)

                .foregroundStyle(.tint)

            Text("Hello, world!")

        }

        .padding()

    }

}



#Preview {

    ContentView()

}

同样的 struct 开头，同样的 声明方式，同样的 Text，同样的设置外观属性方法。
不同的是 ArkTS 按照 Typescript 的写法，以装饰器起头，以 build 方法作为初始化的入口，build 里面才是元素；而 Swift UI 整个 ContentView 就是一个大元素，然后开始潜逃内部元素。

声明式 UI 描述

显然，两者都是用了 声明式的 UI 描述。

个人总结声明式 UI 的公式如下：

Element(props) {

	SubElement...

}.attribute(value)



元素(元素属性配置) {

	子元素

}.元素外观属性(元素外观)

因为 ArkTS 本质上是 Typescript / Javascript ，所以其写法要符合 TS/JS 的写法，引入的属性、变量必须有明确指示。

Text(this.message)  // message 是当前页面引入的，要有 this

        .id('HelloWorld')  

        .fontSize(50)  

        .fontWeight(FontWeight.Bold)  // Bold 是公共常量 FontWeight 的其中一值

对于前端来说，简单易读。这里的 Text 传入一个 message，然后标记 id 为 HelloWorld，设置字体为 50，字重为粗体。

而 Swift 或许更符合苹果以前 Obj C 迁移过来的人的写法。

Image(systemName: "globe") // 公共库名：公共库的值

                .imageScale(.large) // .large 是公共常量的一个值

                .foregroundStyle(.tint)// .tint 是公共常量的一个值

这里的 Image 引入了公共图标库的一个 globe 的图标，然后设置图片大小为大，前景样式为系统主题的颜色，Image(systemName: "globe") 明显不符合 new 一个类的定义方法，.imageScale(.large) 和 .foregroundStyle(.tint) 也不符合参数的使用，按以前的解读会有点让人懵圈。

如果转换成 Typescipt 应该是这样的：

new Image(SystemIcon.globe)

                .imageScale(CommonSize.large)

                .foregroundStyle(CommonColor.tint)

显然 ArkTS 更符合前端人的阅读、书写习惯。但其实掌握 Swift UI 也并不难，只需要记住 Swift UI 的这些细小差别，写两次也能顺利上手了。

声明式 UI 的耦合性争议

也许不少人会对声明式 UI 的耦合性（M和V耦合在一起）反感。但是在前端来说，除了以前的 的 MVC 框架 Angular.js 外，其余框架即使是 MVVM，也很少能做到解耦合的，特别是单功能内和业务数据交互的耦合。

所以，前端耦合性，还是需要自行处理。

Button({

	action: handleGoButton

}).{

	Text("Go")

}



// 自行决定 handleGoButton 是否需要放在外部文件中

private func handleGoButton() {

 ...

}



// 数据耦合在 UI 中，无解

ZStack {

    Color(selectedImageIndex == index ?

        Color.hex("808080") : Color.hex("585857")) // 选中的背景颜色区别一般的

  ...

}

前端的解耦合最终还是需要靠组件化、高阶函数来完成：

组件差异

SwiftUI 和鸿蒙操作系统的 ArtTS UI 框架都提供了多种组件，按前端使用情况，其实同样有很多相同之处。

基础组件

基础组件基本相同：

• Text 用于显示文本；


• Image 用于显示图片；


• Button 用户可以点击执行操作；

布局组件

Swift UI 和 ArkTS 相同/相似的布局组件有：

可以看出，两者基本上的布局都可以通用，当然细节上肯定会有很多不同。不过做一个转译应该不难，可以尝试使用 AI 来完成。

不同的地方在于 Flex 和 Grid 布局：

SwiftUI的布局系统非常灵活，可以通过调整alignment、spacing、padding等属性来实现复杂的布局需求。虽然它不完全等同于CSS中的Flexbox和Grid，但是通过组合使用不同的布局视图，创建出丰富多样的布局效果。

个人在实际开发 iOS 中，通过基础的布局组件搭配，就能完美的实现弹性布局和网格布局。

表单组件

Ark TS UI 提供了一系列的组件，更接近于 html 同名的组件：

• TextInput：用于文本输入。


• CheckBox 和 Switch：用于布尔值的选择。


• Radio：用于单选按钮组，类似于 HTML 中的单选按钮。


• Picker：用于选择器，可以用于日期选择、时间选择或简单的选项选择，类似于 HTML 中的 <select>。

Ark TS UI 表单组件的特点在于它们与数据绑定紧密集成，可以通过 @State、@Link 和 @Prop 等装饰器来管理表单的状态和数据流。

而 Swift UI 也有类似的表单组件，但是大部分都不相同：

• TextField：用于文本输入，可以包含占位符文本。


• SecureField：用于密码输入，隐藏输入内容。


• Picker：用于选择器，可以用于选择单个值或多个值。


• Toggle：用于布尔值的选择，类似于开关。


• DatePicker：用于日期和时间选择。


• Slider 和 Stepper：用于数值选择，Slider 提供连续值选择，而 Stepper 提供步进值选择。


• Form：一个容器视图，用于组织输入表单数据，使得表单的创建和管理更为方便。

虽然不能一一对应，但像日期选择器那样，目前大部分用户已经基本适应了 android 和 iOS 的差异。

总结 - 可运用 AI 转译

通过这次对比学习，可以得出以下结论：

第四点，个人觉得难度不大，本人用代码差异非常大的 android app 转译 iOS app 的也能成功，只是一个个页面进行调试花了不少时间。

至于先开发哪个 app 看你个人习惯，如果你是老 iOS 开发，可以使用先开发 iOS 再进行鸿蒙 OS 开发；甚至 react native 开发生成 iOS 之后，通过生成的 iOS 代码进行转译鸿蒙 OS app。如果你没有之前的负担，完全可以学习 ArkTS，更快地入手，然后通过转译 iOS app 来学习 Swift。

跨窗口通信的九重天劫：从postMessage到BroadcastChannel

第一重：postMessage 基础劫 —— 安全与效率的平衡术

// 父窗口发送

const child = window.open('child.html');

child.postMessage({ type: 'AUTH_TOKEN', token: 'secret' }, 'https://your-domain.com');



// 子窗口接收

window.addEventListener('message', (e) => {

  if (e.origin !== 'https://parent-domain.com') return;

  console.log('收到消息:', e.data);

});

安全守则：

第二重：MessageChannel 双生劫 —— 高性能私有通道

// 建立通道

const channel = new MessageChannel();



// 端口传递

parentWindow.postMessage('INIT_PORT', '*', [channel.port2]);



// 接收端处理

channel.port1.onmessage = (e) => {

  console.log('通过专用通道收到:', e.data);

};



// 发送消息

channel.port1.postMessage({ priority: 'HIGH', payload: data });

性能优势：

• 相比普通postMessage减少50%的序列化开销


• 支持传输10MB以上文件（Chrome实测）

第三重：BroadcastChannel 广播劫 —— 同源全域通信

// 发送方

const bc = new BroadcastChannel('app-channel');

bc.postMessage({ event: 'USER_LOGOUT' });



// 接收方

const bc2 = new BroadcastChannel('app-channel');

bc2.onmessage = (e) => {

  if (e.data.event === 'USER_LOGOUT') {

    localStorage.clear();

  }

};

适用场景：

• 多标签页状态同步


• 全局事件通知系统


• 跨iframe配置更新

第四重：SharedWorker 共享劫 —— 持久化通信枢纽

// worker.js

const connections = [];

onconnect = (e) => {

  const port = e.ports[0];

  connections.push(port);

  

  port.onmessage = (e) => {

    connections.forEach(conn => {

      if (conn !== port) conn.postMessage(e.data);

    });

  };

};



// 页面使用

const worker = new SharedWorker('worker.js');

worker.port.start();

worker.port.postMessage('来自页面的消息');

内存管理：

• 每个SharedWorker实例共享同一个全局作用域


• 需要手动清理断开连接的端口

第五重：localStorage 事件劫 —— 投机取巧的同步

// 页面A

localStorage.setItem('sync-data', JSON.stringify({

  timestamp: Date.now(),

  data: '重要更新'

}));



// 页面B

window.addEventListener('storage', (e) => {

  if (e.key === 'sync-data') {

    const data = JSON.parse(e.newValue);

    console.log('跨页更新:', data);

  }

});

致命缺陷：

• 事件仅在其他页面触发


• 同步API导致主线程阻塞


• 无法传递二进制数据

第六重：IndexedDB 观察劫 —— 数据库驱动通信

// 建立观察者

let lastVersion = 0;

const db = await openDB('msg-db', 1);



db.transaction('messages')

  .objectStore('messages')

  .openCursor().onsuccess = (e) => {

    const cursor = e.target.result;

    if (cursor && cursor.value.version > lastVersion) {

      lastVersion = cursor.value.version;

      handleMessage(cursor.value);

    }

  };



// 写入新消息

await db.add('messages', {

  version: Date.now(),

  content: '新订单通知'

});

适用场景：

• 需要持久化保存的通信记录


• 离线优先的跨窗口消息队列

第七重：Window.name 穿越劫 —— 上古秘术

// 页面A

window.name = JSON.stringify({ session: 'temp123' });

location.href = 'pageB.html';



// 页面B

const data = JSON.parse(window.name);

console.log('穿越传递:', data);

安全警告：

• 数据暴露在所有同源页面


• 最大容量约2MB


• 现代应用已不建议使用

第八重：Server-Sent Events (SSE) 服务劫 —— 服务器中转

// 服务端（Node.js）

app.get('/updates', (req, res) => {

  res.setHeader('Content-Type', 'text/event-stream');

  setInterval(() => {

    res.write(`data: ${Date.now()}\n\n`);

  }, 1000);

});



// 浏览器端

const es = new EventSource('/updates');

es.onmessage = (e) => {

  allWindows.forEach(w => w.postMessage(e.data));

};

架构优势：

• 支持跨设备同步


• 自动重连机制


• 与WebSocket互补（单向vs双向）

第九重：WebSocket 广播劫 —— 实时通信终极形态

// 共享连接管理

const wsMap = new Map();



function connectWS() {

  const ws = new WebSocket('wss://push.your-app.com');

  

  ws.onmessage = (e) => {

    const data = JSON.parse(e.data);

    if (data.type === 'BROADCAST') {

      broadcastToAllTabs(data.payload);

    }

  };

  

  return ws;

}



// 页面可见性控制

document.addEventListener('visibilitychange', () => {

  if (document.hidden) {

    ws.close(); 

  } else {

    ws = connectWS();

  }

});

性能优化：

• 心跳包维持连接（每30秒）


• 消息压缩（JSON → ArrayBuffer）


• 退避重连策略

渡劫指南（技术选型矩阵）

graph LR

    A[是否需要持久化?] -->|是| B[IndexedDB]

    A -->|否| C{实时性要求}

    C -->|高| D[WebSocket]

    C -->|中| E[BroadcastChannel]

    C -->|低| F[postMessage]

    B --> G[是否需要跨设备?]

    G -->|是| H[SSE/WebSocket]

    G -->|否| I[localStorage事件]

天劫问答

调试工具推荐

性能检测代码：

// 通信延迟检测

const start = performance.now();

channel.postMessage('ping');

channel.onmessage = () => {

  console.log('往返延迟:', performance.now() - start);

};

今天带大家盘点一下前端的一些冷知识。

一、浏览器地址栏的妙用

1.1 可以执行javascript代码

在地址栏中输入javascript:alert('hello world')，然后按回车键，会弹出一个提示框显示hello world。

注意：如果直接把这段代码复制到地址栏，浏览器会删除掉前面javascript:（比如谷歌浏览器、edge浏览器等），需要自己手动加上。

还可以使用location.href和window.open来执行它。

location.href = "javascript:alert('hello world')";

window.open("javascript:alert('hello world')");

1.2 可以运行html

在地址栏中输入data:text/html,<div>hello world</div>，然后按回车键，会显示一个包含hello world的div元素。

利用这个能力，我们可以把浏览器标签页变成一个编辑器。

contenteditable属性能把一个元素变成可编辑的，所以我们如果在地址栏中输入data:text/html,<html contenteditable>，就可以把页面直接变成一个编辑器了。你还可以把它收藏到书签，以后直接点击就可以打开一个编辑器了。

二、把整个在线网页变成可编辑

只需要在浏览器控制台中输入这样一行代码，就能把整个页面变成可编辑的。

document.body.contentEditable = 'true';

这样我们就能随便修改页面了，比如修改页面中的文字、图片等等，轻松实现修改账户余额去装逼！

三、利用a标签解析URL

const a = document.createElement('a');

a.href = 'https://www.baidu.com/s?a=1&b=1#hash';

console.log(a.host); // http://www.baidu.com

console.log(a.pathname); // /s

console.log(a.search); //  ?a=1&b=1

console.log(a.hash); // #hash

四、HTML的ID和全局变量的映射关系

在HTML中，如果有一个元素的id是a，那么在全局作用域中，会有一个变量a，这个变量指向这个元素。

<div id="a"></div>

<script>

  console.log(a); // <div id="a"></div>

</script>

如果id重复了，还是会生成一个全局变量，但是这个变量指向的是一个HTMLCollection类数组。

<div id="a">a</div>

<div id="a">b</div>

<script>

  console.log(a); // HTMLCollection(2) [div#a, div#a]

</script>

五、cdn加载省略协议头

<script src="//cdn.xxx.com/xxx.js"></script>

src的值以//开头，省略了协议，则在加载js时，会使用当前页面的协议进行加载。

如果当前页面是https则以https进行加载。
如果当前页面是http则以http进行加载。
如果当前页面是ftp则以ftp进行加载。

六、前端的恶作剧：隐藏鼠标光标

<style>

  * {

    cursor: none !important;

  }

</style>

直接通过css把光标隐藏，让人哭笑不得。

七、文字模糊效果

前端文本的马赛克效果，可以使用text-shadow实现。

<style>

  .text {

    color: transparent;

    text-shadow: #111 0 0 5px;

    user-select: none;

  }

</style>



<span>hello</span><span class="text">world</span>

效果如下：

八、不借助js和css，让元素消失

直接用DOM自带的hidden属性即可。

<div hidden>hello world</div>

九、保护隐私

禁用F12快捷键：

document.addEventListener('keydown', (e) => {

  if (e.keyCode === 123) {

    e.preventDefault();

  }

})

禁用右键菜单：

document.addEventListener('contextmenu', (e) => {

  e.preventDefault();

})

但即使通过禁用F12快捷键和右键菜单，用户依然可以通过其它方式打开控制台。

• Cmd+Opt+I (Mac)


• Ctrl+Shift+C (打开检查元素模式)

十、css实现三角形

<style>

  .triangle {

    width: 0;

    height: 0;

    border: 20px solid transparent;

    border-top-color: red;

  }

</style>



<div class="triangle"></div>

十一、为啥 a === a-1 结果为true

当a为Infinity无穷大时，a - 1的结果也是Infinity，所以a === a - 1的结果为true。

同理，a的值为-Infinity时，此等式也成立。

const a = Infinity;

console.log(a === a - 1);

十二、数字的包装类

console.log(1.toString()); // 报错

console.log(1..toString()); // 正常运行 输出字符串'1'

十三、防止网站以 iframe 方式被加载

if (window.location !== window.parent.location) window.parent.location = window.location;

十四、datalist的使用

datalist 是 HTML5 中引入的一个新元素，它用于为<input>元素提供预定义的选项列表。就是当用户在下拉框输入内容时，浏览器会显示一个下拉列表，列表的内容就是与当前输入内容相匹配的 datalist 选项。

<input list="fruits" name="fruit" />

<datalist id="fruits">

  <option value="苹果"></option>

  <option value="橘子"></option>

  <option value="香蕉"></option>

</datalist>

效果如下：

十五、文字纵向排列

<style>

  .vertical-text {

    writing-mode: vertical-rl;

    text-orientation: upright;

  }

</style>



<div class="vertical-text">文字纵向排列</div>

效果如下：

十六、禁止选中文字

document.addEventListener('selectstart', (e) => {

  e.preventDefault();

})

效果跟使用 css 的 user-select: none 效果类似。

十七、利用逗号，在一行中执行多个表达式

let a = 1;

let b = 2;

(a += 2), (b += 3);

十八、inset

inset是一个简写属性，用于同时设置元素的 top、right、bottom 和 left 属性

.box {

  position: absolute;

  left: 0;

  right: 0;

  top: 0;

  bottom: 0;

}

可以简写成：

.box {

  position: absolute;

  inset: 0;

}

小结

以上就是前端的18个冷知识，希望大家看完都有所收获。

Day.js 与 Moment.js 的比较

优点

• 体积小：Day.js 的体积仅为 2KB 左右，而 Moment.js 的体积约为 67KB。


• API 相似：Day.js 的 API 与 Moment.js 高度相似，迁移成本低。


• 不可变性：Day.js 的日期对象是不可变的，这意味着每次操作都会返回一个新的日期对象，避免了意外的副作用。

缺点

• 功能较少：Day.js 的功能相对 Moment.js 较少，特别是在处理时区和复杂日期操作时。


• 插件依赖：一些高级功能（如时区支持）需要通过插件实现，增加了额外的依赖。

定位与设计理念

• Moment.js

- 老牌时间处理库，2012 年发布，曾是 JavaScript 时间处理的事实标准，功能全面且语法直观。
- 设计目标：覆盖几乎所有时间处理需求，包括复杂的时区、本地化、格式化、操作等。
- 现状：2020 年进入 维护模式（不再新增功能，仅修复严重 bug），官方推荐迁移至更现代的库（如 Day.js、Luxon 等）。

• Day.js
  
  
  
  
  • 轻量替代方案，2018 年发布，设计灵感直接来源于 Moment.js，语法高度相似，但更简洁轻量。
  
  
  • 设计目标：通过最小化核心功能 + 插件机制，提供常用时间操作能力，避免过度设计。
  
  
  • 现状：持续活跃更新，由单一开发者维护，社区支持度快速增长。
  
  
  
  
  
  

核心差异对比

Dayjs中文文档

dayjs.uihtm.com/

如何将 Moment.js 替换为 Day.js

1. 安装 Day.js

首先，安装 Day.js：

npm install dayjs

2. 替换导入语句

将项目中的 Moment.js 导入语句替换为 Day.js：

// 将

import moment from 'moment';



// 替换为

import dayjs from 'dayjs';

3. 替换 API 调用

将 Moment.js 的 API 调用替换为 Day.js 的等效调用。由于两者的 API 非常相似，大多数情况下只需简单替换即可：

// Moment.js

const date = moment('2023-10-01');

console.log(date.format('YYYY-MM-DD'));



// Day.js

const date = dayjs('2023-10-01');

console.log(date.format('YYYY-MM-DD'));

4. 处理差异

在某些情况下，Day.js 和 Moment.js 的行为可能略有不同。你需要根据具体情况调整代码。例如，Day.js 的 diff 方法返回的是毫秒数，而 Moment.js 返回的是天数：

// Moment.js

const diff = moment('2023-10-02').diff('2023-10-01', 'days'); // 1



// Day.js

const diff = dayjs('2023-10-02').diff('2023-10-01', 'day'); // 1

5. 引入插件（可选）

如果你需要使用 Day.js 的高级功能（如时区支持），可以引入相应的插件：

5. 总结：如何选择？

• 选 Moment.js：如果项目依赖其成熟生态、需要兼容旧浏览器，或时间逻辑极其复杂且不愿配置插件。


• 选 Day.js：如果追求轻量、高性能、简洁 API，且能接受通过插件扩展功能（推荐新项目使用）。

import utc from 'dayjs/plugin/utc';

import timezone from 'dayjs/plugin/timezone';



dayjs.extend(utc);

dayjs.extend(timezone);



const date = dayjs().tz('America/New_York');

console.log(date.format('YYYY-MM-DD HH:mm:ss'));

总结：

两者语法高度相似，迁移成本低。若项目对体积和性能敏感，Day.js 是更优解；若功能全面性和旧项目兼容更重要，Moment.js 仍可短期使用，但长期建议迁移至活跃库（如 Day.js 或 Luxon）。

一、建设背景

    2024年1月18日，HarmonyOS NEXT鸿蒙星河版亮相，标志着“纯血鸿蒙”正式开始扬帆起航。同年6月21日，在华为开发者大会上HarmonyOS Next正式发布,并且将于第4季度发布商用版。

    中原银行App用户中华为机型占比第一，及时兼容鸿蒙系统，能够为使用华为设备的客户提供更好的服务，同时适配鸿蒙系统也可以支持我国科技创新和提升金融系统安全性。

二、建设历程

    2024年1月，中原银行App鸿蒙版项目启动；

    2024年4月，完成整体研发工作；

    2024年6月，完成功能测试、安全测试等测试工作；

    2024年6月14日，正式在华为应用市场上架。

三、关键技术

1. 混合开发框架

    中原银行鸿蒙版应用架构为四层架构，分别为基础环境层、基础库层、混合开发框架层、业务模块层。

基础环境层： 主要是一些基础设施及环境配置，如OHPM私仓搭建；

基础库层： 主要是应用中使用的基础功能组件，如网络、加解密等；

混合开发框架层： 采用混合开发模式，各业务模块以中原银行小程序的形式开发，拥有“一次开发、多端适用”和迭代发版灵活快速等特性。基于混合开发框架，原有Android和iOS上运行的小程序可无缝运行在鸿蒙设备上，极大提高开发效率。

    为进一步优化用户体验与性能，自研JsBridge，有效降低了小程序与原生系统间交互的性能损耗，确保流畅的交互体验。同时，采用离线下载机制，将小程序代码及资源通过离线包形式预先下载至本地，配合离线包校验机制，显著提升了小程序加载速度，同时增强了小程序安全性。此外，引入预加载策略，针对公共代码进行预加载处理，并使用C语言优化资源加载逻辑，进一步提升了整体加载性能。

业务模块层： 主要是应用中各业务功能，如存款、理财、登录等。

图3.1 中原银行鸿蒙版架构图

2. 传输安全

    为满足金融app对网络传输的安全、性能及复杂业务逻辑要求，使用分层拦截器将复杂的网络请求进行加解密、gzip、防重防等功能的拆分、解耦，增加网络传输过程安全性、可靠性。其中由于鸿蒙原生密钥协商算法暂不支持国密算法，项目中引入铜锁密码库，替换鸿蒙ECDH密钥协商算法，实现了对国密SM2_256的密钥协商算法支持，满足了监管对国密算法使用的要求；针对加密zip包解压和tar包文件读取，我们定制裁剪minizip-ng和libtar开源c库，通过napi实现arkTs与C库之间的相互调用，最终完成对加密zip包解压和tar包特定文件读取的支持。

图3.2 网络分层拦截器  

图3.3 加解密流程

3. OHPM私仓搭建

    由于金融网络与互联网网络隔离，金融网络环境下无法直接访问互联网上的鸿蒙中心仓库 ohpm.openharmony.cn，导致开发环境无法正常使用，同时需要一个仓库来存放私有类库，为此我们搭建了 OHPM 私有仓库,实现了金融网络环境下 OHPM 仓库的正常使用，并且可一键安装内网专用包和外网公共包，为金融网络内鸿蒙应用开发打下坚实基础。

　　具体操作为：使用OHPM 私仓搭建工具（developer.huawei.com/consumer/cn…），配置“上游”鸿蒙相关仓库地址（ohpm.openharmony.cn），通过公司内专用互联网代理通道代理到鸿蒙中心仓库。现将搭建过程遇到的部分问题总结如下：

（1）由于内网中无法申请到 HTTPS 证书，私仓无法以 HTTPS 方式部署，我们改造了 OHPM 底层网络代码，对使用 HTTPS 的“上游”仓库，改为 HTTP 代理，改造代码如下：
// 改造 ohpm 源代码，解决内网申请不了 https 证书的问题

// 文件: libs/service/uplinks/uplink-proxy/UplinkProxyService.js

// 改造 ohpm 源代码，解决内网申请不了 https 证书的问题

// 文件: libs/service/uplinks/uplink-proxy/UplinkProxyService.js

if ("https:" === t.protocol.trim()) {

  const t = e.https_proxy;

  // 对 https 的上游仓库，使用 http 代理

  t && (o = new i.HttpProxyAgent(t));

}

（2）原版搭建工具为前台启动，可靠性低，日志难以管理。在部署过程中，我们使用了守护进程管理工具PM2用于提升服务可靠性并记录日志，配置代码如下：

// 使用 pm2 实现守护进程管理

// 文件: pm2.config.js

module.exports = {

  apps: [

    {

      // 服务名称

      name: "ohpm-repo",

      // 私仓搭建工具的所在目录

      cwd: "/path/to/ohpm-repo",

      // 入口脚本

      script: "index.js",

      // 集群模式启动，提升服务可靠性

      exec_mode: "cluster",

      // 实例数量

      instances: 2,

      // 崩溃时自动重启服务

      autorestart: true,

      // 不需要监听文件变化

      watch: false,

      // 内存时重新启动

      max_memory_restart: "1G",

      // 将控制台日志输出到文件

      error_file: "./logs/ohpm-repo-error.log",

      out_file: "./logs/ohpm-repo-out.log",

      merge_logs: true,

      // 环境变量

      env_production: {

        NODE_ENV: "production",

      },

    },

  ],

};

四、鸿蒙特性实践

1. 原生智能

    鸿蒙原生系统已深度集成了多项AI能力，例如OCR识别、语音识别等。我们在个人信息设置、贷款信息录入等场景集成了鸿蒙Vision Kit组件，通过扫描身-份-证/银彳亍卡的方式录入客户信息，不仅提升了客户使用的便捷性，还确保了交易的安全性；后续还会在客户上传正件照片时集成智能PhotoPicker，当客户需要上传正件照时，系统智能地从图库中选出正件类照片优先展示，极大地提升用户使用体验；在搜索等场景集成Core Speech Kit组件，通过语音识别实现说话代替手工打字输入，使得输入操作更便捷、内容更准确，后续计划将该能力扩展至智能客服交互和老年版界面播报场景，真正地实现智能贴心服务。

2. 终端安全

鸿蒙设备为开发者提供了基于可信执行环境（TEE）的关键资产存储服务（Asset Store Kit），确保用户敏感数据无法被恶意获取和篡改。我们在可信终端识别场景，通过采集鸿蒙基础环境信息，配合相关唯一标识算法计算出设备的标识码，为防止该标识码被恶意篡改或因应用卸载重装发生变化，利用Asset Store Kit将该标识缓存于设备TEE中，再结合云端关联匹配与碰撞检测机制, 充分保证了标识码的稳定性与抗欺骗性，为应用提供了稳定、唯一与抗欺骗的可信终端识别能力。

3. har和hsp

    鸿蒙lib库分为har和hsp，har包类似正常的lib库，但是如果存在多终端发布可能会重复引用导致包体变大；hsp包为项目内可以共享的lib库，可以提高代码、资源的可重用性和可维护性。

    实践过程中发现对外提供lib库时如使用hsp须包名，版本与宿主App保持一致，否则会出现安装失败问题。通过实践总结如下：

（1）对外提供sdk要使用har包；

（2）项目内部共享的基础库使用hsp包。

4. sdk依赖

    复杂的App项目基本上都会采用分模块管理，不可避免会出现多个模块依赖同一基础库的现象。基础库升级时所有依赖此基础库的模块均需升级，此时非常容易出现个别模块遗漏升级而导致库冲突。

建议统一管理维护sdk依赖，具体操作如下：

（1）将版本信息统一放置在parameter-file.json；

（2）增加冲突解决配置，.ohpmrc中配置resolve_conflict=true，配置后系统会自动使用最新lib库版本。

五、未来展望

    展望未来，我们将深度依托鸿蒙系统的“一次开发、多端部署”核心优势，进一步拓展金融服务边界，构建跨设备、无缝连接的“1+8+N”全场景智慧金融服务生态，将服务延伸至PC、电视、智能手表、智能音箱、平板、穿戴设备、车机、耳机以及更多泛IoT设备（即“N”类设备），实现金融服务在各类智能终端上的全面覆盖与深度融合。银行网点服务侧，我们将结合鸿蒙实况窗技术，实现客户在网点排队取号时，可通过手机或智能手表实时查看排队进度，甚至提前线上完成部分业务预办理，提升服务效率与用户体验。此外，通过对接鸿蒙的意图框架，智能识别用户的信用卡还款需求，自动推送还款提醒，减少逾期风险；同时，基于用户的地理位置等信息，精准推送本地化的金融产品与服务，实现金融服务的个性化与精准化。

作者：js每日一题

今天这篇文章，我将分享我使用收藏的 11 个 JavaScript 脚本，它们可以帮助您自动化日常工作的各个方面。

1. 自动文件备份

担心丢失重要文件？此脚本将文件从一个目录复制到备份文件夹，确保您始终保存最新版本。

const fs = require('fs');const path = require('path');

function backupFiles(sourceFolder, backupFolder) {  fs.readdir(sourceFolder, (err, files) => {    if (err) throw err;    files.forEach((file) => {      const sourcePath = path.join(sourceFolder, file);      const backupPath = path.join(backupFolder, file);      fs.copyFile(sourcePath, backupPath, (err) => {        if (err) throw err;        console.log(`Backed up ${file}`);      });    });  });}const source = '/path/to/important/files';const backup = '/path/to/backup/folder';backupFiles(source, backup);

提示：将其作为 cron 作业运行

2. 发送预定电子邮件

需要稍后发送电子邮件但又担心忘记？此脚本允许您使用 Node.js 安排电子邮件。

const nodemailer = require('nodemailer');

function sendScheduledEmail(toEmail, subject, body, sendTime) {  const delay = sendTime - Date.now();  setTimeout(() => {    let transporter = nodemailer.createTransport({      service: 'gmail',      auth: {        user: 'your_email@gmail.com',        pass: 'your_password', // Consider using environment variables for security      },    });    let mailOptions = {      from: 'your_email@gmail.com',      to: toEmail,      subject: subject,      text: body,    };    transporter.sendMail(mailOptions, function (error, info) {      if (error) {        console.log(error);      } else {        console.log('Email sent: ' + info.response);      }    });  }, delay);}// Schedule email for 10 seconds from nowconst futureTime = Date.now() + 10000;sendScheduledEmail('recipient@example.com', 'Hello!', 'This is a scheduled email.', futureTime);

注意：传递您自己的凭据

3. 监控目录的更改

是否曾经想跟踪文件的历史记录。这可以帮助您实时跟踪它。

const fs = require('fs');

function monitorFolder(pathToWatch) {  fs.watch(pathToWatch, (eventType, filename) => {    if (filename) {      console.log(`${eventType} on file: ${filename}`);    } else {      console.log('filename not provided');    }  });}monitorFolder('/path/to/watch');

用例：非常适合关注共享文件夹或监控开发目录中的变化。

4. 将图像转换为 PDF

需要将多幅图像编译成一个 PDF？此脚本使用 pdfkit 库即可完成此操作。

const fs = require('fs');const PDFDocument = require('pdfkit');

function imagesToPDF(imageFolder, outputPDF) {  const doc = new PDFDocument();  const writeStream = fs.createWriteStream(outputPDF);  doc.pipe(writeStream);  fs.readdir(imageFolder, (err, files) => {    if (err) throw err;    files      .filter((file) => /.(jpg|jpeg|png)$/i.test(file))      .forEach((file, index) => {        const imagePath = `${imageFolder}/${file}`;        if (index !== 0) doc.addPage();        doc.image(imagePath, {          fit: [500, 700],          align: 'center',          valign: 'center',        });      });    doc.end();    writeStream.on('finish', () => {      console.log(`PDF created: ${outputPDF}`);    });  });}imagesToPDF('/path/to/images', 'output.pdf');

提示：非常适合编辑扫描文档或创建相册。

5. 桌面通知提醒

再也不会错过任何约会。此脚本会在指定时间向您发送桌面通知。

const notifier = require('node-notifier');

function desktopNotifier(title, message, notificationTime) {  const delay = notificationTime - Date.now();  setTimeout(() => {    notifier.notify({      title: title,      message: message,      sound: true, // Only Notification Center or Windows Toasters    });    console.log('Notification sent!');  }, delay);}// Notify after 15 secondsconst futureTime = Date.now() + 15000;desktopNotifier('Meeting Reminder', 'Team meeting at 3 PM.', futureTime);

注意：您需要先安装此包：npm install node-notifier。

6. 自动清理旧文件

此脚本会删除超过 n 天的文件。

const fs = require('fs');const path = require('path');

function cleanOldFiles(folder, days) {  const now = Date.now();  const cutoff = now - days * 24 * 60 * 60 * 1000;  fs.readdir(folder, (err, files) => {    if (err) throw err;    files.forEach((file) => {      const filePath = path.join(folder, file);      fs.stat(filePath, (err, stat) => {        if (err) throw err;        if (stat.mtime.getTime() < cutoff) {          fs.unlink(filePath, (err) => {            if (err) throw err;            console.log(`Deleted ${file}`);          });        }      });    });  });}cleanOldFiles('/path/to/old/files', 30);

警告：请务必仔细检查文件夹路径，以避免删除重要文件。

7. 在语言之间翻译文本文件

需要快速翻译文本文件？此脚本使用 API 在语言之间翻译文件。

const fs = require('fs');const axios = require('axios');

async function translateText(text, targetLanguage) {  const response = await axios.post('https://libretranslate.de/translate', {    q: text,    source: 'en',    target: targetLanguage,    format: 'text',  });  return response.data.translatedText;}(async () => {  const originalText = fs.readFileSync('original.txt', 'utf8');  const translatedText = await translateText(originalText, 'es');  fs.writeFileSync('translated.txt', translatedText);  console.log('Translation completed.');})();

注意：这使用了 LibreTranslate API，对于小型项目是免费的。

8. 将多个 PDF 合并为一个

轻松将多个 PDF 文档合并为一个文件。

const fs = require('fs');const PDFMerger = require('pdf-merger-js');

async function mergePDFs(pdfFolder, outputPDF) {  const merger = new PDFMerger();  const files = fs.readdirSync(pdfFolder).filter((file) => file.endsWith('.pdf'));  for (const file of files) {    await merger.add(path.join(pdfFolder, file));  }  await merger.save(outputPDF);  console.log(`Merged PDFs int0 ${outputPDF}`);}mergePDFs('/path/to/pdfs', 'merged_document.pdf');

应用程序：用于将报告、发票或任何您想要的 PDF 合并到一个地方。

9. 批量重命名文件

需要重命名一批文件吗？此脚本根据模式重命名文件。

const fs = require('fs');const path = require('path');

function batchRename(folder, prefix) {  fs.readdir(folder, (err, files) => {    if (err) throw err;    files.forEach((file, index) => {      const ext = path.extname(file);      const oldPath = path.join(folder, file);      const newPath = path.join(folder, `${prefix}_${String(index).padStart(3, '0')}${ext}`);      fs.rename(oldPath, newPath, (err) => {        if (err) throw err;        console.log(`Renamed ${file} to ${path.basename(newPath)}`);      });    });  });}batchRename('/path/to/files', 'image');

提示：padStart(3, '0') 函数用零填充数字（例如，001,002），这有助于排序。

10. 抓取天气数据

通过从天气 API 抓取数据来了解最新天气情况。

const axios = require('axios');

async function getWeather(city) {  const apiKey = 'your_openweathermap_api_key';  const response = await axios.get(    `https://api.openweathermap.org/data/2.5/weather?q=${city}&appid=${apiKey}&units=metric`  );  const data = response.data;  console.log(`Current weather in ${city}: ${data.weather[0].description}, ${data.main.temp}°C`);}getWeather('New York');

注意：您需要在 OpenWeatherMap 注册一个免费的 API 密钥。

11. 生成随机引语

此脚本获取并显示随机引语。

const axios = require('axios');

async function getRandomQuote() {  const response = await axios.get('https://api.quotable.io/random');  const data = response.data;  console.log(`"${data.content}" \n- ${data.author}`);}getRandomQuote();

最后，感谢您一直阅读到最后！希望今天内容能够帮助到你，如果你喜欢此内容的话，也请分享给你的小伙伴，也许能够帮助到他们。

今天咱们聊个啥呢？先设想一个场景：你辛辛苦苦开发了一个前端应用，后端 API 也写得杠杠的。用户通过你的前端界面提交一个订单，比如说买1件商品。请求发出去，一切正常。但如果这时候，有个“不开眼”的黑客老哥，在你的请求发出后、到达服务器前，悄咪咪地把“1件”改成了“100件”，或者把你用户的优惠券给薅走了，那服务器收到的就是个被篡改过的“假”请求。更狠一点，如果他拿到了你某个用户的合法请求，然后疯狂重放这个请求，那服务器不就炸了？

是不是想想都后怕？别慌，今天咱就来聊聊怎么给咱们的API请求加一把“锁”，让这种“中间人攻击”和“重放攻击”无处遁形。这把锁，就是大名鼎鼎的 HMAC-SHA256 请求签名。学会了它，你就能给你的应用穿上“防弹衣”！

一、光有 HTTPS 还不够？为啥还要请求签名？

可能有机灵的小伙伴会问：“老张，咱不都有 HTTPS 了吗？数据都加密了，还怕啥？”

问得好！HTTPS 确实牛，它能保证你的数据在传输过程中不被窃听和篡改，就像给数据修了条“加密隧道”。但它主要解决的是传输层的安全。可如果：

请求签名，则是在应用层做的一道防线。它能确保：

• 消息的完整性：数据没被篡改过。


• 消息的身份验证：确认消息确实是你授权的客户端发来的。


• 防止重放攻击：结合时间戳或 Nonce，让每个请求都具有唯一性。

它和 HTTPS 是好搭档，一个负责“隧道安全”，一个负责“货物安检”，双保险！

二、主角登场：HMAC-SHA256 是个啥？

HMAC-SHA256，听起来挺唬人，拆开看其实很简单：

• HMAC：Hash-based Message Authentication Code，翻译过来就是“基于哈希的消息认证码”。它是一种使用密钥（secret key）来生成消息摘要（MAC）的方法。


• SHA256：Secure Hash Algorithm 256-bit，一种安全的哈希算法，能把任意长度的数据转换成一个固定长度（256位，通常表示为64个十六进制字符）的唯一字符串。相同的输入永远得到相同的输出，输入有任何微小变化，输出都会面目全非。

所以，HMAC-SHA256 就是用一个共享密钥 (Secret Key)，通过 SHA256 算法，给你的请求数据生成一个独一无二的“签名”。

三、签名的艺术：请求是怎么被“签”上和“验”货的？

整个流程其实不复杂，咱们用个图来说明一下：

sequenceDiagram

    participant C as 前端 (Client)

    participant S as 后端 (Server)



    C->>C: 1. 准备请求参数 (如 method, path, query, body)

    C->>C: 2. 加入时间戳 (timestamp) 和/或 随机数 (nonce)

    C->>C: 3. 将参数按约定规则排序、拼接成一个字符串 (stringToSign)

    C->>C: 4. 使用共享密钥 (Secret Key) 对 stringToSign 进行 HMAC-SHA256 运算，生成签名 (signature)

    C->>S: 5. 将原始请求参数 + timestamp + nonce + signature 一起发送给后端



    S->>S: 6. 接收到所有数据

    S->>S: 7. 校验 timestamp/nonce (检查是否过期或已使用，防重放)

    S->>S: 8. 从接收到的数据中，按与客户端相同的规则，提取参数、排序、拼接成 stringToSign'

    S->>S: 9. 使用自己保存的、与客户端相同的 Secret Key，对 stringToSign' 进行 HMAC-SHA256 运算，生成 signature'

    S->>S: 10. 比对客户端传来的 signature 和自己生成的 signature'

    alt 签名一致

        S->>S: 11. 验证通过，处理业务逻辑

        S-->>C: 响应结果

    else 签名不一致

        S->>S: 11. 验证失败，拒绝请求

        S-->>C: 错误信息 (如 401 Unauthorized)

    end

简单来说，就是：

四、Talk is Cheap, Show Me The Code!

光说不练假把式，咱们来点实在的。

前端签名 (JavaScript - 通常使用 crypto-js 库)

// 假设你已经安装了 crypto-js: npm install crypto-js

import CryptoJS from 'crypto-js';



function generateSignature(params, secretKey) {

  // 1. 准备待签名数据

  const method = 'GET'; // 请求方法

  const path = '/api/user/profile'; // 请求路径

  const timestamp = Math.floor(Date.now() / 1000).toString(); // 时间戳 (秒)

  const nonce = CryptoJS.lib.WordArray.random(16).toString(); // 随机数，可选



  // 2. 构造待签名字符串 (规则很重要，前后端要一致！)

  // 通常会对参数名按字典序排序

  const sortedKeys = Object.keys(params).sort();

  const queryString = sortedKeys.map(key => `${key}=${params[key]}`).join('&');



  const stringToSign = `${method}\n${path}\n${queryString}\n${timestamp}\n${nonce}`;

  console.log("String to Sign:", stringToSign); // 调试用



  // 3. 使用 HMAC-SHA256 生成签名

  const signature = CryptoJS.HmacSHA256(stringToSign, secretKey).toString(CryptoJS.enc.Hex);

  console.log("Generated Signature:", signature); // 调试用



  return {

    signature,

    timestamp,

    nonce

  };

}



// --- 使用示例 ---

const mySecretKey = "your-super-secret-key-dont-put-in-frontend-directly!"; // 强调：密钥不能硬编码在前端！

const requestParams = {

  userId: '123',

  role: 'user'

};



const { signature, timestamp, nonce } = generateSignature(requestParams, mySecretKey);



// 实际发送请求时，把 signature, timestamp, nonce 放在请求头或请求体里

// 例如：

// fetch(`${path}?${queryString}`, {

//   method: method,

//   headers: {

//     'X-Signature': signature,

//     'X-Timestamp': timestamp,

//     'X-Nonce': nonce,

//     'Content-Type': 'application/json'

//   },

//   // body: JSON.stringify(requestBody) // 如果是POST/PUT等

// })

// .then(...)

划重点！ 上面代码里的 mySecretKey 绝对不能像这样直接写在前端代码里！这只是个演示。真正的 Secret Key 需要通过安全的方式分发和存储，比如在构建时注入，或者通过更安全的认证流程动态获取（但这又引入了新的复杂性，通常 Secret Key 是后端持有，客户端动态获取一个有时效性的 token）。对于纯前端应用，更常见的做法是后端生成签名所需参数，或者整个流程由 BFF (Backend For Frontend) 层处理。如果你的应用是 App，可以把 Secret Key 存储在原生代码中，相对安全一些。

后端验签 (Node.js - 使用内置 crypto 模块)

const crypto = require('crypto');



function verifySignature(requestData, clientSignature, clientTimestamp, clientNonce, secretKey) {

  // 0. 校验时间戳 (例如，请求必须在5分钟内到达)

  const serverTimestamp = Math.floor(Date.now() / 1000);

  if (Math.abs(serverTimestamp - parseInt(clientTimestamp, 10)) > 300) { // 5分钟窗口

    console.error("Timestamp validation failed");

    return false;

  }



  // (可选) 校验 Nonce 防止重放，需要存储已用过的 Nonce，可以用 Redis 等

  // if (isNonceUsed(clientNonce)) {

  //   console.error("Nonce replay detected");

  //   return false;

  // }

  // markNonceAsUsed(clientNonce, clientTimestamp); // 标记为已用，并设置过期时间



  // 1. 从请求中提取参与签名的参数

  const { method, path, queryParams } = requestData; // 假设已解析好



  // 2. 构造待签名字符串 (规则必须和客户端完全一致！)

  const sortedKeys = Object.keys(queryParams).sort();

  const queryString = sortedKeys.map(key => `${key}=${queryParams[key]}`).join('&');



  const stringToSign = `${method}\n${path}\n${queryString}\n${clientTimestamp}\n${clientNonce}`;

  console.log("Server String to Sign:", stringToSign);



  // 3. 使用 HMAC-SHA256 生成签名

  const expectedSignature = crypto.createHmac('sha256', secretKey)

                               .update(stringToSign)

                               .digest('hex');

  console.log("Server Expected Signature:", expectedSignature);

  console.log("Client Signature:", clientSignature);



  // 4. 比对签名 (使用 crypto.timingSafeEqual 防止时序攻击)

  if (clientSignature.length !== expectedSignature.length) {

    return false;

  }

  return crypto.timingSafeEqual(Buffer.from(clientSignature), Buffer.from(expectedSignature));

}



// --- Express 示例中间件 ---

// app.use((req, res, next) => {

//   const clientSignature = req.headers['x-signature'];

//   const clientTimestamp = req.headers['x-timestamp'];

//   const clientNonce = req.headers['x-nonce'];

//   // 实际项目中，secretKey 应该从环境变量或配置中读取

//   const API_SECRET_KEY = process.env.API_SECRET_KEY || "your-super-secret-key-dont-put-in-frontend-directly!";



//   // 构造 requestData 对象，包含 method, path, queryParams

//   // 注意：如果是 POST/PUT 请求，请求体 (body) 通常也需要参与签名

//   // 且 body 如果是 JSON，建议序列化后参与签名，而不是原始对象

//   const requestDataForSig = {

//     method: req.method.toUpperCase(),

//     path: req.path,

//     queryParams: req.query, // 对于GET；POST/PUT可能还需包含body

//     // bodyString: req.body ? JSON.stringify(req.body) : "" // 如果body参与签名

//   };



//   if (!verifySignature(requestDataForSig, clientSignature, clientTimestamp, clientNonce, API_SECRET_KEY)) {

//     return res.status(401).send('Invalid Signature');

//   }

//   next();

// });