一、小程序开发的“变”与“不变”
从2017年微信小程序正式上线，到如今各家超级App都搭建起自己的小程序生态，八年时间过去了。小程序开发这件事，看似成熟稳定，实则一直在演进。
不变的：小程序的核心理念——即用即走、轻量便捷、依托宿主——始终没变。开发范式上，Page/Component、生命周期、setData/this.setState这类模型依然是主流。
变化的：开发工具链越来越成熟，跨端框架百花齐放，云开发降低了后端门槛，渲染引擎也从最初的WebView转向了原生渲染与Hybrid并存的局面。
回顾这些年，我认为理解小程序开发的核心，不在于掌握某个框架的API，而在于理解它的运行环境约束和宿主生态规则。
二、运行环境：小程序的“围城”
小程序运行在一个“半封闭”的环境中，这既是它的优势，也是开发时需要时刻警惕的约束。
1. 双线程模型
小程序的架构核心是双线程模型：渲染层（WebView）与逻辑层（JSCore/V8）分离。这意味着：
DOM操作不可用：所有UI更新必须通过数据驱动
setData是性能命门：每次调用都是线程间通信，数据量过大或频率过高都会导致卡顿
同步API有限制：大量API设计为异步，开发时需注意时序问题
一个常见的性能优化点：合并setData调用，避免在循环中频繁触发。这个道理虽然简单，但在实际代码review中依然经常看到。
2. 包体积与资源加载
小程序对包体积有严格限制（主包通常不超过2MB）。这迫使我们思考：
分包加载不是“可选项”，而是“必选项”
图片资源必须走CDN，而非打包进项目
按需引入第三方库，tree-shaking在小程序环境下需要格外留意
三、跨端开发：理想与现实的差距
“一套代码，多端运行”是跨端框架的核心卖点。但实际落地时，有几个问题值得冷静看待。
1. 差异抽象层
Taro、uni-app这类框架本质上是在各个平台之上构建了一个差异抽象层。抽象层越厚，开发体验越统一，但性能损耗和排查问题的难度也相应增加。
当你需要调用某个平台的特色能力（比如微信的订阅消息、支付宝的生活号）时，不可避免地要写条件编译或平台判断代码。完全抹平差异是不现实的，接受这一点反而能让技术选型更务实。
2. 生态兼容
跨端框架通常滞后于平台原生能力更新。当微信小程序发布新能力时，跨端框架需要时间适配。如果你的业务重度依赖最新平台特性，原生开发可能是更稳妥的选择。
四、工程化实践
小程序开发早已脱离“写几个页面就完事”的阶段，工程化能力直接决定了项目的可维护性。
1. TypeScript 是标配
无论选择原生还是跨端框架，TypeScript都应该成为标配。小程序项目的API数量多、回调嵌套深，类型系统能显著降低心智负担。配合正确的类型声明文件（如@types/wechat-miniprogram），开发体验可以提升一个档次。
2. 状态管理的取舍
小程序的状态管理不需要照搬Web端的Redux、Pinia。大多数场景下，以下策略已经足够：
页面级状态：组件间通信通过props/events
跨页面状态：使用全局存储（
getApp()）或简单的事件总线复杂全局状态：确有需要再引入专门的库
过度设计状态管理，在小程序项目中带来的收益往往低于预期。
3. 请求层封装
网络请求是小程序与后端交互的命脉。一个稳健的请求封装应该包含：
自动携带登录态（sessionKey/token）
请求/响应拦截器
统一的错误处理与上报
并发请求控制与请求去重
这些能力在原生小程序中需要手动封装，跨端框架通常提供了更完善的方案。
五、关于性能优化的几点体会
1. 长列表渲染
小程序的列表渲染有天然的瓶颈。当列表项过多时，setData传递大量数据会导致明显的卡顿。常见的优化手段：
虚拟列表（只渲染可视区域）
分页加载 + 增量更新
使用
createIntersectionObserver实现懒加载
2. 图片资源优化
图片通常是小程序中的“流量大户”和“性能杀手”：
使用WebP格式（微信等平台已支持）
根据屏幕尺寸动态拼接图片URL参数
懒加载机制
预加载策略的合理运用
3. 首屏加载
首屏速度直接影响用户留存。优化方向包括：
主包体积精简
利用预加载（preload）能力
骨架屏提升感知性能
关键数据优先请求，非关键数据延迟加载
六、结语
小程序开发的技术栈虽然不像Web前端那样“日新月异”，但它的演进一直在持续。从最初的简单页面容器，到如今承载复杂业务的完整应用生态，小程序开发正在变得越来越“重型”，对工程化、性能、稳定性的要求也在不断提高。
如果说有什么值得长期关注的方向，我认为是：跨端能力的持续演进、云原生开发模式的普及，以及AI能力与小程序的深度融合。
技术分享的意义，不在于提供“标准答案”，而在于呈现一个经过实践检验的思考路径。希望这篇文章能为你提供一些参考，也欢迎交流指正。