小程序 面试题

小程序的性能优化，不能只从“前端渲染”角度看。它的运行模型和 Web 不同，存在 逻辑层（JSCore）与视图层（WebView）分离 的架构特征，核心瓶颈往往出在：

• 跨线程通信成本
• setData 传输体积
• 渲染节点数量
• 包体与启动链路

优化必须围绕这些机制展开。

一、理解运行架构是前提

以 微信小程序 为例：

• 逻辑层：JS 执行环境
• 视图层：WebView 渲染
• 两层通过 JSON 序列化通信

每一次 setData：

1. 数据序列化
2. 线程间传输
3. 视图层 diff
4. 真实节点更新

所以小程序性能优化的第一原则是：

减少跨线程通信的数据量与次数。

二、控制 setData 的粒度与频率

1. 避免大对象全量更新

错误方式：

this.setData({
  form: newFormObject
})

如果 form 很大，每次都会整体传输。

正确方式：

this.setData({
  "form.username": value
})

使用路径更新，最小化数据传输。

2. 合并多次 setData

多次调用：

this.setData({ a: 1 })
this.setData({ b: 2 })

会触发多次通信。

应合并为：

this.setData({
  a: 1,
  b: 2
})

3. 避免高频 setData

例如滚动、拖拽、动画中频繁 setData，会造成卡顿。

解决方式：

• 使用节流 / 防抖
• 纯样式动画交给 CSS
• 使用 WXS 做视图层计算

三、列表渲染优化

列表是性能高发区。

1. 控制节点数量

一次性渲染几百个节点，必然卡顿。

解决方式：

• 分页加载
• 虚拟列表
• 懒加载

2. 正确使用 wx:key

如果 key 不稳定，会导致整列表重渲染。

必须使用唯一且稳定的 id，而不是 index。

3. 条件渲染用 hidden 替代频繁切换

wx:if 会销毁重建节点 hidden 只是控制显示

频繁切换时使用 hidden 性能更好。

四、包体与启动优化

小程序启动性能极其关键。

1. 分包加载

把非首屏页面放入分包，减小主包体积。

首包越小，冷启动越快。

2. 图片优化

• 使用压缩图片
• 使用 CDN
• 首屏图片懒加载

3. 代码体积控制

• 删除无用依赖
• 避免大型工具库
• Tree shaking

五、网络请求优化

小程序环境下网络延迟会显著影响体验。

优化方式：

• 请求合并
• 数据缓存
• 预加载关键接口
• 减少无意义轮询

六、渲染层优化技巧

1. 使用 WXS

WXS 在视图层执行，避免频繁 JS → View 通信。

适合：

• 简单计算
• 格式转换
• 列表中轻量逻辑

2. 使用 pureDataPattern

可以声明不参与视图层更新的数据字段，减少 setData 传输。

3. 减少复杂组件嵌套

组件层级过深，会增加渲染成本。

七、长列表与复杂页面的工程实践

如果是电商或内容类页面：

• 使用分块渲染（首屏优先）
• Skeleton 占位
• 滚动区域分段加载
• 图片懒加载

核心目标是：

让用户“尽快看到内容”，而不是等全部渲染完成。

八、本质理解

小程序优化的核心矛盾是：

逻辑层与视图层分离带来的通信成本。

因此优化方向始终围绕：

• 减少 setData 次数
• 减少传输数据量
• 控制节点数量
• 降低首屏体积

小程序的加载是一个多线程协作的过程，主要可以分为环境准备、代码下载、注入运行以及首屏渲染四个阶段。

1. 运行环境准备（准备阶段）

当用户点击小程序图标时，微信客户端会立即启动一个原生容器。

• 进程启动：微信会为小程序分配独立的进程或线程。
• 双线程环境初始化：微信会同时初始化两个运行环境，即逻辑层（AppService）和渲染层（WebView）。为了提速，微信通常会预先启动一个通用的空白 WebView（预加载机制），从而缩短环境搭建的时间。

2. 代码包下载与加载（资源阶段）

在环境准备的同时，微信会根据小程序的 AppID 去服务端请求最新的代码包。

• 增量更新与缓存：如果本地已有缓存，则直接校验版本；若无或版本过旧，则下载加密的代码包。
• 分包加载优化：如果开发者配置了分包，此时只会下载“主包”内容，从而减少首次下载的数据量，提升启动速度。

3. 代码注入与逻辑初始化（初始化阶段）

代码包下载完成后，微信会开始解析并执行代码。

• 逻辑层注入：执行 app.js 和各页面的 JS 逻辑。此时，小程序会触发 App.onLaunch 和 App.onShow 生命周期回调。
• 配置解析：解析 app.json 和页面配置，确定全局样式、路由关系及初始页面。

4. 渲染层视图构建与首屏渲染（渲染阶段）

这是用户肉眼感知页面出现的关键时刻。

• 视图层初始化：渲染层载入 WXML 转换后的模板和 WXSS 样式。
• 初始数据传输（First Paint）：逻辑层在实例化页面后，会将初始数据（Initial Data）通过微信底层提供的 evaluateJavascript 方式，跨线程传递给渲染层。
• 动态渲染：渲染层接收到数据后，结合模板生成最终的 DOM 树，并交由浏览器引擎进行绘制。

5. 交互就绪（Finish 阶段）

• 生命周期触发：页面初次渲染完成后，逻辑层会收到反馈，并触发页面的 onReady 回调。此时，逻辑层与渲染层已经建立了稳定的双向数据绑定，用户可以开始进行交互操作。

在微信生态中，小程序与 H5 网页虽然都使用前端技术栈（HTML/CSS/JS），但两者在性能表现和用户体验上存在显著差异。

从小程序底层的“双线程”架构到 H5 的传统 Web 运行机制，这种差异源于设计思路的根本不同。

1. 架构层面的区别：双线程 vs 单线程

这是导致性能差异的最根本原因。

• H5 网页（单线程机制）：运行在标准的 WebView 中，其 JS 逻辑执行和 UI 渲染都在同一个线程中。这意味着如果 JS 逻辑计算量过大，会直接阻塞页面的渲染或交互，造成明显的“卡顿”感。
• 微信小程序（双线程架构）：将运行环境拆分为渲染层（WebView）和逻辑层（AppService/JSCore）。
• 逻辑层：负责 JS 脚本运行，运行在独立的沙箱环境中，不涉及 DOM 操作。
• 渲染层：负责页面展现，使用 WebView 渲染。
• 优势：这种分离保证了即使逻辑层在处理复杂计算，渲染层依然能响应用户的滚动、触摸等交互。

2. 加载与启动性能：离线包 vs 实时加载

• H5 网页：本质上是远程 URL。用户每次打开 H5 都要经历 DNS 解析、TCP 连接、SSL 握手以及 HTML/JS/CSS 的下载和解析。即使有 HTTP 缓存，首屏加载受网络波动的影响依然非常大。
• 小程序：采用了**“离线包”机制**。当用户初次访问或有版本更新时，微信会下载整个代码包到本地。
• 预加载：微信会预先启动小程序的运行环境。
• 本地执行：打开页面时直接从本地磁盘读取静态资源，几乎抵消了网络加载的时间损耗。

3. 系统权限与原生组件的调用

• H5 网页：受限于浏览器安全沙箱，对系统权限（如蓝牙、传感器、复杂文件系统）的访问非常受限，且通常需要经过 JS-SDK 桥接，链路较长。
• 小程序：提供了大量原生组件（Native Components）。例如地图、视频播放、相机等。这些组件不是由 WebView 渲染，而是由微信客户端直接在页面上方叠加的原生视图。这种“混合渲染”模式让高负载组件的性能（如滑动流畅度、编解码效率）直接对标原生 App。

4. 渲染机制的约束与优化

• H5 网页：开发者可以随意操作 DOM。但在移动端，不规范的 DOM 操作极易引发全量重排（Reflow），导致性能崩溃。
• 小程序：严禁直接操作 DOM。所有 UI 变更必须通过 setData 触发。这种限制看似降低了灵活性，实则强制开发者遵循数据驱动的范式。微信底层会对 setData 的数据进行 Diff 和 Patch 优化，减少了不必要的渲染开销。

在小程序开发中，为了实现 界面自适应，官方提供了 rpx 单位，而最终在渲染时需要转换为实际像素（px），同时需要兼顾不同屏幕密度的设备（如 Retina 屏）。

1. rpx 的概念

• rpx（responsive pixel）是微信小程序特有的单位。

• 设计初衷：统一不同屏幕宽度的布局，使页面在各种设备上都能按比例显示。

• 转换规则：

  • 以 iPhone 6/7/8 宽度 750rpx 作为设计稿参考宽度
  • 小程序会根据设备屏幕宽度自动计算比例

示例：

• 设备屏幕宽度：375px
• 1rpx = 375 / 750 = 0.5px

2. rpx → px 转换公式

px = rpx * (屏幕宽度 / 750)

小程序官方 API

const systemInfo = wx.getSystemInfoSync()
const screenWidth = systemInfo.screenWidth  // 单位 px

function rpxToPx(rpx) {
  return rpx * screenWidth / 750
}

• 可以在 JS 中动态计算尺寸
• 结合 wx.createSelectorQuery() 获取元素实际宽度，实现动态布局

3. 适配高密度屏（Retina、2K、4K 屏）

• Retina 屏 的特征是物理像素比（devicePixelRatio）大于 1

• 微信小程序渲染引擎会自动处理 设备像素比，所以在大部分情况下：

  • 使用 rpx → px 转换后，页面显示正常
  • 不必手动乘 devicePixelRatio

• 如果涉及 Canvas 绘制或图片显示：

  • 需要手动乘上 devicePixelRatio，保证在高分屏上清晰

const dpr = wx.getSystemInfoSync().pixelRatio
const canvasWidth = rpxToPx(300) * dpr
const canvasHeight = rpxToPx(200) * dpr

• 这样绘制的 Canvas 在 Retina 屏上不会模糊

4. 实践建议

1. 布局元素：

   • 使用 rpx 单位，自动适配不同屏幕宽度
   • 避免直接使用 px

2. 图片和 Canvas：

   • 对图片可用多分辨率资源（@2x、@3x）
   • 对 Canvas 绘制手动乘 devicePixelRatio

3. 字体适配：

   • 小程序的 rpx 也可以用在 font-size，保证文字大小随屏幕缩放

在微信小程序里，通常我们会在 app.js 里的 onLaunch 方法里，执行微信静默授权，即调用 wx.login 。但是，由于静默授权是异步的，我们不能保证，在页面的 onLoad 里，静默授权流程已经完成了。如果再次发起 wx.login，又会重复执行静默授权，增加页面渲染时间。

通常在这种情况下，我们都实现一个全局的授权方法，比如叫wxAuthSingleton()，内部维护一个唯一的静默授权 Promise 对象，当这个对象已经存在之后，直接返回这个 Promise，如果不存在，才生成一个 Promise。每个页面，都去调用这个全局授权方法wxAuthSingleton()，得到全局相同的授权 Promise。

下面是简略代码：

const wxAuthSingleton = (function (){
    let promise = null;
    return async function wxAuthSingletonInner(){
    if (promise) {
        // 已经调用过了，可能正在执行中，或者已经执行结束
        return promise;
    }
    promise = new Promise((resolve, reject) =>{
    try {
        wx.login({
            // 注意：这里只是伪代码，需要参考官方文档修改
            async success(res){
                // 拿到code，调用后端接口
                // 这里加上异常处理
                await silentAuthLogin(res.code);
                resolve();
            },
            fail(){
                reject(new Error('静默授权失败'));
            },
        });
    } catch (err) {
        reject(err);
    }
});
};
})();

小程序（如微信小程序、支付宝小程序等）无法使用 DOM 相关的 API 主要是因为它们的设计目标和运行环境与传统的 Web 应用有所不同。以下是一些原因：

1. 运行环境限制

小程序运行在一个沙箱环境中，这个环境与传统的浏览器环境不同。小程序的渲染引擎通常是针对特定平台进行优化的，不完全依赖于浏览器的 DOM 和 CSSOM 结构。为了保证跨平台的一致性和安全性，开发者无法直接操作 DOM。

2. 设计目标

• 跨平台一致性：小程序的目标是让应用能够在不同的操作系统（如 iOS 和 Android）上以一致的方式运行。直接操作 DOM 可能导致平台间的不一致性，因此小程序框架提供了自己的视图层来保证一致性。

• 性能和安全性：直接操作 DOM 可能会影响性能和引入安全风险。小程序框架通过抽象和优化渲染过程来提高性能，并提供了更高的安全性。

3. 使用小程序的视图层

小程序使用自己的视图层（如 WXML 和 WXSS）来描述界面。这些视图层通过特定的 API 进行操作，开发者通过调用小程序提供的 API 来更新视图、处理用户交互等，而不是直接操作 DOM。这样做可以将视图渲染和逻辑处理分离，简化开发和维护。

4. 组件化

小程序强调组件化开发，通过定义组件并使用组件的生命周期来管理 UI 和交互。组件内部封装了 DOM 操作的细节，开发者只需关注组件的属性和事件，而不需要直接操作 DOM 元素。

微信小程序采用了类似于Web的WXML和WXSS语言来描述页面结构和样式，但是却没有提供直接操作DOM的API。

这是因为小程序本身是在一个JavaScript环境中运行的，其选用的是JavaScriptCore引擎，而不是浏览器中常见的V8引擎。JavaScriptCore与V8引擎的实现方式存在较大差异，其中一个显著的特点是JavaScriptCore的执行速度较慢。对于小程序开发者来说，直接操作DOM会比较耗时，会导致性能下降和体验差。

另外，小程序的设计初衷也是为了提供一种更轻量级、更快速启动的应用方式，它的定位是“去中心化、低门槛、高灵活性”的。如果允许开发者直接操作DOM，那么就可能会打破这种设计理念，增加小程序的复杂性和开发难度。

因此，微信小程序暂时不支持直接操作DOM。开发者需要通过其他方式来实现类似的功能，例如使用组件或自定义组件，利用微信小程序提供的API进行页面渲染和交互。

双线程指的是客户端运行时有两个线程，分别是渲染线程和逻辑线程。

• 渲染线程：负责渲染界面，包括解析WXML和WXSS、样式计算、布局排版和绘制视图等操作。

• 逻辑线程：负责处理业务逻辑和数据处理，包括调用小程序API、处理事件、请求网络等操作。

通过双线程协同工作，可以实现小程序的高性能和流畅体验。当界面需要进行更新时，渲染线程会优先响应，避免造成卡顿；而逻辑线程则负责处理复杂的业务逻辑，不会对界面渲染产生影响。这种设计可以有效地提高小程序的运行效率，同时也能够更好地满足用户对于小程序的使用需求。

微信小程序的架构是一个融合了前端显示与后端逻辑处理的综合性系统，其设计旨在为用户提供无需下载安装即可使用的便捷应用体验。微信小程序的架构主要包括视图层（View）和逻辑层（App Service），以及它们之间的数据通讯机制。以下是对微信小程序架构的详细解析：

一、整体架构

微信小程序架构主要分为两个主要部分：

1. 视图层（View）：

   • 负责页面的渲染和展示，用户通过视图层与小程序进行交互。
   • 使用微信自定义的标记语言WXML（WeiXin Markup Language）来描述页面结构，类似于HTML。
   • 使用WXSS（WeiXin Style Sheets）来控制页面样式，类似于CSS，但增加了一些特定的尺寸单位（如rpx）以适应不同屏幕尺寸。

2. 逻辑层（App Service）：

   • 负责小程序的业务逻辑处理，包括数据的获取、处理以及与视图层的交互。
   • 使用JavaScript语言进行开发，微信提供了丰富的API供开发者调用，以实现各种功能，如网络通信、本地存储、设备信息等。

二、文件结构

微信小程序的每个页面通常包含四个文件：

• .wxml：页面的结构文件，使用WXML描述。
• .wxss：页面的样式文件，使用WXSS定义。
• .js：页面的逻辑文件，使用JavaScript编写。
• .json：页面的配置文件，用于配置页面的窗口表现、导航条样式、标题等。

此外，小程序的全局配置、全局样式和全局逻辑分别通过app.json、app.wxss和app.js文件进行配置和管理。

三、数据通讯机制

视图层和逻辑层之间的数据通讯是小程序架构的核心之一。微信小程序支持数据绑定和事件系统，以实现视图层与逻辑层之间的数据通讯：

1. 数据绑定：

   • 开发者可以在WXML中使用双大括号{{}}语法将视图层的组件与逻辑层的数据关联起来。
   • 当逻辑层的数据发生变化时，框架能够自动将最新的数据渲染到视图层，实现数据的动态展示和更新。

2. 事件系统：

   • 视图层通过事件绑定来响应用户的交互操作，如点击、滑动等。
   • 事件绑定通过bind或catch前缀实现，并在对应的.js文件中定义处理函数。
   • 当用户触发事件时，框架会调用对应的处理函数，并将事件对象作为参数传递，从而实现用户交互和数据传递。

四、架构模式

微信小程序主要采用的是MVVM（Model-View-ViewModel）架构模式：

• Model：代表数据模型，是数据的存储和处理中心。
• View：代表UI组件，用于展示数据和接收用户输入。
• ViewModel：作为View和Model的桥梁，负责将Model的数据变化映射到View上，并响应View上的用户操作，更新Model的数据。

微信小程序的架构是一个以视图层和逻辑层为核心，通过数据绑定和事件系统实现数据通讯的综合性系统。其设计理念和实现方式为用户提供了便捷的应用体验，同时也为开发者提供了强大的开发工具和丰富的资源支持。

微信小程序的运行原理可以拆解为以下几个核心层面：

1. 双线程架构设计

采用逻辑层（App Service）与渲染层（View）分离的模型：

• 逻辑线程：运行在独立的 JavaScript 引擎中（iOS：JavaScriptCore，Android：V8），处理业务逻辑、数据请求及状态管理
• 渲染线程：基于 WebView 渲染界面，但禁用了常规浏览器 API（如 DOM 操作）
• 通信机制：通过 Native 层的中转站进行数据交换（序列化为字符串传输），采用事件驱动更新

2. 预编译与沙箱环境

• WXML/WXSS 编译：模板语言被编译为虚拟 DOM 结构的 JS 对象，样式被转换为特定 CSS 规则
• JavaScript 限制：运行在沙箱环境中，无 window/document 对象，禁止动态执行代码（如 eval）
• 模块系统：基于 CommonJS 规范实现模块隔离，每个页面/组件有独立作用域

3. 原生组件混合渲染

• 内置组件：如
• 性能优化：滚动容器（scroll-view）等关键组件使用原生实现避免 WebView 性能瓶颈

4. 更新与热加载机制

• 分包加载：主包不超过 2MB，支持按需加载子包（总上限 20MB）
• 增量更新：基于版本对比的差量更新策略，减少下载体积
• 热启动：后台保持常驻内存，二次启动速度优化

5. 安全控制体系

• 域名白名单：网络请求受限为配置的合法域名
• 代码签名：所有发布包需腾讯云签名验证
• 数据隔离：不同小程序之间完全隔离存储空间

优势

1. 快速部署与低成本：

   • 商家可以快速搭建线上店铺，大大缩短了上线时间和开发周期，降低了初期投入成本。
   • 市场上存在大量的小程序开发工具，利用小程序模板就可以快速创建小程序，降低了开发难度和成本。
   • 开发和运营推广成本仅为APP的十分之一，对于创业者或传统商家来说是一大优势。

2. 用户体验好：

   • 无需下载安装即可使用，不占手机内存，方便快捷。
   • 用户体验流畅，加载速度快，能够提供良好的用户体验。

3. 功能丰富：

   • 模板小程序通常集成了电商所需的各项基本功能，如商品展示、购物车、在线支付、订单管理、物流跟踪、会员系统、积分兑换、优惠券发放等，实现一站式电商交易闭环。
   • 可以调用更多的手机系统功能进行开发，如GPS定位、录音、拍视频、重力感应等，能开发更丰富的使用场景。

4. 入口众多：

   • 微信小程序具有多种入口，如扫码、搜索、附近的小程序、公众号关联等，为小程序带来更多的曝光和开启机会。

5. 社交裂变：

   • 借助微信的社交属性，小程序可以通过社交裂变的方式快速传播，增大企业产品的曝光率。

6. 生态完整：

   • 微信小程序以微信为生态环境，可以充分利用微信平台的用户、支付、社交等资源，为商家提供更加全面的服务。

劣势

1. 功能限制：

   • 小程序的总代码量有限制（目前单个分包/主包大小不能超过2M，整体小程序大小不超过8M），导致无法开发大型复杂的应用。
   • 功能受限于微信开放的功能，部分复杂功能无法实现。

2. 开放性不足：

   • 小程序不支持随意跳转外链，每个外链都需要到后台“开发设置”里添加业务域名，这样就限制了其他支付方式以及功能的接入。
   • 无法被分享到微信朋友圈，错失了这一流量巨大的入口。

3. 用户留存差：

   • 由于小程序即用即走的特点，用户对于小程序的留存相较于APP、微信公众号都是非常薄弱的，需要企业具备强大的营销能力来持续增加用户粘性。

4. 技术限制：

   • 小程序的技术框架可能不够稳定，开发方法时常有修改，导致短时间内需要频繁升级维护。
   • 所有更新需要经过腾讯的审核才能应用到小程序中，给应用的更新带来一定的风险。

5. 样式单一：

   • 小程序的部分组件样式不可修改，限制了开发者在界面设计上的自由度。

6. 新鲜度与热度：

   • 小程序的新鲜度高，但热度可能只持续一段时间，过了高潮期后可能会被遗忘。

1. 路由 URL 参数传递

这是最简单、最常用的方式，适用于传递少量、简单的数据。

• 实现方式：在调用 wx.navigateTo 或 wx.redirectTo 时，将数据以查询字符串的形式拼接到 URL 后。在目标页面的 onLoad 生命周期的参数中即可获取。
• 局限性：URL 长度有限制，且不支持传递复杂的对象或包含特殊字符（需经过 encodeURIComponent 处理）的数据。

2. 全局状态管理（App.globalData）

适用于需要在多个页面间共享的持久性配置或状态。

• 实现方式：在 app.js 定义 globalData 对象。页面通过 getApp() 访问并修改其中的属性。
• 特点：简单直观，但由于缺乏响应式监听机制，当 globalData 改变时，已打开的页面无法自动更新 UI，通常需要配合页面生命周期手动同步。

3. 数据缓存（Storage）

适用于持久化存储或大数据量的传递。

• 实现方式：利用 wx.setStorage / wx.getStorage 及其同步版本。
• 特点：数据会存储在本地磁盘。适合传递如用户信息、配置缓存等不经常变动的数据。需要注意及时清理，避免占用过多本地空间。

4. 事件通道（EventChannel）

这是 wx.navigateTo 提供的一个高级特性，专门用于打开页面与被打开页面之间的双向通信。

• 实现方式：在跳转时定义 events 监听回调，目标页面通过 this.getOpenerEventChannel() 获取通道。
• 优势：支持双向实时通信，不仅可以从 A 传到 B，B 也可以在处理完逻辑后通过通道向 A 回传数据，非常适合表单选择、弹窗反馈等场景。

5. 全局事件总线（EventBus）或 状态管理库

对于大型项目，通常会引入像 MobX、Pinia 或自实现的 Pub/Sub（发布订阅）模式。

• 实现方式：创建一个全局单例的事件中心。页面 A 订阅某个事件，页面 B 触发该事件并携带数据。
• 特点：解耦了页面间的直接依赖，适合处理跨层级、多页面的复杂通信需求。

• 相同点： 都是点击事件
• 不同点： bindtap 不会阻止冒泡，catchtap 可以阻止冒泡。

小程序 WXSS (WeiXin Style Sheets) 与标准 CSS 在核心概念上保持一致，但针对小程序运行环境做了特定调整和扩展，主要差异体现在以下几个方面：

1. 尺寸单位扩展 WXSS 在传统 CSS 单位基础上引入了 rpx（responsive pixel）单位，可根据屏幕宽度进行自适应缩放（1rpx ≈ 0.5px @750px 设计稿标准）。这种设计简化了多端适配工作流，而标准 CSS 需要依赖 rem/vw 等方案实现类似效果。

2. 样式隔离机制 小程序默认启用样式隔离，组件样式不会影响外部页面。这种隔离通过给组件添加唯一属性选择器实现，与标准 CSS 的全局作用域形成对比。CSS Modules 或 Scoped CSS 虽然能实现类似效果，但需要额外配置。

3. 选择器支持差异 WXSS 选择器支持度约为 CSS2 水平，部分 CSS3 选择器（如 :first-child）可能表现不一致。特别限制包括：

• 不支持属性选择器
• 不支持级联选择器（如 div p）
• 通配符 * 作用范围有限

4. 预处理器支持 原生 WXSS 不支持 Sass/Less 等预处理语法（需依赖构建工具转换），而现代 CSS 开发通常直接集成预处理工具链。

5. 导入方式 WXSS 使用 @import 语句时必须指定相对路径，且不支持 CSS 原生 @charset 规则。

微信小程序的主要文件构成相对清晰，主要包括以下几个部分：

1. 全局文件

• app.js：小程序的逻辑层入口文件，用于注册小程序全局实例，编译时会和其他页面的逻辑文件打包成一个JavaScript文件。它是小程序中不可或缺的一部分，负责小程序的初始化和全局变量的定义等。
• app.json：小程序的全局配置文件，用于配置小程序的一些基本信息，如页面路径、窗口样式、tabBar、网络超时等。这个文件是必需的，因为它定义了小程序的整体结构和一些基础设置。
• app.wxss（或app.css）：小程序的全局样式文件，用于设置全局的样式、主题色等。这个文件虽然不是必需的，但它在全局范围内应用样式，可以极大地提高开发效率。
• project.config.json：小程序项目的开发工具配置文件，包含了项目的个性化配置信息，如开发者工具配置、插件配置等。这个文件对于开发者来说非常重要，因为它允许开发者根据自己的需求调整开发工具的设置。

2. 页面文件

对于小程序的每一个页面，通常都包含以下四个文件，且这四个文件必须具有相同的路径与文件名：

• .js：页面的逻辑文件，用于编写JavaScript代码以控制页面逻辑，包括数据处理、事件处理以及与后端的交互等。这个文件在页面中是不可缺少的。
• .json：页面的配置文件，用于指定该页面的窗口样式、导航栏样式等。这个文件也是页面不可或缺的组成部分。
• .wxml：页面的结构文件，用于编写页面结构和组件标签，类似于HTML文件中的扩展名为.html的文件。它是页面内容的基础，定义了页面的布局和数据绑定等。
• .wxss（或.css）：页面的样式表文件，用于定义页面中用到的各类样式表。这个文件虽然不是必需的，但它在页面样式的定义和布局调整中起着重要作用。

3. 其他可选文件

除了上述主要文件外，小程序还可以包含其他可选文件，如：

• sitemap.json：用于配置小程序的页面索引，以便搜索引擎收录。这个文件是可选的，但对于希望提高小程序搜索可见性的开发者来说是有用的。
• utils文件夹：用于存放一些工具类、通用函数或者封装的功能模块，以便在不同页面中复用。
• components文件夹：用于存放自定义组件，以便在不同页面中引用和复用。每个组件也包括.wxml、.wxss、.js和.json四个文件。
• images文件夹：用于存放小程序中使用的图片资源，如图标、背景图等。

总结

微信小程序的主要文件包括全局文件（如app.js、app.json、app.wxss、project.config.json）和页面文件（如.js、.json、.wxml、.wxss）。此外，还可以包含其他可选文件以丰富小程序的功能和外观。这些文件共同构成了小程序的完整结构和功能。