一次郑州本地生活服务类小程序项目把兼容问题暴露得很直接：同一套页面在不同版本微信、安卓和 iOS 机型上表现各异，渲染错位、无法拿到 safe-area、网络超时错位断流。那时我们决定从技术栈和构建策略两端同时入手，目标不是堆依赖，而是把“轻量化”当作第一准则。

      选型上，我倾向于原生小程序加渐进式组件化：页面用原生 WXML/WXSS，状态管理用轻量 Pub/Sub 或 pinia-like 思路的自研微状态库。为什么不首选跨端框架？因为跨端带来的打包体积和运行时差异在调试阶段成本太高。需要多端覆盖时，再用 Taro 或 uni-app 做一套编译分支。

      构建细节不可省：开启 es6 转 ES5、配置 terser 压缩、开启 sourceMap 便于线上错误定位；同时把第三方 npm 包做按需引入与 tree-shaking。实操中我把 dayjs 替代 moment，lodash 改为 lodash-es 并在 webpack（或 mp-vite）里配置 sideEffects:false，效果明显——首屏 JS 包减少 30% 左右。

      性能优化不仅是构建。分包（subpackages）和按路由懒加载能显著缩短首屏渲染，但注意分包边界的公共状态传递与 onShareAppMessage 的路径限制。数据更新尽量用局部 setData，避免一次性传入整个 state；复杂计算放到云函数或使用 WebWorker 思路的子包处理，降低主线程压力。

      网络层实战：采用自封装请求库，封装重试、限流和统一的 token 刷新拦截器。调试时我常用 Charles 做抓包，结合微信开发者工具的网络面板对比请求头与实际返回差异。遇到偶发 502，往往是 CDN 配置与后端 keep-alive 不一致，排查从 TCP 层开始更靠谱。

      兼容性检查是工程化流程的一部分：CI 用 miniprogram-ci 自动打包并上传体验版，集成基础库降级测试脚本；关键机型上跑真机回归并记录 video，配合 crashlog 上报做回溯。我的体会是：早期覆盖 3 个代表性设备，比后期大量设备抽样更省时间。

      最后几点建议：把体积、启动时延和内存当作首要指标；常用工具包括微信开发者工具、mpx/mini-program-simulate、miniprogram-ci 与 Charles；遇到兼容怪异先定位基础库版本与系统信息再动代码。未来可能会更多看到端内能力拓展，当前务实地把工程化做好，是真正能稳住体验的策略。