打开微信，点开任何一个小程序，你可能不会去想它背后跑了多少行代码。但作为一个想入行或者已经在坑里的开发者，你绕不开一个问题：这玩意儿到底用什么写的？微信小程序的技术栈，表面上看着像网页开发，实际上处处是“亲儿子”式的私有规范。今天这篇东西，不给你整那些虚头巴脑的框架对比，咱们直接拆开揉碎了聊，从你第一次打开开发者工具，到能独立撸出一个能上线的小程序，这条路上你究竟要碰哪些技术，踩哪些坑。

先得说清楚一个最基础的认知：小程序不是H5，也不是原生App。它用的是微信自己定义的一套标记语言WXML，样式用WXSS，逻辑层用JavaScript，再加上一个JSON配置文件管页面。听着是不是觉得“这不就是网页三件套换了个名”？对，但也不全对。WXML比HTML多了很多微信特有的组件和语法，比如代替，代替，绑定数据用，事件绑定用。你写惯了React或者Vue，上手会很快，但千万别手滑把写进去，编译直接报错给你看。WXSS也差不多，支持大部分CSS属性，但多了这个响应式像素单位，iPhone 6的屏幕宽度是750rpx，你照着这个基准写，适配各种机型基本不用操心。

这里要插一句，很多人一上来就问“我要不要学uni-app或者Taro”。我的看法是，如果你是纯新手，先老老实实学原生小程序，哪怕丑点，哪怕代码冗余，至少你知道了微信底层的真实逻辑。等你把原生那套摸透了，再去看跨端框架，你会发现那些框架无非就是把你的Vue或React代码，编译成WXML和WXSS。到时候你理解起编译报错、兼容性坑来，会快得多。反过来，一上来就抱着Taro写React语法，遇到一个诡异问题，你根本不知道是React的问题、Taro转译的问题，还是小程序本身的问题，排查起来像大海捞针。

说回JavaScript。小程序里的JS环境跟浏览器不完全一样，它没有完整的DOM和BOM，所以你不能用那套。但好在微信提供了丰富的API，比如发网络请求，存本地缓存，拿定位。这些API几乎全是异步回调风格，所以你很快会接触到Promise或者async/await，不然写两层回调你就想摔键盘。另外，小程序的页面逻辑是放在Page()函数里的，组件则是Component()，这两个构造器你得熟，尤其是生命周期——、、、、，每个节点该干什么，直接决定你页面体验顺不顺畅。

再往深了走，就是数据驱动的思维转变。小程序里，你写，视图才会更新。这玩意是你跟界面沟通的唯一桥梁，而且它是有性能开销的——数据量太大、频率太高，页面就会卡顿。所以进阶的核心技巧之一，就是优化：能只更新一个字段就别传整个对象，能用局部更新的路径就别全量替换。还有，列表渲染的时候，记得加，不然删个元素，整个列表都可能重渲染。这些细节，你在文档上看得再多，不如自己写一个长列表拖一下试试，那种卡顿感会让你记住一辈子。

组件化也是绕不开的坎。小程序支持自定义组件，你可以把页面拆成一个个功能块，比如商品卡片、搜索框、弹窗。组件之间传值靠，子组件往父组件发消息靠，跨组件共享状态就得靠全局或者引入第三方状态管理库，比如。这里有个坑要提醒你：组件样式默认是隔离的，父组件的class不会渗透到子组件里，你得显式开启或者用，不然你会写出一堆重复的样式代码。

到了这一步，你已经能写出一个像模像样的小程序了。但真正让它跑得稳、跑得快，还得靠后端配合。小程序要求所有请求的域名必须HTTPS，而且得在小程序管理后台配置合法域名，开发阶段可以勾选“不校验合法域名”来绕过，但上线前必须配置好。通常咱们会用云开发，这是微信官方的后端方案，你不需要自己买服务器，直接用云函数、云数据库、云存储。云函数跑在Node.js环境里，你可以用npm装包，写业务逻辑，然后通过调用。这玩意儿对个人开发者特别友好，省去了域名备案、服务器运维的麻烦，一个月几块钱的免费额度就能跑个小项目。

聊点实战层面的东西。当你准备发布，你得面对审核。微信审核对类目和内容卡得挺严，尤其是涉及支付、社交、金融的，一个资质不全就得反复打回。代码包体积限制在2M以内，超过就得用分包加载，把首屏需要的页面放主包，其他业务放分包，按需加载。还有性能监控，微信开发者工具里的Audits面板能帮你分析性能得分，什么首次渲染时间、JS执行耗时，都得有意识地去调优。

写到这里，你应该发现了，微信小程序的技术栈并不高深，但它是一套封闭且自洽的体系。你不需要会复杂的编译原理，也不用懂底层的渲染引擎，但你得有耐心去适应它的规矩。从WXML的标签到的性能敏感，从组件的样式隔离到云开发的便利，每一步都是一次思维切换。别指望看几篇教程就能成高手，找个真实项目，哪怕是给自己写个记账本，把登录、支付、列表、详情、分享这些流程全走一遍，你才算真正入了门。技术栈这东西，列出来就那么几行字，但手感，是写出来的。