在移动互联网应用形态持续演进的背景下，一种无需下载安装、即用即走的轻量级应用——微信小程序，自其诞生以来便迅速渗透至商业、生活与服务的各个角落。对于开启者而言，清晰理解其技术基底是构建高效、稳定应用的前提。本文旨在以严谨的逻辑链条与证据，系统剖析微信小程序开发所依赖的核心技术语言，厘清其在整体架构中的定位与协作关系，从而为开启者提供一个坚实的认知框架。

一、 核心语言构成：一套自成一体的技术栈

要准确回答“微信小程序用什么语言制作”，首先必须摒弃将其与单一编程语言划等号的简单思维。微信小程序采用的是一套由微信官方定义、彼此协同的技术栈，这套栈由四种核心语言或规范构成：WXML、WXSS、JavaScript以及JSON。这四者各司其职，共同构成了小程序开发的基础。

1. 视图结构描述语言：WXML

WXML（WeiXin Markup Language）是小程序框架设计的标签语言，其角色类似于传统Web开发中的HTML。它并非HTML的简单复刻。证据在于，WXML在语法上进行了大量简化和优化，移除了HTML中部分不适用于移动端或可能带来安全风险的标签与属性，同时引入了更贴合小程序数据驱动模式的特有能力。例如，它通过`{{ }}`语法实现数据绑定，通过`wx:for`指令实现列表渲染，通过`wx:if`、`wx:elif`、`wx:else`实现条件渲染。这些特性并非装饰，而是小程序响应式数据绑定系统的直接体现，使得界面能够与逻辑层数据状态自动同步。

2. 视图样式描述语言：WXSS

WXSS（WeiXin Style Sheets）用于描述WXML组件的样式，其基础语法与CSS高度兼容，这降低了前端开启者的迁移成本。但WXSS的关键性增强在于引入了rpx（responsive pixel）响应式单位。小程序规定屏幕宽度为750rpx，开启者使用rpx进行布局时，框架会自动根据屏幕宽度进行换算，从而实现了跨不同尺寸移动设备的适配。这一设计决策，从逻辑上解决了移动端开发中长期存在的屏幕适配难题，是其作为移动端专属解决方案的有力证据。

3. 逻辑层脚本语言：JavaScript

JavaScript是小程序逻辑层的仅此编程语言，负责处理所有业务逻辑，包括数据管理、事件响应、网络请求、API调用等。开启者编写的所有JavaScript代码蕞终会被打包并运行于一个独立的JavaScript引擎（在iOS上是JavaScriptCore，在Android上是V8）环境中，这个环境被称为“逻辑层”或“App Service”。需要特别指出的是，小程序中的JavaScript运行环境与浏览器环境有显著区别：它移除了浏览器中诸如`window`、`document`等与DOM操作相关的BOM对象，因为视图渲染由另前沿程（渲染层）负责。这种隔离是出于性能和安全性的双重考虑，确保了逻辑运算的纯粹性与稳定性。

4. 静态配置语言：JSON

JSON文件用于对小程序或各个页面进行静态配置。`app.json`作为全局配置文件，定义了小程序的所有页面路径、窗口表现、网络超时时间等；每个页面的`.json`文件则用于配置该页面的窗口样式等。JSON的使用贯彻了“配置与代码分离”的原则，使得应用的元数据管理更加清晰和可维护。

二、 架构逻辑：双线程模型下的语言分工协作

上述四种语言并非孤立存在，其价值在微信小程序独特的双线程模型架构下得以充分体现。理解这一架构，是理解各语言如何协同工作的关键。

小程序运行环境分为两个主要线程：

渲染层（View Thread）：由多个WebView线程组成，负责渲染WXML模板与WXSS样式，展示用户界面。

逻辑层（App Service Thread）：由一个独立的JavaScript引擎线程运行，负责执行JavaScript代码，处理数据、调用API等。

两个线程之间通过微信客户端（Native）进行中转通信，数据传递被序列化为字符串格式。这一架构设计带来了明确的职责划分与安全边界：

1. 性能与体验：将耗时的JavaScript逻辑运算与UI渲染分离，避免了脚本执行阻塞渲染导致的界面卡顿。逻辑层的数据变化通过`setData`方法，经由Native层转发至渲染层，驱动视图更新，实现了高效的响应式界面。

2. 安全性：由于渲染层（WebView）无法直接执行JavaScript，也无法直接操作另前沿程的数据，这有效防止了恶意脚本通过DOM操作获取敏感信息或干扰应用逻辑，提供了比传统Web应用更强的安全管控能力。

由此，我们可以构建一个清晰的证据链：WXML与WXSS在渲染层工作，负责视图的构建与表现；JavaScript在逻辑层工作，负责业务逻辑与状态管理；JSON作为静态配置，在应用初始化时被读取。 它们通过微信客户端建立的通信桥梁，共同完成一个完整的小程序应用生命周期。

三、 开发实践：技术栈在项目中的具体体现

在一个标准的小程序项目目录结构中，这套技术栈得以具象化：

```

project/

├── app.js // 小程序全局逻辑（JavaScript）

├── app.json // 全局配置（JSON）

├── app.wxss // 全局样式（WXSS）

└── pages/ // 页面目录

├── index/

│ ├── index.wxml // 页面结构（WXML）

│ ├── index.wxss // 页面样式（WXSS）

│ ├── index.js // 页面逻辑（JavaScript）

│ └── index.json // 页面配置（JSON）

└── ...

```

开启者通过微信开启者工具，编写WXML、WXSS、JavaScript和JSON文件。工具负责代码的编译、预览与调试。例如，当在`index.js`中调用`this.setData({ message: “Hello” })`时，数据`message`的变化会通过架构中的通信机制传递到渲染层，进而更新`index.wxml`中绑定了`{{message}}`的视图内容。整个过程印证了各语言在既定架构下的协同流程。

虽然小程序开发以官方技术栈为主，但生态中也存在如uni-app、Taro等第三方框架。这些框架允许开启者使用Vue.js或React的语法进行开发，蕞终通过编译工具将代码转换为小程序原生的WXML、WXSS和JavaScript。这可以视作对官方技术栈的语法糖封装或跨端解决方案，其底层运行时仍然离不开上述核心语言与架构的支持。

制作微信小程序并非依赖于某一种孤立的编程语言，而是基于一套由微信官方定义的、与双线程架构深度绑定的复合型技术栈。WXML承担视图结构的描述职责，WXSS负责样式定义并解决了移动端适配问题，JavaScript作为仅此的逻辑处理语言运行于隔离的线程中，而JSON则用于静态配置管理。这四者严格遵循渲染层与逻辑层分离的架构设计，通过规范的接口进行通信，共同确保了小程序在开发效率、运行性能与安全性之间的平衡。对于“微信小程序用什么语言制作”这一问题，蕞严谨的答案是：它使用一套包含WXML、WXSS、JavaScript和JSON的特定技术栈，在独特的双线程模型下进行协同开发。理解这一本质，是开启者高效利用小程序生态、构建优质应用的基础。