开发者进阶中级989 次阅读
Web3 SDK 选型：ethers、viem、web3.js 该用哪个
对比 ethers、viem 与 web3.js 在类型、体积、错误处理与生态上的差异，给出新项目和存量项目各自的选型建议。
#SDK#前端#工具链#TypeScript#选型
一句话结论
三个 SDK 都能把交易发上链，真正拉开差距的是类型体验、错误表达和维护成本。新项目默认选 viem 或 ethers，只有在接手存量代码时才继续用 web3.js。
四个维度怎么看
类型支持。ethers 与 viem 都是一等公民的 TypeScript 实现，能从合约 ABI 推导出方法参数与返回值类型，字段名写错在编译期就会报错；web3.js 的历史更久，类型信息多是后补的，动态类型的用法更常见。
包体积。viem 采用模块化设计，按需引入，打包工具能摇掉没用到的部分，对首屏体积敏感的前端更友好；ethers 提供相对完整的单一入口；web3.js 的依赖较重，通常是三者中体积最大的。
错误处理。这一项最容易被忽略。链上开发里「用户点拒绝」「链上 revert」「RPC 超时」是三件完全不同的事，要给用户三种不同提示。SDK 是否把底层错误包装成可判断的结构化错误，直接决定你要写多少字符串匹配。
生态与文档。ethers 出现最早，教程和示例最多，搜索命中率高；viem 与 React 侧的连接工具配合紧密，类型链路更短；web3.js 在其他链生态中仍有位置，以太坊侧主要用于存量项目。
怎么选
- 全新前端项目：优先 viem，类型推导与体积都占优。
- 已积累大量 ethers 代码：继续用 ethers，迁移收益通常小于风险。
- 只跑脚本或后端任务：三者都够用，选团队最熟的那个。
给你的教训
- 不要在同一个项目里长期混用两套 SDK：它们对同一概念的类型定义不兼容，最后会多出一层互相转换的胶水代码。
- 把 SDK 用法收敛到一层封装里：业务代码不直接调用 SDK，日后换库才不用全局重写。
- 错误提示要按用户能理解的语言分层：拒绝签名、余额不足、链上拥堵，文案完全不同，别都叫「交易失败」。
- 选库前看它最近一年的发布节奏与 issue 响应速度，维护活跃度比 Star 数更能说明问题。