小程序开发实战

SAAS服务商的应用大多数都是一对多的模式，这种场景下微信小程序提供的的We分析工具很难满足业务的诉求。期望搭建用户行为分析平台不仅可以满足客户需求，同时内部基于用户行为数据分析SAAS各个模块的活跃

服务商SAAS开发者的苦难：定制需求。当前导购业务SAAS产品面临"客户认可产品核心能力，但存在定制化需求"的问题。

当线上环境捕获错误日志时，需建立标准化处理流程确保问题闭环。本规范结合导购小程序特点和错误日志的日志级别指定，重点解决生产环境JS报错排查难的问题，同时及时处理异常报错增加线上环境的稳定性。

当前导购小程序有一套错误监控方案，但也仅限在导购小程序使用无法普及到其他项目中。基于此我们准备对错误监控方案做升级。期望新版本的错误监控体系可观测、可追踪。

作为SAAS服务商，理论场景开发应用都要可以实现1对多，即可以通过账号体系授权登录实现客户登录应用。但是这个仅限理论场景。现实的问题是你可能会同时维护20个以上小程序。

在业务迭代过程中，我们面临着将原有Wepy项目与新型Taro框架整合的技术挑战。本文针对小程序多框架混合构建场景，分享从源码编译到产物发布的完整解决方案

现有小程序采用Wepy框架开发，需接入NutUI日历组件实现时间区间选择功能，为了实现该功能需要找到一个方式可以在Wepy框架调用Taro框架的组件。

CSS通过@font-face规则支持自定义字体加载，实现文字符号的图形化渲染。每个Unicode字符对应特定矢量图形，浏览器根据字符编码自动匹配并渲染为预设图标。

一个官方不在维护的小程序框架Wepy1.6.0，需要为此找到一个当前可以迁移的到Taro框架的方案，同时考虑方案的可行性！那如何实现多框架打包呢

将企微侧边栏的H5可以平迁到小程序的webview中使用，做到一套代码多端使用。同时要保证在小程序使用的H5可以跟原生小程序进行交互。

一般的场景个号小程序很难遇到在同一个小程序做多角色切换的场景。但在企业微信私域环境，随着客户数据维度的增加，如：多店铺、多区域、管理者等。客户会期望不同维度或者权限的人展示不同的信息。