> 今天在抖音上看到一个这样的题目，好像很多地方都见过，比较基础，提供一些可能高效的解决思路，在算法选择最优解的基础上，继续优化代码细节，让效率快2-3倍，并进行扩展应用。





## 题目

现有两个有序数组，例如

```js
const a = [1, 3, 5];
const b = [2, 4, 6];
```
需要实现一个函数，将这两个有序数组按元素大小进行合并吗，得到以下结果

```js
[1, 2, 3, 4, 5, 6];
```

## 解决思路

看着好像蛮简单的，思路可能也很多。在工作里面，如果不考虑效率，可能就这样做了。

```js
function mergeArr (a, b) {
    return [...a, ...b].sort((a, b) => a - b);
}
```

这样，不能说没得到解决，但是在面试里如果这样写，基本是等于没写。

### 方案

我建议是用双指针的形式来写。

**双指针遍历（时间复杂度 O(m+n)）**

- 使用两个指针分别遍历两个数组
- 每次选择较小的元素推入结果数组
- 仅需遍历 m + n - 1 次比较（m 和 n 分别为数组长度）

然后因为这两个数组可能长度不是对等的，会导致有数组存在剩余元素的情况。

**剩余元素处理（时间复杂度 O(k)）**

- 当任一数组遍历完成后，通过 slice 直接获取剩余元素
- 由于两个数组本身已排序，剩余元素可以直接拼接


### 代码

```js

function mergeSortedArrays(a, b) {
  const merged = [];
  let i = 0, j = 0;
  
  while (i < a.length && j < b.length) {
    a[i] <= b[j] ? merged.push(a[i++]) : merged.push(b[j++]);
  }
  
  return merged.concat(a.slice(i)).concat(b.slice(j));
}
```

在这个场景下，这种写法应该是性能最优的。

### 不同算法思路的对比


| 方法 | 时间复杂度 | 空间复杂度 | 适用场景 | 
| --- | --- | --- | --- |
| 双指针 | O(m+n) | O(m+n) | 已排序数组合并 |
| 快速排序 | O((m+n)log(m+n)) | O(m+n) | 未排序数组合并 |
| 插入排序 | O(mn) | O(1) | 小规模数组合并 |


### 进阶优化(内存预分配)

在之前算法的基础上，可以在很多更细节的角度来优化性能，毕竟在面试中，100分的人就是比99分的人更有机会。

```js
function mergeSortedArraysPlus(a, b) {
  const totalLength = a.length + b.length;
  const merged = new Array(totalLength);
  let i = 0, j = 0, k = 0;

  while (i < a.length && j < b.length) {
    merged[k++] = a[i] <= b[j] ? a[i++] : b[j++];
  }

  while (i < a.length) merged[k++] = a[i++];
  while (j < b.length) merged[k++] = b[j++];

  return merged;
}
```

**优化点：**

- 预先分配结果数组内存（减少动态扩容开销）
- 使用索引直接赋值（避免 push 方法和 contact 方法的调用开销）


通过实际的数据测试中，进阶优化的版本会比原版本快2-3倍。


![image.png](https://creatorblog.cn/static/img/85a489a765b7962aa1c5236afeb65678.image.webp)

几个小细节的优化就在算法思路不变的前提下，性能又强了2-3倍...fucking crazy

### 扩展应用

在面试中，往往面试官都喜欢在一个角度追着问。既然题目是合并两个有序数组，那如果是合并多个有序数组呢。

思维开阔一点，就能很快get到原理其实没变，可以借助现有`JS`方法一行代码实现。

```js
function mergeKSortedArrays(arrays) {
  return arrays.reduce(mergeSortedArraysPlus, []);
}
```

`mergeSortedArraysPlus`就是上面进阶优化版本的实现函数。

合并两个有序数组

> 上家公司中前端项目有用MQTT协议和硬件通信的场景，虽然很早就听说过MQTT协议，但是这是第一次在前端项目里基于MQTT协议做网络通信。当时没了解太多，工作中只做好了代码层面的工作，并没有深入了解MQTT协议的好处和适合的应用场景。




在前端项目中，应该99%的情况都会基于`HTTP`和`WebSocket`来进行网络通信，使用`MQTT`在前端里确实比较小众。

目前可能只会在物联网项目中，需要跟硬件通信的前提下，前端才会有`MQTT`协议的选项。

我搜罗了一些资料来了解这样做的好处。

## 轻量级 & 低带宽消耗

前端项目里，在绝大多数的情况下，业务场景都是去跟服务端通信，服务端理论上是可以无限扩展的。但是如果通信对象是一个设备参数固定的硬件，其实是不具备扩展能力的。

所以轻量级和低消耗很关键。

- ​**协议开销极小：** MQTT报文头仅2字节，远低于HTTP的冗长Header，适合硬件资源（CPU、内存）有限的设备。
- **节省流量：** 对网络带宽要求低，尤其适用于NB-IoT、LoRa等低功耗广域网络。

## 发布/订阅模型

`HTTP`协议是基于请求/响应的设计，每次请求都应该立即得到相应的响应，完整的【请求参数+响应结果】才算一次完整的通信。

`WebSocket`协议是基于长连接且全双工通信的设计，通信的双方在建立长连接后，可以由任何一方进行消息的发送。

`MQTT`协议在`WebSocket`的长连接 + 全双工通信的基础上，使用了发布/订阅的模式。

- **解耦通信双方：** 硬件只需向Topic发布消息，无需感知订阅者（如Web前端、其他设备），扩展性强。
- **一对多广播：** 单个消息可被多个订阅者接收，避免为每个客户端重复建立连接（如WebSocket需维护多个连接）。

`MQTT`协议在设计上有一个订阅中心的概念，硬件设备其实从角色上来说跟前端一样，也是`client`。

现在有一个前端A和一个前端B，都需要跟硬件C进行通信，接收硬件的统一消息。

如果是基于`MQTT`协议，硬件C只需要把要发布的消息发给指定的`Topic`，不需要跟接收者进行直接的交互。

前端A和前端B可以通过订阅指定`Topic`来接受硬件C发布的消息。

这样理论上硬件C的消息可以发布给任何数量的前端。

反过来也是同理，因为硬件和前端都属于`client`的角色

那如果这种场景用`WebSocket`协议来做呢，硬件C就需要分别跟前端A和前端B建立长连接，然后将消息分发出来。而`MQTT`协议中，硬件C只需要跟订阅中心建立关系，不需要管订阅中心分发给了多少`client`。

## QoS消息质量保障

在`MQTT`协议中，**QoS（服务质量）** 是确保消息在不同网络环境下可靠传输的核心机制。它分为三个等级，从"尽力而为"到"绝对可靠"，适应多种场景需求。

**1. QoS 0：至多一次（At Most Once）**

- **工作原理：**
    - 发送方（发布者）将消息发出后，不等待确认，直接处理下一条消息。
    - 接收方（订阅者）可能收到消息，也可能因网络问题完全丢失。

- **适用场景：**
    - **不重要或高频数据：** 如温度传感器定期上报数据，偶尔丢失不影响整体趋势。
    - **低功耗设备：** 免确认交互，节省电量（如电池供电的传感器）。

- **示例：**
    - 智能灯泡每隔10秒上报一次亮度值，丢失一次数据不影响用户体验。

**2. QoS 1：至少一次（At Least Once）**

- **工作原理：**
    - 发送方发出消息后，**等待接收方的确认**。
    - 若未收到确认，发送方会**重复发送消息**，直到收到确认为止。
    - 接收方可能收到**重复消息**，需应用层去重（如通过消息ID）。

- **适用场景：**
    - **关键但允许重复的操作：** 远程开灯指令（多按一次开关影响不大）。
    - **网络波动环境：** 保消息必达，容忍少量重复。

- **示例：**
    - 用户通过APP发送"关闭空调"指令，即使网络延迟导致指令重复发送，空调只需执行一次关闭操作。

**3. QoS 2：恰好一次（Exactly Once）**

- **工作原理：**
    - **两阶段握手**，确保消息既不丢失也不重复：
        - **PUBLISH → PUBREC：** 发送方发出消息，接收方确认收到并暂存。
        - **PUBREL → PUBCOMP：** 发送方释放消息存储，接收方最终确认。

    - 协议层自动处理去重，应用层无需额外逻辑。

- **适用场景：**
    - **敏感数据或交易：** 如支付指令、告警信号（如烟雾探测器报警）。
    - **严格不允许重复的场景：** 如工业设备的状态控制命令。

- **示例：**
    - 银行系统发送"转账100元"指令，必须确保仅执行一次，避免重复扣款。

`MQTT`还有离线消息缓存，Broker可为断开连接的订阅者暂存消息（Clean Session=false），设备重连后补发。

**QoS选择指南**

| 维度 | QoS 0 | QoS1 | QoS2 |
| --- | --- | --- | --- |
| 可靠性 | 可能丢失 | 必达但可能重复 | 必达且不重复 |
| 网络开销 | 最低 | 中等 | 最高 |
| 延迟 | 最低 | 中等 |  最高 | 
| 适用设备 | 低功耗设备 | 常规设备 | 高可靠设备 | 


## 适应不稳定网络

- **心跳机制：** Keep Alive参数检测连接状态，自动重连减少断线影响。
- **遗嘱消息（LWT）：** 设备异常离线时，Broker自动发布预设消息，通知其他系统处理故障。

## 低功耗优化

- **短连接模式：** 设备发送数据后立即休眠，相比HTTP的长连接更省电。
- **避免轮询：** 订阅者实时接收消息，无需如HTTP轮询查询状态，减少无效请求。

## 对比其他协议劣势

- **HTTP：**
    - 请求/响应模式导致高延迟，不适合实时通信。
    - 无状态特性需频繁重建连接，Header冗余大。
    - 服务端无法主动推送数据，依赖轮询（浪费资源）。

- **WebSocket：**
    - 虽支持全双工，但无原生消息队列和QoS支持。
    - 需自行实现订阅逻辑和消息路由，增加开发复杂度。
    - 维护大量长连接对服务端资源消耗较高。

## 适用场景举例

- **传感器数据采集：** 大量设备高频上报温度、GPS等数据，MQTT轻量级特性显著降低负载。
- **远程设备控制：** 通过QoS 2确保关键指令（如阀门开关）可靠执行。
- **多端数据同步：** Web、App、硬件均订阅同一Topic，实现数据实时同步。

## 何时选择其他协议

- **需要强事务性：** 如支付场景，HTTP+RESTful API更合适。
- **简单单向通信：** 如上传文件，可使用HTTP PUT。
- **浏览器兼容性优先：** 若无跨平台SDK支持，WebSocket更易集成。

## 总结

`MQTT`在物联网场景下，以低开销、高可靠、易扩展等特性成为最优解，而其他协议更适用于侧重事务处理或简单通信的场景。

前端用MQTT协议通信的场景和好处

> 2025年，随着deepseek引起的AI大模型技术的深度革命，带来了很多机会和挑战，前端程序员作为互联网里一个普通但必不可少的岗位，在当前形势下，需要主动变革才能走的更稳。本文简单介绍三个方向，Web3前端、全栈、AI Agent。




最近要开始找工作了，调研了一下前端市场的变化。

在AI大模型成本大幅降低但质量依然顶级的前提下，一定会加速AI应用的全面落地，所以25年理论上，岗位会变多，因为不管是什么虾兵蟹将都想在AI应用里分一杯羹。会有新钱，会有新公司，会有新岗位。

但是如果依然按照传统的前端思维继续走，可能路会比较难了。经常了解前沿新闻的都知道，也都体验过，AI大模型带来的编程方面的巨大变革。不管你的前端技术多好还是多差，在AI技术的辅助下，水平差距都不会特别大，尤其是初级和中级之间。

这样就很有必要提升自己的竞争力了。

我最近了解了一下市场，基本上市场表明，现在前端需要朝三个方向分叉。

永远跟着市场走，因为你最终是要进入市场的，别人说什么都不重要，他不招你去他那里工作，他说了不算。


## Web3前端方向


![1740828550408.png](https://creatorblog.cn/static/img/2166bed812968b55a4c139015dc77c25.1740828550408.webp)

应该很多人都了解过Web3和区块链，我也玩`Crypto`有几年的，但是一直都没详细了解过相关的技术岗位。

最近研究了一下，发现主流岗位其实可以大致分为两个，Web3前端开发和智能合约开发。当然还有很多衍生的岗位，密码学和底层链开发之类的，岗位数量就比较少了，而且大部分都在国外。

Web3前端开发和智能合约开发是在国内有充分就业岗位的。

Web3目前的核心概念其实都是围绕智能合约的，你可以简单理解智能合约就是传统Web2的接口。

所以Web2的前端可能大部分工作都是和接口交互完成增删改查的，Web3的前端本质上来说，就是和智能合约交互来完成增删改查。

因为前端这个角色的职责是比较固定的，在任何时期，前端的职责都是在提供一个友好的UI界面的前提下，让用户完成他们的主观行为，这个主观行为本质上都离不开增删改查。

所以，区别只是前端交互的对象不同。

技术栈上也几乎没有转型的门槛。

我也是跟相关从业人士深度交流后知道，在国内想从Web2前端转Web3前端，其实在了解完一些基本概念之后，多学习两个库的使用`ethers.js`和`wagmi`。

- `ethers.js`是比较原生的和以太坊链交互的库。

- `wagmi`其实就是封装了很多更加友好的`Hooks`。

既然学习的对象是一些库，本质上就是学习API的过程，没什么难度。

## 全栈方向


![1740826913043.png](https://creatorblog.cn/static/img/0e3177fc811760de17f22714921e3977.1740826913043.webp)

我听很多程序员都说过，大公司里是没有全栈这种岗位的，需要你专精一个岗位的技术栈。这话说的没什么问题。

但是，全栈方向，并不是要你进了公司里，上午写前端，下午写后端，晚上自己和自己联调。

而是要了解后端的工作流，这样会极大提高你的工作效率和竞争力。当然，在必要的时候，如果后端人手不够，但是你当前又没有工作要做，给你分配一些后端部分的工作，你能够胜任是最好的。

我很赞同deepseek在招聘的JD里写的一句话：

"我们相信技术是互通的，对系统设计美感的追求最终也能收束统一"。

deepseek在招聘的岗位里就有很多全栈。人家只是想，在需要你写前端的时候，你能写，需要你写后端的时候，你也能够胜任，而不是上午前端下午后端，一个人同时当两个用。

在完全了解过后端的工作流之后，再作为一个前端进行和后端的联调时，就会顺畅特别多，因为我懂你...

作为一个前端出身的人，在进行全栈方面的努力时，还是优先选择`Nodejs`和`Python`这些语言比较容易。语言其实不是很重要，语言只是解决问题的工具，会很多语言并不厉害。

## AI Agent方向


![1740830065242.png](https://creatorblog.cn/static/img/503ec0b274db11e9ae480355855769db.1740830065242.webp)

AI Agent是一种以大型语言模型（LLM）为核心驱动的智能系统，具备自主感知、规划、记忆和工具使用能力，能够独立完成复杂任务的自动化执行。它不同于传统AI或单一的大模型，其核心在于通过"大脑（LLM）+ 四肢（工具）"的协作模式实现目标导向的主动决策。

简单点说，就是让AI拥有自己解决连续问题的能力，比如用户说"帮我策划一下周末的旅行"，AI Agent会自己完成查机票、订酒店、规划路线，甚至根据天气调整计划的情况。

现阶段很多AI Agent框架都是基于`JavaScript`和`Python`完成的。

和一些相关从业人士深度交流后知道，想转型这个方向的话，优先学习和理解`LangChain`框架，这个框架是支持`JavaScript`和`Python`，也是业内很主流的。



## 总结

从转型难度上来说，AI Agent > 全栈 > Web3。作为前端开发，在不同时期想办法提前自己的竞争力是关键。并不是说传统前端的技术路线没饭吃了，只是初级、中级、高级的差距在现阶段AI技术的辅助下在逐渐缩小，差距缩小就等于有更多的竞争对手，并且会有更低的待遇。

25年前端如何走的更稳

> 在2月17日，加密社区一则看似普通的信息吸引了广泛的关注，中国程序员胡乐知将500枚ETH（价值约140万美金）转入黑洞地址销毁（等于把钱彻底扔掉了，没有任何可能找回），并用中文留下一段令人震惊的留言。





![image.png](https://creatorblog.cn/static/img/0da7d148bb25b6b4352239c17dd76102.image.webp)


**"我是胡乐知，一名普通的程序员，创业者。自2022年10月以来，我意识到我从出生起就遭受着脑控组织的监控和摆布。而当我意识到脑控组织的存在时，他们也在加大对我的伤害，这两年我过得非常痛苦，现在已经到了身而为人的尊严彻底丧失的地步，我决定离开这个世界，也希望这个丑陋的世界早日毁灭。"**


![a259aa7b768c409b2c6548f14cc18f7.jpg](https://creatorblog.cn/static/img/b758a0819d797db36f24c37b6837e8ab.a259aa7b768c409b2c6548f14cc18f7.webp)

人们在链上追查了这个转入黑洞地址的钱包，发现这不是其第一次操作。

该钱包地址近期还向以下机构多次捐赠价值不菲的ETH：

- 向 WikiLeaks 地址捐赠 711 枚 ETH，约合 191 万美元。
- 向 Endaoment 地址捐赠 700 枚 ETH，约合 187万美元。
- 向以太坊基金会地址捐赠 133 枚 ETH，约合 35.4万美元。
- 最后一笔是上文提到的，将500 枚 ETH，约合 140 万美金，转入黑洞地址，永久销毁。

这前前后后捐掉和销毁了接近600万美金，4000多万人民币的资产。不禁让人们不得不重视这个人最后的留言，受到脑机武器长期控制...

这看似科幻版的描述，是真的吗。


这个人在后续的社区交流中透露了更多的信：

**"宽德投资的老总:冯鑫，徐御之使用脑机武器迫害了所有公司员工以及前员工，甚至他们自己本身也是受控者"**

**"随着脑机接口和读心技术不断发展，出现了一种新的犯罪模式:野生动物沦为数字机器的傀儡或完全的奴隶"**

**"目前出现了一种新的奴役受害者的犯罪模式，受害者的欲望感官被逐渐剥夺，直到最后完全成为数字机器的奴隶，如果有一天我成为了最后阶段的受害者，我会选择离开这个世界"**


![fa75369d82f2b2944a244c2bb76c884.jpg](https://creatorblog.cn/static/img/f577571816e622890ceb0d882a00c667.fa75369d82f2b2944a244c2bb76c884.webp)

emmm很难评价，科技已经进不到这种程度了吗。放在平时可能没人关注，因为天天都有那种看小说看着迷之后到处发疯的人，但是这个胡乐知可是花真金白银几千万人民币的代价传递的这些信息。


这个消息在国内国外持续发酵，2月18日宽德投资也发布了相关澄清公告：

![](https://creatorblog.cn/static/img/f93803b4bce6135af7efd3fc5ecf86dd.image.webp)

具体真相如何，不得而知。

程序员胡乐知受到脑机武器长期控制留下绝望留言

> 百度搜索宣布接入deepseek，微信宣布灰度测试接入deepseek的AI搜索，百度宣布将开源下个版本大模型，苹果将和阿里巴巴合作开发Apple Intelligence的国内版本。




## 冤大头百度

先说一下冤大头百度，回旋镖终究还是砸到了李总的头上。


![image.png](https://creatorblog.cn/static/img/62127ad998e35b274ca36133c392d2d4.image.webp)

百度作为国内最早一批推出国产大模型的厂商，文心一言一直很高调，在早期确实也占据了国产大模型前列的席位，当然也是几乎最早有收费版本的国产大模型。而且李彦宏李总曾多次讲到，大模型的开源策略是智商税永远比不过闭源模型。所以文心一言一直的策略都是紧紧闭源，也不跟其它大模型做过任何技术交流。

但是...


![image.png](https://creatorblog.cn/static/img/b91bd693f96edeae940d4fe9e05e059a.image.webp)

先是在2月13日，百度宣布所有终端的所有版本的文心一言将完全免费。


![image.png](https://creatorblog.cn/static/img/776fbfd37d2e78ead40695eec4e1f9f7.image.webp)

然后在2月14日，百度宣布将推出文心一言4.5版本，并且开源...哈哈哈

李总啪啪打脸。

最后在2月16日，百度宣布旗下文心智能体平台和百度搜索将全面接入deepseek。


![1739802083621.png](https://creatorblog.cn/static/img/c9f88265f0717e8a02338f1ec93eb769.1739802083621.webp)

没办法，deepseek带来的影响太大了，百度不这么做，要彻底GG了。


## 识时务者为俊杰的腾讯

还有一个大消息就是在上周末，腾讯旗下最大的国民级APP微信宣布灰度测试接入deepseek的AI搜索功能。虽然这个功能比较简单，但是带来的影响很大。


![image.png](https://creatorblog.cn/static/img/10c5ddfa872bc342eb22563a5a9e160f.image.webp)

微信是一个十亿日活的产品（冷知识苹果在国内的终端日活也就两亿），当微信通过"国运级"大模型deepseek的加持后，将带来前所未有的改变。这个改变首先影响了金融市场，就这一个举措，众多国外投行大幅提高腾讯股票的目标价。


![1739804265424.png](https://creatorblog.cn/static/img/658713a3a60d1d84ae9583f7620519f1.1739804265424.webp)

基于deepseek开源、能力强、且成本超低的前提下，微信后续的想象空间很大，AI搜索只是第一小步。


![1739804299677.png](https://creatorblog.cn/static/img/bcf72d4850691be6bd9a948d23170bf1.1739804299677.webp)


比如在收到消息后，AI根据平时的聊天习惯，给出一些智能推荐的回复。

比如一些平时消息量很大，阅读很耗费时间的人群，可以通过AI智能总结一些关键、紧急的信息。

比如朋友圈根据平时的点赞、评论、阅读停留时间等习惯，在一天下班后，没时间爬楼，但不想错过感兴趣的信息的时候，智能分析和总结今天朋友圈内所有优质的动态。

反正，腾讯很会审时度势，因为本身自己也有做混元大模型，能主动接入别人的deepseek到自己最核心的产品里（当然也可能不是主动的，可能是上面要求的...）。

## 稳扎稳打的阿里巴巴


![image.png](https://creatorblog.cn/static/img/66aba005c6a4c859f1d58bff4bac5e7d.image.webp)

在没有阿里巴巴和苹果合作的消息之前，阿里最近在金融市场上的估值本身就已经在大幅回升了，首先阿里巴巴自己的通义千问表现一直都很好，在春节后推出的最新版本里的表现，在机构评分上是超过deepseek的。当然它现在做不到既便宜又好用。deepseek的核心是足够便宜又足够好用。

然后大模型时代，阿里云本身就是最吃香的云服务提供商，谁家的模型好，自己都沾光。

现在苹果宣布和阿里巴巴合作开发国内Iphone16被阉割的Apple Intelligence，直接起飞。苹果对于国内的合作商要求很严格，前前后后试了好多家，库克都来了中国好几次。证明阿里巴巴整体的实力被足够认可。


![image.png](https://creatorblog.cn/static/img/0bb15682d7d18d08986b2bb3251d3beb.image.webp)


![image.png](https://creatorblog.cn/static/img/1fd5a55909c03e5676646c06e8a93499.image.webp)

最后，还有个消息，马云最近频频亮相，并且参加了在2月17日中央召开Top1主持的民企座谈会，而且坐到了第一排。金融市场现在对这个消息很关注，因为马云之前其实得罪了不少人，导致阿里巴巴股价被抛弃，现在开始被接纳了。

"BAT"最近都在搞AI大事件

欢迎来到我的博客，这里是我分享前端、web3、理财、互联网等方面的知识和心得的地方。我是一名热爱编程的前端程序员，我希望通过我的博客能够帮助更多的人学习和进步。在这里，你可以找到最新最实用的前端技术教程，了解最前沿的互联网动态和趋势，掌握最有效的理财方法和策略。我也会不定期地发布一些个人项目和作品，展示我的创意和能力。如果你对我的博客感兴趣，欢迎你留言、评论、收藏、关注，也可以通过邮箱或社交媒体与我联系，交流学习和合作。谢谢你的支持！