跨窗口通信的九重天劫：从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();

// });

五、细节是魔鬼：实施过程中的注意事项

六、HMAC-SHA256 vs. 其他方案？

HMAC-SHA256 更侧重于请求本身的完整性和来源认证，而 JWT 更侧重于用户身份的认证和授权。它们可以结合使用。

好啦，今天关于 HMAC-SHA256 请求签名的唠嗑就到这里。这玩意儿看起来步骤多，但一旦理解了原理，实现起来其实就是细心活儿。给你的 API 加上这把锁，晚上睡觉都能踏实点！

我是老码小张，一个喜欢研究技术原理，并且在实践中不断成长的技术人。希望今天的分享对你有帮助，咱们下回再聊！欢迎大家留言交流你的看法和经验哦！

背景

由于大模型通常是需要实时推理的，Web 应用调用大模型时，它的标准模式是浏览器提交数据，服务端完成推理，然后将结果以 JSON 数据格式通过标准的 HTTP 协议返回给前端。但是这么做有一个问题，主要是推理所花费的时间和问题复杂度、以及生成的 token 数量有关。在日常使用中会发现，只是简单问候一句，可能 Deepseek 推理所花费的时间很少，但是如果我们提出稍微复杂一点的要求，比如编写一本小说的章节目录，或者撰写一篇千字的作文，那么 AI 推理的时间会大大增加，这在具体应用中就带来一个显而易见的问题，那就是用户等待的时间很长。能够发现，我们在使用线上大模型服务时，不管是哪一家大模型，通常前端的响应速度并没有太慢，这正是因为它们默认采用了流式（streaming）传输，不必等到整个推理完成再将内容返回，而是可以将逐个 token 实时返回给前端，这样就大大减少了响应时间。

服务端推送

服务端推送，也称为消息推送或通知推送，是一种允许应用服务器主动将信息发送到客户端的能力，为客户端提供了实时的信息更新和通知，增强了用户体验。

服务端推送的背景与需求主要基于以下几个诉求：

实时通知：在很多情况下，用户期望实时接收到应用的通知，如新消息提醒、商品活动提醒等。节省资源：如果没有服务端推送，客户端需要通过轮询的方式来获取新信息，会造成客户端、服务端的资源损耗。通过服务端推送，客户端只需要在收到通知时做出响应，大大减少了资源的消耗。增强用户体验：通过服务端推送，应用可以针对特定用户或用户群发送有针对性的内容，如优惠活动、个性化推荐等。这有助于提高用户对应用的满意度和黏性。

常见推送场景有：微信消息通知栏、新闻推送、外卖状态 等等，我们自身的推送场景有：下载、连线请求、直播提醒 ......

解决方案

传统实时处理方案：

轮询：这是一种较为传统的方式，客户端会定时地向服务端发送请求，询问是否有新数据。服务端只需要检查数据状态，然后将结果返回给客户端。轮询的优点是实现简单，兼容性好；缺点是可能产生较大的延迟，且对服务端资源消耗较高。长轮询（Long Polling）：轮询的改进版。客户端向服务器发送请求，服务器收到请求后，如果有新的数据，立即返回给客户端；如果没有新数据，服务器会等待一定时间（比如30秒超时时间），在这段时间内，如果有新数据，就返回给客户端，否则返回空数据。客户端处理完服务器返回的响应后，再次发起新的请求，如此反复。长轮询相较于传统的轮询方式减少了请求次数，但仍然存在一定的延迟。

HTML5 标准引入的实时处理方案：

WebSocket：一种双向通信协议，同时支持服务端和客户端之间的实时交互。WebSocket 是基于 TCP 的长连接，和HTTP 协议相比，它能实现轻量级的、低延迟的数据传输，非常适合实时通信场景，主要用于交互性强的双向通信。SSE：Server-Sent Events 服务器推送事件，简称 SSE，是一种服务端实时主动向浏览器推送消息的技术。SSE 是 HTML5 中一个与通信相关的 API，主要由两部分组成：服务端与浏览器端的通信协议（ HTTP 协议）及浏览器端可供 JavaScript 使用的 EventSource 对象。

​ 从“服务端主动向浏览器实时推送消息”这一点来看，SSE 与 WebSockets API 有一些相似之处。但是，SSE 与 WebSockers API 的不同之处在于：

第三方推送：

常见的有操作系统提供相应的推送服务，如苹果的APNs（Apple Push Notification service）、谷歌的FCM（Firebase Cloud Messaging）等。同时，也有一些跨平台的推送服务，如个推、极光推送、友盟推送等，帮助开发者在不同平台上实现统一的推送功能。

这种推送方式在生活中十分常见，一般你打开手机就能看到各种信息推送，基本就是利用第三方推送来实现。

SSE

developer.mozilla.org/zh-CN/docs/…

SSE 服务端推送，它基于 HTTP 协议，易于实现和部署，特别适合那些需要服务器主动推送信息、客户端只需接收数据的场景：

EventSource

developer.mozilla.org/zh-CN/docs/…

服务器发送事件 API （SSE）包含在 eventSource 接口中。换句话说 eventsource 接口是 web 内容与服务器发送事件通信的接口。一个 eventsource 实例会对 HTTP 服务器开启一个持久化的连接，以text/event-stream格式发送事件，此连接会一直保持开启直到通过调用EventSource.close()关闭。

一旦连接开启，来自服务端传入的消息会以事件的形式分发至你代码中。如果接收消息中有一个 event 字段，触发的事件与 event 字段的值相同。如果不存在 event 字段，则将触发通用的 message 事件。

建立连接

EventSource 接受两个参数：URL 和 options。

​ URL 为 http 事件来源，一旦 EventSource 对象被创建后，浏览器立即开始对该 URL 地址发送过来的事件进行监听。

​ options 是一个可选的对象，包含 withCredentials 属性，表示是否发送凭证（cookie、HTTP认证信息等）到服务端，默认为 false。

const eventSource = new EventSource('http_api_url', { withCredentials: true })



// 关闭连接

eventSource.close()



// 可以使用addEventListener()方法监听

eventSource.addEventListener('open', function(event) {

  console.log('Connection opened')

})



eventSource.addEventListener('message', function(event) {

  console.log('Received message: ' + event.data);

})



// 监听自定义事件

eventSource.addEventListener('xxx', function(event) {

  console.log('Received message: ' + event.data);

})



eventSource.addEventListener('error', function(event) {

  console.log('Error occurred: ' + event.event);

})

// 也可以使用属性监听的方式

eventSource.onopen = function(event) {

  console.log('Connection opened')

}



eventSource.onmessage = function(event) {

  console.log('Received message: ' + event.data);

}



eventSource.onerror = function(event) {

  console.log('Error occurred: ' + event.event);

})

Stream API

developer.mozilla.org/zh-CN/docs/…

Stream API 允许 JavaScript 以编程方式访问从网络接收的数据流，并且允许开发人员根据需要处理它们。

流会将你想要从网络接受的资源分成一个个小的分块，然后按位处理它。

@microsoft/fetch-event-source

http://www.npmjs.com/package/@mi…

默认的浏览器eventSource API在以下方面存在一些限制：

无法传递请求体（request body），必须将执行请求所需的所有信息编码到 URL 中，而大多数浏览器对 URL 的长度限制为 2000 个字符。无法传递自定义请求头。只能进行 GET 请求，无法指定其他方法。如果连接中断，无法控制重试策略，浏览器会自动进行几次尝试然后停止。

@microsoft/fetch-event-source 的优势：

@microsoft/fetch-event-source提供了一个基于 Fetch API 的替代接口，完全兼容 Event Stream 格式。这使得我们能够以更加灵活的方式进行服务器发送事件的消费。以下是该库的一些主要优势：

支持任何请求方法、请求头和请求体，以及 Fetch API 提供的其他功能。甚至可以提供替代的 fetch() 实现，以应对默认浏览器实现无法满足需求的情况。

提供对响应对象的访问权限，允许在解析事件源之前进行自定义验证/处理。这在存在 API 网关（如 nginx）的情况下非常有用，如果网关返回错误，我们可能希望正确处理它。

对连接中断或发生错误时，提供完全控制的重试策略。

此外，该库还集成了浏览器的 Page Visibility API，使得在文档被隐藏时（例如用户最小化窗口），连接会关闭，当文档再次可见时会自动使用上次事件 ID 进行重试。这有助于减轻服务器负担，避免不必要的开放连接（但如果需要，可以选择禁用此行为）。

import { fetchEventSource } from "@microsoft/fetch-event-source";



const Assistant: React.FC<Iprops> = (props) => {

  const [abortController, setAbortController] = useState(new AbortController());

  

  const send = (question: any) => {

    setIsAnswering(true);

    setIsScrollAtBottom(true);

    setAskText("");



    // 创建“生成中...”的占位符消息

    const loadingMessage = { content: "生成中...", chatSenderType: 0, isLoading: true };



    // 更新 chatList，添加用户消息和占位符消息

    setChatList([...chatList, { content: question.text, chatSenderType: 1, problemType: question.problemType }, loadingMessage]);



    setLoading(true); // 开始加载



    fetchEventSource("https://demo.com/chat", {

      method: "post",

      body: JSON.stringify({ message: question.text, systemType, oa, problemType: question.problemType }),

      headers: {

        "Content-Type": "application/json"

      },

      signal: abortController.signal,

      async onopen(response) {

        // 可以在这里进行一些操作

      },

      onmessage(msg: { data: string }) {

        msg.data.length && setStopDisabled(false);

        // 接收到实际响应后，更新 chatList 中的占位符消息

        const newMessage = { ...JSON.parse(msg.data).data, chatSenderType: 0, isLoading: false };

        setChatList((prevChatList: any[]) => {

          // 替换最后一个消息（占位符）为实际消息

          const updatedChatList = [...prevChatList];

          updatedChatList[updatedChatList.length - 1] = newMessage;

          return updatedChatList;

        });



        setIsScrollAtBottom(true);

        setLoading(false); // 加载完成

      },

      onclose() {

        setIsStop(true);

        setLoading(false); // 加载完成

        setIsAnswering(false);

        // 停止生成禁用

        setStopDisabled(true);

      },

      onerror(err) {

        abortController.abort();

        setLoading(false); // 加载出错，停止加载

        throw err;

      }

    });

  };



  const stop = async () => {

    abortController.abort();

    const answer = chatList[chatList.length - 1];

    setAbortController(new AbortController());

    setIsAnswering(false);

    setLoading(false); // 停止加载

    stopAnswer({ message: answer.content, messageId: answer.messageId, problemType: answer.problemType, systemType, oa }).then((res: any) => {

      message.success("操作成功");

    });

  };



  return (

	<div>

    	<Chat

          chatList={chatList}

          setChatList={setChatList}

          askText={askText}

          setAskText={setAskText}

          send={send}

          stop={stop}

      />

    </div>

  )

};

AbortController

developer.mozilla.org/zh-CN/docs/…

在前端开发中，网络请求是不可或缺的一环。但在处理网络请求时，我们经常会遇到需要中途取消请求的情况。这时候，abortController可以帮助大家更好地掌控网络请求。

简介

AbortController是一个Web API，它提供了一个信号对象（AbortSignal），该对象可以用来取消与Fetch API相关的操作。当我们创建AbortController实例时，会自动生成一个与之关联的AbortSignal对象。我们可以将这个AbortSignal对象作为参数传递给fetch函数，从而实现对网络请求的取消控制。

使用方法

创建AbortController实例获取AbortSignal对象使用signal对象发起fetch请求取消fetch请求

const controller = new AbortController();

const signal = controller.signal;

// 当需要取消请求时，我们只需调用AbortController实例的abort方法：

fetch(url, { signal }).then(response => {

    // 处理响应数据

}).catch(error => {

    if (error.name === 'AbortError') {

        console.log('Fetch 请求已被取消');

    } else {

        // 处理其他错误

    }

});

// 当需要取消请求时，我们只需调用AbortController实例的abort方法：

controller.abort();

参考资料

blog.csdn.net/ldw20151080…

juejin.cn/post/722112…

http://www.npmjs.com/package/@mi…

segmentfault.com/a/119000004…

写在开头

其实这才是文章的标题：使用 TAPD MCP 实现任务的自动同步与快速管理😋

🤔 困境：在飞书和TAPD之间反复横跳是什么体验？

日常小编的需求任务拆分的工作流程大概是这样的：

看流程不算复杂，甚至优于不少企业的管理流程，似乎该"知足常乐"吧！🙊

当然!!!

但作为坚持极客精神的执行者（强行立人设 + 1🙈），重复劳动简直是效率大敌！

从 “技术人视角” 看，第二步的手动同步操作尤为繁琐 —— 虽说程序猿是世界上最"懒"的人，但本质是用智慧消灭无意义的重复。✨✨✨

任何机械性工作都该交给程序处理，腾出时间做更有价值的事（比如……moyu，误，专注工作）

✨ 优化思路：

😎 为什么我们爱飞书？

说实话，飞书真的很香！

其实，更多的是因为日常办公使用的就是飞书沟通。😋

二连追问，企微、钉钉：我们不配？😑

不过，小编这段时间使用下来，确实也感觉飞书的功能非常强大！

特别是📝多维表格功能，Top1!!!

前段时间网上爆火的使用"飞书多维表格+AI=小红书爆款内容"，那效果......啧啧啧，确实牛👍。

讲回来，在使用飞书文档管理我们的需求任务时，也确实是有好处的，起码我所知道的有：

• 📊 计划图表：直观展示每个人的任务分配情况，看着舒服~


• 📝 多维表格：各种公式随便玩，算工时简直不要太方便！


• 💬 即时沟通：有问题？评论一下自动戳同事!

😅 那为什么还要用TAPD？

emmm...这就要问问Leader了（小声bb）不过认真说，TAPD确实有它的优势：

• 🎯 需求管理更专业


• 📈 数据分析很强大


• 🔄 工作流程更规范

但是...这不代表我们要当复制粘贴工具人啊！(╯°□°）╯︵ ┻━┻

🎉 解救方案：TAPD MCP 来啦！

救星：传送门 🚀🚀🚀

🤖 什么是MCP？

简单来说，MCP就是让AI变得更聪明的一个协议！它可以：

（此处省略一万字。。。。）

🛠️ 开始配置我们的AI助手

支持MCP的AI客户端：

• Cursor（推荐）


• Windsurf


• Claude


• Cherry Studio（推荐）

第1️⃣步：Python环境配置

为什么要安装Python环境？🤔

Anthropic 为 MCP 提供了官方的 Python 和 TypeScript/Node.js SDK，方便开发者快速构建 MCP 服务或将 MCP 客户端集成到自己的应用中。（参考）

而 TAPD MCP 是使用 Python 开发的，所以要想使用这个MCP，需要先安装Python的环境，它是以uvx命令来运行的。

首先，python环境的安装教程网上非常多，这里就不细嗦了，可以上官网直接下载：传送门。

然后，我们来扩展认识一个新朋友：uv！

uv：一个超快的Python包管理器，比pip快到飞起！🚀 和前端的nvm差不多的东西，uv有一个坑点就是下载python版本的时候，需要🪜🪜🪜。

安装与使用uv的方式不是本章的主要内容，也不细嗦了，可以参考这篇文章：传送门。

本章要求的Python环境版本最低要 3.13+ 🔉🔉🔉 （为啥？当然是 TAPD MCP 要求的🙇）

小编的python版本配置：

其他一些工具对比：

总结：反正你本地需要安装好 Python 3.13 + 的环境，并且安装 uv ，能运行 uvx 命令即可。

第2️⃣步：获取TAPD凭证

每个API账号的权限是不一样的，也可以配置该账号的权限范围：

设置权限范围可以有效的防止AI助手误操作其他项目的情况，这很重要!!!⏰

第3️⃣步：在Cursor中配置MCP

具体配置如下：

{

  "mcpServers": {

    "mcp-server-tapd": {

      "command": "uvx",

      "args": [

        "mcp-server-tapd",

        "--api-user=你的API账号",

        "--api-password=你的API秘钥",

        "--api-base-url=https://api.tapd.cn",

        "--tapd-base-url=https://www.tapd.cn"

      ]

    }

  }

}

使用 Ctrl + S 保存后，回到 Cursor Settings 就能看到 TAPD MCP 的服务了，并且它应该是亮绿灯，这说明你配置成功了。🥳

如果配置后，没有亮绿灯，那么你要先可以检查一下TAPD的凭证有没有什么问题，Python的环境有没有 3.13+ 以上， 有没有安装uv，或者重启大法。

如果还不行，就要进行技术的排查了，可以点击 Help -> Toggle Developer Tools ，会调出 Cursor 的控制台，MCP配置不成功的话，控制台是会抛出错误的，拿到错误。

如果你是程序猿就自己分析错误的内容啦，你可以的。👌

如果你非程序猿，咱们就点击下图的第四步，把错误内容丢给AI，给它简单描述一下你的困境，最好选择agent模式，让它帮你修复，你只要不断给它同意、同意、同意即可。😋

🎮 实战：让AI帮我们做任务！

完成配置后，到这里咱们就能进入正式的使用环节了。咱们来开启Cursor的Agent模式，开始来实际使用TAPD MCP Server！

4.1 验证MCP服务是否正常工作

当然，你最好先在TAPD平台上创建一个空间，方便咱们初始验证。

在 TAPD 中，空间是团队协作的基础单元，用于隔离不同项目或团队的数据和权限，每个空间可以有多个项目。

需求是从用户角度描述的独立功能点，是产品研发的核心对象。

任务是在需求下拆分的具体工作项。

TAPD 的业务对象还包括迭代、缺陷、测试计划、测试用例等。

以下是小编创建的一个名叫"橙子果园项目"的空间，TAPD默认会帮我们初始化一些需求、特性啥的。还有，我们可以从地址栏获取到这个空间的唯一ID（workspace_id），通过这个ID能让AI更加精准的自动去操作，也能防止它操作到其他空间中去!!!⏰

其实本质是通过API接口去操作，接口要求传递workspace_id参数，这很正常吧。😋

有了空间ID，接下来咱们来让AI帮我们查询一下这个空间的"需求"列表，如下：

请你使用TAPD的MCP，帮我查询一下这个空间（58195679）中的需求列表。

它仅把"需求"的帮我们查出来了，是不是还不错？👻

初始目的达成，撒花撒花。🌸🌸🌸

4.2 自动化创建需求

能进行查找，基本上TAPD的MCP是能正常使用了，接下来，咱们让AI通过MCP帮我们创建一个需求。

首先，我们先上TAPD上看看创建一个需求要填些什么信息（其实不看也是可以的，它会给你提示）：

能填的东西很多，但是只有标题是必填的，咱们简单的填写一个标题和内容来创建一个需求就行，如下：

帮我创建一个需求，标题为"第一期计划1.0.1"，内容为“项目的基本搭建、架构规划、发布流程部署、缺陷计划、验收标准”。

结果：

是不是挺好，一句话，就让AI帮咱们吭哧吭哧的干活。😍

注意，我们使用的是自然语言，上面小编虽然提供了对话内容，但是也不一定要和我一样，能大致表达你的想法就行。

4.3 自动化创建任务🍊🍊🍊

上面，需求已经创建完了，接下来就要来解决咱们开头提到的实际困境了。

本来按照小编开始的设想，任务的信息应该是AI自动去飞书的平台那边获取的，但是......🙉。

• 飞书还没有提供文档这方面的相关MCP，社区倒是有，如：传送门。但是好像不能满足小编心中所想， 还有就是它非官方，不敢用呀，怕夹带私货。😩


• 飞书提供了开放的API平台，我们其实可以自己搭一个服务，让AI去访问这个服务拿数据就行，Em...就是要写代码，麻烦，再想想...。😑


• 思考了两坤年半后，小编觉得前面配置运行环境，配置MCP已经很麻烦，信息来源这部分应该需要简单化了😋，咱直截了当从飞书文档中复制过来就行啦。

日常工作中，小编需要在飞书多维表格里查找对应需求并创建开发任务，如下：

其中，需同步至 TAPD 的核心内容为上图红框部分。

同样，👀咱们可以先去TAPD上看看手动在需求下创建任务的情况是如何的，如下：

刚刚好，内容是正好对应上的。但要每次都得逐个创建任务，面对大量任务时，这操作流程就显得极为繁琐，实在令人困扰！😣

现在，我们可以借助 AI 进行自动化创建，只需将内容复制给它即可。

具体操作是，在多维表格中长按并拖动鼠标选中目标单元格，按下 Ctrl+C 完成复制。

再把内容丢给AI，告诉它帮我们创建任务，如下：

我希望你在"第一期计划1.0.1"的 需求 下创建三个子任务，任务内容如下：

页面样式切图与基本逻辑编写 周北北 3 2025/04/20 2025/04/20

页面接口联调与逻辑完善 周北北 4 2025/04/21 2025/04/21

缺陷修复 周北北 2 2025/04/22 2025/04/24

Em...最终结果是正向的，AI 确实成功帮小编创建好了任务，效果堪称完美💯-1。 不过，就给它打99分吧，因为这一过程并非一帆风顺，其中也遇到了不少难题😅

首先，AI 在区分需求和任务这两个概念时，存在一定困难❗

从用户角度来看，需求和任务的界定清晰明了，但对于程序而言，两者存在层级关系。

TAPD MCP 并未提供专门用于创建任务的独立 API，创建任务与创建需求共用同一个 API，仅通过 "workitem_type_id" 字段来加以区分。从程序设计层面讲，这种方式并无问题，然而却给 AI 的理解带来了挑战，这也恰恰凸显出不同模型推理能力的差异。

起初，AI 将小编的三个任务错误创建成了三个需求。于是，小编想着更换模型，让AI能更好理解我的想法，我从 GPT-4o 切换为 Claude3.7。

Claude3.7确实强大，当它遇到 “任务” 概念无法理解时，会先在 TAPD MCP 提供的全部功能中进行查找，在发现确实没有可直接创建任务的 API 后，又找到了创建需求的 API，并留意到其中有一个参数能够区分需求和任务。

随后，模型沿着这个思路，一步步进行自我引导，并向小编询问关键信息，最终成功完成了任务创建。✅

其次，AI无法很明确字段的定义❗

在上面的TAPD的截图中，可以三个任务已成功创建，但处理人这列还显示为空，这是为什么呢？

"预估工时"字段是正常的，它要在任务详情中查看，小编在 TAPD 平台调整许久，始终无法调出 "处理人" 列。。。

小编通过核查 AI 执行详情与 TAPD 文档发现：

原来是AI把字段搞错了。。。当复制内容涉及多个相近字段时，AI 可能因信息模糊而 "懵圈"，这也是其不确定性之一。因此，明确告知复制内容对应的字段至关重要。

我们再来尝试重新一个创建任务，并向 AI 详细说明 "处理人" 字段：

再帮我创建一个任务：

产品验收小缺陷修复 周北北 1 2025/04/25 2025/04/25

周北北 是处理人owner

从截图可见，这次效果堪称完美了💯💯💯！

经过上一轮 "调教"（其实是上下文连贯的作用😂），AI 已能清晰区分需求与任务的概念。同理，本次明确 "处理人" 字段后，AI 下次便能自动识别，让我们省心不少。

不过，AI 理解仍有小插曲 —— 小编本意不想设置负责人的，AI 却自动添加了，不过问题不大。整体来看，明确字段规则后，AI 协作效率显著提升啦！

TAPD MCP API 详情：

4.4 自动化更新任务状态

需求和任务创建完成后，接下来还有一个问题就是咱们需要时不时去更改任务的状态。虽然操作本身不复杂，只需点击几下，但小编仍觉得有些 "麻烦"—— 尤其是每次登录 TAPD 平台时，若遇到登录状态过期，还需用手机扫码重新登录，实在让人头疼。😕

还有，试想，如果每次完成任务（比如敲完代码）时，能在编辑器旁边顺手告诉 AI，让它帮忙更新任务状态，岂不是更高效？这样一来，写代码和更新任务状态都能在 Cursor 中完成，无需频繁切换平台。

还有还有不仅仅是任务，"缺陷"修复后若能自动更新状态，也能省去反复登录平台修改的麻烦。可见，自动化更新任务状态是个非常实用的操作呀。😀

那么，我们要如何做呢？

一个任务在TAPD平台上通常有以下三种状态：

我们尝试让 AI 将某个任务状态更改为 "进行中" 试试：

在 Claude 3.7 模型下，该操作算是一次成功的。🎉🎉🎉

但此前小编在 GPT-4o 模型中尝试时，初次操作就出现了错误❗

模型未理解 "进行中" 的状态定义，随便选择塞了一个状态进行更新，而 TAPD 平台居然没有对状态值进行有效性验证，直接就成功了😗。此外，GPT-4o 也没有像 Claude 3.7 那样先查询任务状态列表，直接 "盲操作"，推理能力略显不足呀！

不过，在小编向其提供了 TAPD 文档中的任务状态说明后：

它最终也是能正确完成状态的更新，也算可以啦。😋 如果说TAPD更出名一点，文档更友好一点，AI模型的前期训练积累了这方面的内容，其实都问题不大。

看到这里，不知道你有没有存在一些疑问❓是不是好似还有一个隐藏的痛点🙈：

每次对话时，都需要提供精确的任务名称作为匹配标准。虽然不算太麻烦，但是如果能更简洁一点，那肯定是更简洁好呀。在某些AI模型的视角下，如果存在名称相近的任务，就容易混淆，它容易"乱来"。但有一些模型比较聪明一些，相近或者模糊的任务名称也是可以的，AI会列举任务名称相近的任务，一个一个咨询你是否执行，也可能是 AI 先查询任务列表，再从结果中定位目标任务进行状态修改。这样一来，即使任务名称相近，也能通过列表精准匹配，这样操作效率与准确度反而更高了。

总的来说，尽管不同模型的表现有差异，但通过合理引导和补充规则，都问题不大，能满足实际需要了。👻

🚀 未来展望

• 🔄 通过飞书开放平台的 API，实现任务自动同步。


• ⏳设置定时任务，定期同步两个平台的数据。


• 🎯 自动帮我们写代码？


• 💪 可以专注于更有意义的工作

随着 AI 技术的发展，咱们可以期待更多智能化的协作方式。希望本章的分享能帮助大家从重复的工作中解放出来，毕竟生活不只有搬砖，还有诗和远方呢！(๑•̀ㅂ•́)و✧

至此，本篇文章就写完啦，撒花撒花。

最近遇到个需求，要求实现一个渐变色的边框，并且是虚线的，同时还要有动画。

有的朋友可能看到这里就要开骂了，估计要提刀找设计和产品怼回去了。

但其实我是可以理解的，因为这种花哨的边框想要用在一个类似于魔法框的地方，框住一个地方，然后交给 ai 处理。这样的交互设计可以很好的体现科技感，并且我也想尝试一下，就接了这个需求。

单看几个条件都好处理，css 已经支持了 border-image。

再不济用伪元素遮盖一下，clip-path镂空也可以

甚至我看到很多网站是直接放个视频就完了

但是我这次的需求最重要的是虚线，这就不好处理了。因为设置了边框为虚线后会忽略掉 border-image。

其实这个问题看起来很难，做起来也确实难。我搜到了张鑫旭大佬多年前的文章，就是专门讲这件事的

http://www.zhangxinxu.com/wordpress/2…

看完之后我受益匪浅，虽然我不能用他的方案（因为他的方案中，虚线是假的，样式会和浏览器有差异）

我尝试了很多方案，mask、clip-path、背景图等等，效果都不好。

绝望之际我想到了一个救星svg

div 做不到的事情，我 svg 来做。svg 可以设置 stroke，可以设置 fill，可以设置渐变色，渐变色还可以做动画。简直就是完美的符合需求

先写个空标签上去

<style>

.rect{

    width: 100px;

    height: 100px;

}

</style>

<div class='rect'>

    <svg xmlns="http://www.w3.org/2000/svg" version="1.1">

    </svg>

</div>

因为我需要 svg 尺寸跟随父容器变化，所以就不写 viewBox 了，直接设置宽高 100%。同时在里面画一个矩形，也是宽高 100%。

<svg xmlns="http://www.w3.org/2000/svg" version="1.1" width='100%' height='100%'>

    <rect width="100%" height="100%"></rect>

</svg>

现在长这样

接下来给 rect 设置填充和描边，边框宽度为 4px

<rect 

    fill="transparent" 

    stroke="red" 

    stroke-width="4" 

    width="100%" 

    height="100%"

></rect>

接下来我们给border 设置为渐变色，需要在 svg 中定义一个渐变，svg 定义渐变色还是很方便的，都是现成标签和属性直接就可以通过 id 取到。

<svg>

    ...

    <defs>

        <linearGradient id="gradient" x1="0%" y1="0%" x2="100%" y2="0%">

            <stop offset="0%" stop-color="lightcoral" />

            <stop offset="50%" stop-color="lightblue" />

            <stop offset="100%" stop-color="lightgreen" />

        </linearGradient>

     </defs>

</svg>

接下来给红色的 stroke 换成渐变色

<rect 

    fill="transparent" 

    stroke="url(#gradient)" 

    stroke-width="4" 

    width="100%" 

    height="100%"

></rect>

接下通过 stroke-dasharray 来设置虚线边框

mdn 上关于 dasharry的介绍在这里 developer.mozilla.org/zh-CN/docs/…

我给 rect 设置 dasharray 为 5,5

<rect 

    fill="transparent"

    stroke="url(#gradient)"

    stroke-dasharray="5,5" 

    stroke-width="4" 

    width="100%" 

    height="100%"

></rect>

这样渐变虚线边框就成了

接下来处理动画效果

动画分两种

这两种效果我都实现了

首先展示线动，背景色不动的情况

这种情况只要能想办法让虚线产生偏移就可以，于是我搜了一下，这不巧了吗，正好有个属性叫 stroke-dashoffset

于是就可以通过 css 动画来修改偏移量

<style>

.dashmove {

    animation: dashmove 1s linear infinite;

}



@keyframes dashmove {

    0% {

        stroke-dashoffset: 0;

    }

    100% {

        stroke-dashoffset: 10;

    }

}

</style>

<rect class="dashmove" .... ></rect>

大功告成

接下来处理第二种情况，线不动，背景动

这种情况就更简单了，因为 svg 本身就支持动画

我们只需要在渐变色中增加一个animateTransform标签

<linearGradient id="gradient" x1="0%" y1="0%" x2="100%" y2="0%">

    ...

    <animateTransform

        attributeName="gradientTransform"

        type="rotat

        from="0 0.5 0.5" 

        to="360 0.5 0.5" 

        dur="1s" 

        repeatCount="indefinite" 

    />

</linearGradient>

接下来看一下拖拽的效果，这个很重要，因为我们不希望随着容器比例变化，会让边框宽度也变化。

给容器元素加上这三个属性，这个 div 就变成了可拖拽缩放的

.rect{

    //    ...

    resize: both;

    position: relative;

    overflow: auto;

}

看下效果

完美 🎉🎉🎉

在这里查看完整在线 demo stackblitz.com/edit/stackb…

    对于做APP的UI，免不了会写大量的重复布局，重复UI页面。此时对于将重复的UI控件抽离出来封装为通用组件来进行优化很是重要。

    本文重点分析鸿蒙几种UI处理上，如何抽离通用方法来进行UI的复用。重点对比@Style，@Extend, AttributeModifier， @Builder和 struct 这五种方法的区别和使用场景。

Styles装饰器

    学过Android开发的小伙伴知道Android中有样式Style概念，我们定义好一个样式，那么就可以在各个组件中使用。从而保持每个组件有一样的属性。

    同理，鸿蒙中也可以使用样式。比如我们UI上的按钮具有相同的宽，高，背景色和边角距。那么我们就可以定义一个Style，每次定义按钮时候，只需要将Style赋给按钮就可以实现该属性，从而避免重复代码的书写。

• 代码说明

    如图，在当前页面内定义一个方法，使用装饰器Styles修饰，修饰后，方法内部就可以直接通过 .属性 的方式来定义属性了。方法定义完后，下方button里可以直接使用该方法。虽然我这里方法命名为commonButton，但是实际上所有基础控件都可以使用该方法使用里边的属性，比如下方的Text组件。

• Style特点

Extend装饰器

    对于Styles装饰器的第2点限制，鸿蒙推出了解决方案，那就是使用@Extend装饰器。

    Extend装饰器需要我们在使用时候指定定义哪个组件的属性，是专门抽离指定组件的。

• 代码说明

    Extend要求必须定义方法为在当前文件的全局定义，且也不能够export，同时定义时候需要指定是针对哪个控件。如图指定了控件Select，然后就可以指定Select的专有属性了。

• Extend特点

AttributeModifier

    对于上述两个装饰器都存在一个相同的限制，就是无法做到全局所有文件都可以公用。

    AttributeModifier的出现可以变相的解决这个问题。AttributeModifier本意是用于自定义控件中设置属性用的。但是我们在这里也可以通过这个机制，来实现全局所有文件中控件均可通用的属性。

• 代码说明

    该Modifier只能针对专用控件，比如我要抽离一个通用的TextInput，那么我可以如上图所定义。

    需要实现一个接口 AttributeModifier，接口泛型定义和我们想要给哪个控件使用有关，比如我们想给TextInput使用，那么泛型就是 TextInputAttribute，如果给Column使用，那么泛型就是ColumnAttribute，以此类推。

    在该接口的实现方法中，定义控件的属性。

• 布局中使用

• 自定义属性

    我们还可以自定义部分属性，只需要修改TextInputAttribute，例如我们想自定义字体大小。可以定义变量。

• 使用

• AttributeModifier特点

@Builder

    上述说的都是针对单独的控件，如果我们想抽离一个通用的布局呢？或者我们的控件就是固定的可以拿来到处使用。

    比如我有一个Text，各种属性固定，只是文案不同，那么我使用上述几种都比较麻烦，需要书写较多代码。那么这个时候就可以使用builder了。

• 代码

    我们可以在任意需要展示该Text的地方使用，直接调用该方法，对应位置就可以显示出内容了。原理相当于是将方法内的控件代码放到了对应的位置上。

• 使用

• @Builder特点

struct

    有时候，我们可能页面中存在大量如下UI：

    对于这种UI，我们完全可以抽离出为一个控件。然后我们页面需要展示的地方，直接调用该控件，设置标题，按钮文案等就可以简化了。

    我们可能想到使用builder来定义，但是builder只能写纯UI代码，这里还涉及到用户输入的内容，如何在点击按钮时候传过去。所以builder就无法使用了，这个时候就可以用struct封装了。

• 代码

@Component

export struct InputNumberItemWithButton {

  label: string = "标题"

  buttonClick: (v: number) => void = () => {

  }

  buttonLabel: string = "设置"

  inputPlaceholder: string = "我是提示语"

  inputId: string = this.label

  parentWidth: string = '100%'

  private value: number = 0



  build() {

    RelativeContainer() {

      Text(this.label)

        .attributeModifier(Modifier.textLabel())

        .id('label1')

        .alignRules({

          left: { anchor: '__container__', align: HorizontalAlign.Start },

          top: { anchor: '__container__', align: VerticalAlign.Top },

          bottom: { anchor: '__container__', align: VerticalAlign.Bottom }

        })

        .margin({ left: 2 })



      TextInput({ placeholder: this.inputPlaceholder })

        .onChange((value: string) => {

          this.value = Number.parseInt(value) ?? 0

        })

        .type(InputType.Number)

        .id(this.inputId)

        .height(30)

        .placeholderFont({ size: 10 })

        .fontSize(CommonStyle.INPUT_TEXT_SIZE)

        .borderRadius(4)

        .alignRules({

          right: { anchor: 'button1', align: HorizontalAlign.Start },

          left: { anchor: 'label1', align: HorizontalAlign.End },

          top: { anchor: '__container__', align: VerticalAlign.Top },

          bottom: { anchor: '__container__', align: VerticalAlign.Bottom }

        })

        .margin({ left: 6, right: 6 })



      Button(this.buttonLabel)

        .attributeModifier(SuBaoSmallButtonModifier.create())

        .onClick(() => {

          this.buttonClick(this.value)

        })

        .id('button1')

        .alignRules({

          right: { anchor: '__container__', align: HorizontalAlign.End },

          top: { anchor: '__container__', align: VerticalAlign.Top },

          bottom: { anchor: '__container__', align: VerticalAlign.Bottom }

        })

        .margin({ right: 2 })

    }

    .width(this.parentWidth)

    .height(40)

    .padding({

      left: 5,

      right: 5,

      top: 2,

      bottom: 2

    })

    .borderRadius(4)

  }

}

    该struct中通过维护一个变量value 来保存用户输入的数字，然后在用户点击按钮时候传给点击事件方法，交给调用者调用。

• 使用

    点击设置按钮，点击事件触发，a直接赋值。

• struct特点

对比各个使用场景

    实际编程中，一般都是混合相互配合使用，没必要单独硬使用哪一个。

来源：前端开发爱好者

在 JavaScript 的世界里，Promise 一直是处理异步操作的神器。

而现在，随着 ES2025 的发布，Promise 又迎来了一个超实用的新成员——Promise.try()！

这个新方法简直是对异步编程的一次 “革命” ，让我们来看看它是怎么让代码变得更简单、更优雅的！

什么是 Promise.try()？

简单来说，Promise.try() 是一个静态方法，它能把任何函数（同步的、异步的、返回值的、抛异常的）包装成一个 Promise。无论这个函数是同步还是异步，Promise.try() 都能轻松搞定，还能自动捕获同步异常，避免错误遗漏。

语法

Promise.try(func)

Promise.try(func, arg1)

Promise.try(func, arg1, arg2)

Promise.try(func, arg1, arg2, /* …, */ argN)

参数

• func：要包装的函数，可以是同步的，也可以是异步的。


• arg1、arg2、…、argN：传给 func 的参数。

返回值

一个 Promise，可能的状态有：

• 如果 func 同步返回一个值，Promise 就是已兑现的。


• 如果 func 同步抛出一个错误，Promise 就是已拒绝的。


• 如果 func 返回一个 Promise，那就按这个 Promise 的状态来。

为什么需要 Promise.try()？

在实际开发中，我们经常遇到一种情况：不知道或者不想区分函数是同步还是异步，但又想用 Promise 来处理它。

以前，我们可能会用 Promise.resolve().then(f)，但这会让同步函数变成异步执行，有点不太理想。

const f = () => console.log('now');

Promise.resolve().then(f);

console.log('next');

// next

// now

上面的代码中，函数 f 是同步的，但用 Promise 包装后，它变成了异步执行。

有没有一种方法，让同步函数同步执行，异步函数异步执行，并且让它们具有统一的 API 呢？

答案是可以的，并且 Promise.try() 就是这个方法！

怎么用 Promise.try()？

示例 1：处理同步函数

const syncFunction = () => {

  console.log('同步函数执行中');

  return '同步的结果';

};



Promise.try(syncFunction)

  .then(result => console.log(result)) // 输出：同步的结果

  .catch(error => console.error(error));

示例 2：处理异步函数

const asyncFunction = () => {

returnnewPromise(resolve => {

    setTimeout(() => {

      resolve('异步的结果');

    }, 1000);

  });

};



Promise.try(asyncFunction)

  .then(result =>console.log(result)) // 1秒后输出：异步的结果

  .catch(error =>console.error(error));

示例 3：处理可能抛出异常的函数

const errorFunction = () => {

  throw new Error('同步的错误');

};



Promise.try(errorFunction)

  .then(result => console.log(result))

  .catch(error => console.error(error.message)); // 输出：同步的错误

Promise.try() 的优势

实际应用场景

场景 1：统一处理 API 请求

function fetchData(url) {

  return Promise.try(() => fetch(url))

    .then(response => response.json())

    .catch(error => console.error('请求失败:', error));

}



fetchData('https://api.example.com/data')

  .then(data => console.log('数据:', data));

场景 2：混合同步和异步操作

const syncTask = () => '同步任务完成';

const asyncTask = () => new Promise(resolve => setTimeout(() => resolve('异步任务完成'), 1000));



Promise.try(syncTask)

  .then(result => console.log(result)) // 输出：同步任务完成

  .then(() => Promise.try(asyncTask))

  .then(result => console.log(result)) // 1秒后输出：异步任务完成

  .catch(error => console.error(error));

场景 3：处理数据库查询

function getUser(userId) {

  return Promise.try(() => database.users.get({ id: userId }))

    .then(user => user.name)

    .catch(error => console.error('数据库查询失败:', error));

}



getUser('123')

  .then(name => console.log('用户名称:', name));

场景 4：处理文件读取

function readFile(path) {

  return Promise.try(() => fs.readFileSync(path, 'utf8'))

    .catch(error => console.error('文件读取失败:', error));

}



readFile('example.txt')

  .then(content => console.log('文件内容:', content));

总结

Promise.try() 的引入让异步编程变得更加简单和优雅。

它统一了同步和异步函数的处理方式，简化了错误处理，让代码更易读易维护。

ES2025 的这个新特性，绝对值得你去尝试！快去试试吧，你的代码会变得更清晰、更强大！

先说优点

💡 先说优点叠个甲，毕竟库本身没有太大问题，往往都是使用的人有问题。

由于是基于设计稿进行屏幕适配的框架，在处理不同尺寸的屏幕时，都可以使用相同的 尺寸数值+单位 ，实现对设计稿等比例的适配，同时保真程度一般很高。

在有设计稿的情况下，只使用 Container + GestureDetector 都可以做到快速的开发，可谓是十分的无脑梭哈。

在：只考虑移动端、可以接受使用大屏幕手机看小屏幕 ui、不考虑大字体的模式、被强烈要求还原设计稿、急着开发。的情况下，还是挺好用的。

为什么劝退？

来到我劝退师最喜欢的一个问题，为什么劝退。如果做得不好，瞎搞乱搞，那就是我劝退的对象。

在亲身使用了两个项目并结合群里的各种疑惑，我遇到常见的有如下问题：

如何实现对平板甚至是桌面设备的适配？

由于基于设计稿尺寸，平板、桌面等设备的适配基本上是没法做的，要做也是费力不讨好的事。

千万不要想着说，我通过屏幕宽度断点来使用不同的设计稿，当用户拉动边框来修改页面的宽度时，体验感是很崩溃的。而且三套设计稿要写三遍不同的代码，就更不提了。（这里说三遍代码的原因是，计算 .w .h 的布局，数据会跟随设计稿变化）

如何适配大字体无障碍？

因为大字体缩放在满屏的 .w .h 下，也就是写死了尺寸的情况下，字体由于随系统字体放大，布局是绝对会溢出的。很多项目开发到最后上线才意识到自己有大字体无障碍的用户，甚至某些博客上，使用了一句：

MediaQuery.of(context).copyWith(textScaleFactor: 1.0),

来处理掉自己的用户，强制所有屏幕字体不可缩放。一时的勉强敷衍过去，最后只能等项目慢慢腐烂。

为什么在 1.w 的情况下会很糊？同样是 16.sp 为什么肉眼可见的不一样大？

库的原理很简单，提供了一堆的 api 相对于设计图的宽高去做等比例计算，所以必然存在一个问题，计算结果是浮点数。可是？浮点数有什么问题吗？

梳理一下原理：已知屏幕设计图宽度 sdw 、组件设计图宽度 dw ，根据屏幕实际宽度 sw ，去计算得出组件实际宽度 w。

w = sw / sdw * dw

可是设计图的屏幕宽度 sdw 作为分母时，并不能保证总是可以被表示为有限小数。举个例子：库的文档中给的示例是 const Size(360, 690), 的尺寸，如果我需要一个 100.w 会得到多少？在屏幕宽度为 420 的情况下，得到组件宽度应该为 116.6666... 的无限小数。

这会导致最终在栅格化时会面临消除小数点像素的锯齿问题。一旦有像素点的偏差，就会导致边缘模糊。

字体对尺寸大小更为敏感，一些非矢量的字体甚至只有几个档位的大小，当使用 14.5、15、15.5 的字体大小时，可能会得到一样的视觉大小，再加上 .sp 去计算一道，误差更是放大。

具体是否会发生在栅格化阶段，哪怕文章有误也无所谓，小数点像素在物理意义上就是不存在的，总是会面临锯齿平滑的处理，导致无法像素级还原 UI。

为什么部分屏幕下会溢出？

我们知道了有小数点问题，那么不得不说起计算机编程常见的一个不等式：

0.1 + 0.2 != 0.3

由于底层表示浮点数本身就有的精度问题，现在让 Flutter 去做这个加法，一样会溢出。考虑以下代码：

    Row(

      children: [

        SizedBox(width: 60.w),

        SizedBox(width: 100.w),

        SizedBox(width: 200.w),

      ],

    );

在一个总共宽度 360.w 的设计图上，可能出现了溢出，如果不去使用多个屏幕来调试，根本不会觉得异常，毕竟设计图是这样做的，我也是这样写的，怎么可能有错呢？

然而恰恰是库本身的小数问题，加上编程届常见的底层浮点数精度问题，导致边缘溢出一点点像素。

我使用了 screenutil 为什么和真实的单位 1px 1rem 1dp 的大小不同呢？

哪怕是 .sp 都是基于设计图等比例缩放的，使用 screenutil 就从来不存在真实大小，计算的结果都是基于设计稿的相对大小。就连 .w 和 .h 都没法保证比例相同，导致所有布局优先使用 .w 来编写代码的库，还想保证和真实尺寸相等？

为什么需要响应式 UI？

说个题外话：在面试淘菜菜的时候真的会有点崩不住，他们问如何做好不同屏幕的适配，我说首先这是 UI 出图的问题，如果 UI 出的图是响应式的，那没问题，照着写，闭着眼都能适配。

但是如果设计图不是响应式的，使用 flutter_screenutil 可以做到和设计图高保真等比还原，但是如果做多平台就需要 UI 根据屏幕断点出不同平台的设计图。

面试官立即就打断我说他们的 UI 只会出一份图。我当场就沉默了，然后呢？也不说话了？是因为只有移动端用户，或者说贵公司 UI 太菜了，还是说都太菜了。菜就给我往下学 ⏬

首先 UI 的响应式设计是 UI 的责任

抛开国情不谈，因为国内的 UI 能做到设计的同时，UI 还是响应式的，这样的 UI 设计师很少很少，他们能把主题规范好，约定好，已经是不得了的了。

但即使如此，响应式 UI 设计也还是应该归于 UI 设计中，在设计图中去根据不同的尺寸，拖动验证不同的布局效果是很容易的。在不同的尺寸下，应该怎么调整元素个数，应该如何去布局元素，只有 UI 使用响应式的写法去实现了，UI 和开发之间的无效交流才会减少。

响应式的 UI 可以避免精度问题

早在 19 年我就有幸翻阅了一本 iOS 的 UI 设计规范，当时有个特别的点特别印象深刻：尺寸大小应该为 2 的整数次幂，或者 4 的倍数。因为这样做，在显示和计算上会较为友好。

💡 这其实是有点历史原因的，之前的 UI 在栅格化上做得并不是很好，锯齿化严重也是常态，所以使用可以被 2 整除的尺寸，一方面使用起来只有几个档位，方便调整；另一方面这样的尺寸可以在像素的栅格化上把小数除尽。

举个例子，在屏幕中间显示一个 300 宽度的卡片，和边距 16 的卡片，哪一个更响应式，无疑是后者，前者由于需要计算 300 相对与设计稿屏幕的宽度，后者只需要准确的执行 16 的边距就好，中间的卡片宽度随屏幕的宽度自动变化。

同样的例子，带有 Expanded 布局的 Row 组件，相比直接给定每个子组件尺寸导致精度问题的布局，更能适配不同的屏幕。因为 Row 会先放置固定大小的组件，剩余空间由 Expanded 去计算好传给子组件，原理和 Web 开发中的 flex 布局一样。

响应式布局是通用的规范

如果有 Web 开发经验的，应该会知道 Web 的屏幕是最多变的，但是设计起来也可以很规范，常见的 bootstrap 框架就提到了断点这个观点，指出了当我们去做 UI 适配的时候，需要根据不同的屏幕大小去做适配。同时 flex 布局也是 Web 布局中常用的响应式布局手段。

在设计工具中，响应式 UI 也没有那么遥远，去下载一份 Material Design 的 demo，对里面的组件自由的拉伸缩放，再对比一下自己通过输入尺寸大小拼凑在一起的 UI，找找参数里面哪里有差异。

怎么做响应式 UI

这里直接放一个谷歌大会的演讲，我相信下面的总结其实都可以不用看了，毕竟本实验室没有什么可补充的，但是我们还是通过从外到内、从整体到局部的顺序来梳理一下如何去做一个响应式的 UI，从而彻底告别使用 flutter_screenutil。

http://www.youtube.com/watch?v=LeK…

SafeArea

一个简单的组件，可以确保内部的 UI 不会因为愚蠢的设备圆角、前置挖孔摄像头、折叠屏链接脚、全面屏边框等原因而被意外的裁剪，将重要的内容，显示在“安全区”中。

屏幕断点

让 UI 根据不同的尺寸的窗口变化而变化，首先就要使用 MediaQuery.sizeOf(context); 和 LayoutBuilder() 来实现对窗口的宽度的获取，然后通过不同的屏幕断点，去构建不同情况下的 UI。

其中 LayoutBuilder 还能获取当前约束下的宽度，以实现页面中子区域的布局，比如 Drawer 的宽度，对话框的宽度，导航的宽度。

这里举了个例子，使用媒体查询获得窗口宽度之后，展示不同的 Dialog：

写出如此优雅的断点代码只需要三步：

• 抽象：找到全屏对话框和普通对话框中共同的属性，并将功能页面提取出来。


• 测量：思考应该使用窗口级别的宽度（MediaQuery），还是某个约束下的宽度（LayoutBuilder）。


• 分支：编写如上图所示的带有断点逻辑的代码。

GridView

熟悉了移动端的 ListView 布局之后，切换到 GridView 布局并适配到平板、桌面端，是一件十分自然的事，只需要根据情况使用不同的 gridDelegate 属性来设置布局方式，就能简单的适配。

这里一般使用 SliverGridDelegateWithMaxCrossAxisExtent(maxCrossAxisExtent: ) 方法来适配，传入一个期望的最大宽度，使其在任何屏幕上看到的子组件都自然清晰，GridView 会根据宽度计算出合适的一行里合适的列数。

Flex 布局，但是 Flutter 版

前面说过了尽量不要去写固定尺寸的几个元素加起来等于屏幕宽度，没有那么巧合的事情。在 Row/Column 中，善用 Expanded 去展开子组件占用剩余空间，善用 Flexible 去缩紧子组件，最后善用 Spacer 去占用空白，结合 MainAxisAlignment 的属性，你会发现布局是那样的自然。

只有部分组件是固定尺寸的

例如 Icon 一般默认 24，AppBar 和 BottomNavigationBar 高度为 56，这些是写在 MD 设计中的固定尺寸，但是一般不去修改。图片或许是固定尺寸的，但是一般也使用 AspectRatio 来固定宽高比。

我曾经也说过一个普遍的公理，因为有太多初学者容易因为这个问题而出错了。

当你去动态计算宽高的时候，可能是布局思路有问题了。

在大多数情况下，你的布局都不应该计算宽高，交给响应式布局，让组件通过自己的能力去得出自己的位置、约束、尺寸。

举一个遇到过的群友问题，他使用了 stack 布局包裹了应用栏和一个滚动布局，由于SliverAppBar 拉伸后的高度会变化，他想去动态的计算下方的滚动布局的组件起始位置。这个问题就连描述出来都是不可思议的，然后他问我，我应该如何去获取这个 AppBar 的高度，因为我想计算下方组件的高度。（原问题记不清了，但是这样的需求是不成立的）