当小程序主包只剩下几十KB，每 1KB，都是真金白银！

做过小程序的人，大概都有过一个共同的深夜时刻。

打包完成，控制台弹出一行刺眼的红字：主包超出限制！

你开始一行行地翻代码，删掉一张用了半年却没人点的运营图，压缩一段冗余的工具函数，甚至开始纠结要不要把某个第三方 SDK 换成"更轻的版本"。

在小程序的世界里，主包的每 1KB，都是真金白银。

微信 2MB、支付宝 4MB、抖音 4MB——这是小程序主包的物理上限。

看起来不小，但真正开发过就知道，这点空间要装下：

• 核心业务代码

• 首屏页面与组件

• UI 资源、图标、字体

• 埋点、监控、A/B 实验框架

• 通信、支付、地图等各类 SDK

• ……

而其中最容易"超预算"的，往往是第三方 SDK。

一个功能全面的 IM SDK，动辄 700-800 KB，甚至更大。

对于一个只需要“发发消息、拉个会话”的轻交互场景来说，这样的体积代价，是否值得？

这是我们在与大量小程序开发者沟通中，被反复问到的一个问题。

过去很多年，SDK 的设计逻辑是"功能越全越好"，以此来覆盖尽可能多的场景，兼容尽可能多的环境，提供尽可能丰富的能力。

这套逻辑在 Web 端、App 端是成立的，因为体积不是最敏感的成本。

但在小程序场景下，这套逻辑开始失效：

• 开发者只用了 SDK 的一小部分能力，却要为全部功能"付费"

• 为了兼容极少数低版本环境，SDK 背负了大量历史包袱

• 多端适配逻辑散落在各处，耦合严重、难以裁剪

结果就是：一个"大而全"的 SDK，挤压了业务本该拥有的空间。

我们意识到，是时候用小程序自己的方式，重新设计一款 SDK 了。

7 月，网易智企·云信正式发布了小程序 IM SDK 的轻量化版本 —— Lite 版。

默认提供的 basic 核心包体积控制在 200KB 以内，约为传统全量 SDK 的 1/4，并与全量版保持一致的 API 参数。

但更重要的不是这个数字，而是我们做这件事的方式。

云信不是简单删掉几个"看起来没用"的模块，不是把代码压缩工具的参数调得更狠，不是牺牲稳定性去换体积。

云信是把 SDK 拆成"核心链路 + 扩展能力"两层，核心链路只保留登录、消息、会话、用户等最基础的模块，扩展能力按需加载。同时，针对小程序场景，剥离低频使用的模块（如某些复杂的音视频扩展、企业级管理接口等）。

我们把散落在各处的多端适配逻辑（微信、支付宝、抖音、uni-app…）统一收敛到一层适配器中，减少重复代码。

而且，更进一步聚焦文本消息、自定义消息等高频场景，覆盖 80% 以上的小程序 IM 需求。

另外，我们放弃对低版本浏览器等场景的兼容，只支持 ES2015+ 环境，这个在 2026 年，是一个合理的取舍。

因此，Lite 版基于 Web SDK v10 API 体系演进，并不是一个"新 SDK"，而是同一套体系下更精炼的形态。

很多人第一反应是："这么小，是不是能力也很弱？"事实上，Lite 版的 basic 产物已经完整覆盖了小程序 IM 的核心链路，包括：登录、消息、会话、用户&好友以及订阅&通知。

可以覆盖电商客服咨询、社群消息推送、在线教育师生沟通、工具类应用的通知触达以及内容社区的私信互动等诸多场景。

对于开发者来说，一套 SDK 覆盖浏览器（ES2015+）、微信 / QQ / 抖音 / 百度 / 支付宝小程序、以及 uni-app 场景。SDK 内置运行时环境识别能力，接入时几乎无需额外配置。

当然，体积数字只是结果，真正的变化发生在开发者的工作流里。

过去为了塞下全量 SDK，很多团队被迫启用分包机制，重新规划页面归属，修改 app.json，处理跨包引用。Lite 版之后，多数中小型甚至中大型项目可以不再启用分包，工程结构回归简洁。

更小的下载体积意味着更少的下载、解析、执行成本。在弱网环境、低端机型、高频冷启动场景下，这种差异会被显著放大。

微信官方建议小程序插件体积不超过 200KB。Lite 版恰好卡在这条线内，让 IM 能力作为插件被复用、被嵌入变得更加自然。

最后，我们最想传达的一点——SDK 不该和业务抢空间。我们把 SDK 做轻，就是为了让开发者能把更多空间留给页面体验、留给增长玩法、留给那些真正定义产品差异化的项目。