一、微信小程序架构设计
微信小程序的架构是一种结合了BS（浏览器-服务器）与CS（客户端-服务器）架构的混合模式，其核心架构可分为以下几个部分：
1. 双线程模型
微信小程序的逻辑层（AppService）与渲染层（WebView）分别运行在两个独立的线程中：
- 逻辑层：基于JSCore（iOS）或X5 JSCore（Android）运行JavaScript代码，负责数据处理、事件响应和API调用。
- 渲染层：通过WebView渲染WXML和WXSS，生成页面视图。
两者通过微信原生桥接（WeixinJsBridge）进行异步通信。逻辑层通过setData方法将数据传递给渲染层，触发UI更新，而用户交互事件则反向传递至逻辑层处理。这种设计避免了传统Web开发中脚本与UI线程的互斥问题，提升了安全性，但也带来了数据通信的延迟。
2. 组件系统
小程序基于Exparser框架构建了一套原生组件系统，其设计类似WebComponents的Shadow DOM模型，但独立于浏览器环境运行。组件分为两类：
- 普通组件：如
view、button，完全由Exparser渲染。 - 原生组件：如
map、video，由客户端原生渲染，层级更高且性能更优。
开发者还可通过自定义组件实现复用，其通信机制类似Vue的父子组件传值。
3. 运行与更新机制
- 启动模式：
-
- 冷启动：首次打开或销毁后重新加载。
- 热启动：后台切换至前台，无需重新初始化。
- 更新策略：新版本发布后，用户冷启动时会异步下载更新包，但需下次启动生效。开发者可通过
wx.getUpdateManager主动提示用户更新。
4. API与模块化
微信提供了丰富的API（如wx.request、wx.storage），本质是通过JSBridge调用原生能力。这些API覆盖网络、存储、设备信息等功能，并通过模块化设计（如require）支持代码复用。
二、微信小程序是否支持DOM操作？
1. 传统DOM的缺失
微信小程序不支持直接操作DOM，原因如下：
- 线程隔离：逻辑层与渲染层分离，逻辑层无法直接访问WebView中的DOM树。
- 安全性：避免JavaScript操纵DOM导致UI线程阻塞或数据不一致。
- 性能优化：原生组件和异步通信机制减少了渲染层与逻辑层的耦合，提升响应速度。
2. 替代方案：SelectQuery API
小程序提供了wx.createSelectorQuery接口，用于异步获取节点信息，例如：
const query = wx.createSelectorQuery();
query.select('#element').boundingClientRect();
query.exec(res => console.log(res[0].top));
与浏览器API的差异：
- 异步执行：查询操作需通过
exec触发，结果在回调中返回。 - 线程通信：查询请求通过原生桥接传递至渲染层，数据序列化后返回逻辑层。
3. 动态内容生成的限制
小程序无法像Web端通过JavaScript动态插入DOM节点。若需动态渲染内容，需依赖数据驱动的模板语法：
<view wx:for="{{list}}" wx:key="id">{{item.text}}</view>
数据变更需通过setData更新，触发视图层重新渲染。
4. 第三方解决方案：Kbone框架
为兼容Web端代码，微信推出了Kbone框架。它通过模拟浏览器环境（如实现DOM API），允许Vue、React等框架的代码直接运行在小程序中。但其代价是性能损耗，适用于节点数较少（<1000）的场景。
三、架构与DOM限制的实际影响
1. 开发模式差异
- 数据驱动：开发者需适应“数据变更→视图更新”的范式，而非直接操作DOM。
- 组件化思维：依赖小程序原生组件或自定义组件构建UI，而非自由操作DOM树。
2. 性能权衡
- 优势：双线程模型避免了脚本阻塞渲染，提升了复杂交互的流畅性。
- 劣势：频繁的
setData调用可能导致通信延迟，需优化数据传递量。
3. 兼容性挑战
Web端库（如jQuery）因依赖DOM/BOM无法直接使用，开发者需依赖小程序生态的替代方案（如wx.request替代axios）。
四、总结
小程序采用双线程模型（逻辑层JS线程 + 渲染层WebView），渲染层使用WXML虚拟节点树替代DOM：
- ❌ 无
document/window等浏览器API - ❌ 禁止直接操作节点（如
getElementById） - ✅ 数据驱动视图：通过
setData更新状态，框架自动 diff 渲染
