Go 写的 CLI，为什么正越来越多地通过 npm 分发？
内容提要
文章解释为何Go、Rust等原生CLI常通过npm分发：npm实为跨平台应用商店，提供统一入口、npx免安装、免费CDN与版本管理。包装分单包内置、postinstall下载、optionalDependencies子包三种。文中拆解飞书CLI的package.json、install.js、run.js与GoReleaser配置，并实战演示将Go版HelloWorld发布到npm，涵盖注册、交叉编译、启动器编写、发布升级及避坑要点。
延伸解读
npm 作为跨平台应用商店的利与弊
文章指出，npm 为原生 CLI 提供了统一入口、npx 免安装、免费 CDN 和版本管理等便利，使其成为覆盖面最广的跨平台分发渠道。但代价是用户必须先安装 Node.js，因此更适合开发者工具，而非面向普通大众的软件。这种模式降低了分发成本，但也引入了对 Node 环境的依赖。
三种包装模式的适用场景
单包内置将所有平台二进制塞进一个包，简单但体积大；postinstall 下载按平台从外部获取，包小但依赖网络且可能被 --ignore-scripts 禁用；optionalDependencies 子包为每个平台发布独立包，主包声明可选依赖，npm 只安装匹配当前平台的子包，速度快且离线友好，但发布流程更复杂。选择取决于工具体积和分发需求。
飞书 CLI 的工程细节与安全考量
飞书 CLI 采用 postinstall 下载模式，其 install.js 实现了平台映射、多源下载（GitHub 回退到 npmmirror）、SHA-256 校验和主机白名单，run.js 则拦截 install 子命令并懒加载兜底。这些设计提升了国内网络下的可用性和供应链安全性，但也增加了维护复杂度，且依赖外部下载源。
发布与维护中的关键避坑点
文章提醒，版本号不可复用，撤回有限制，建议用 dist-tag 做灰度。企业环境可能禁用 postinstall，需懒加载兜底或改用 optionalDependencies。国内网络需镜像回退，供应链安全需校验和与域名限制。静态编译（CGO_ENABLED=0）和 Windows 文件占用问题也需注意。macOS 签名公证对公众工具值得投入。
Q&A
为什么Go、Rust写的CLI工具越来越多地通过npm分发？
因为npm实际上扮演了跨平台应用商店的角色，提供统一入口、npx免安装、免费CDN与版本管理、PATH自动处理，且开发者环境高度重合，能大幅降低分发成本。
把原生二进制包装进npm包有哪几种常见模式？
主要有三种：单包内置所有平台二进制；postinstall下载（安装时按平台从外部下载）；optionalDependencies子包（每个平台一个子包，npm只安装匹配当前平台的）。
飞书CLI的npm包是如何实现套壳的？
package.json声明bin指向run.js启动器、postinstall调用install.js下载二进制、os/cpu限定平台、files白名单只含脚本和校验和；GoReleaser编译二进制到GitHub Releases；install.js负责下载、校验和镜像回退；run.js负责转发参数和懒加载兜底。
如何把一个Go写的HelloWorld发布到npm？
注册npm账号并开启2FA，交叉编译Go程序生成多平台二进制，编写package.json和run.js启动器，本地用npm pack --dry-run和npm install -g .验证，然后npm publish发布。
发布到npm后如何升级和维护包？
版本号不可复用，修改后需升版本再发布；撤回有限制，建议用npm deprecate标记问题版本；可用dist-tag做灰度；正式项目建议用GitHub Actions自动化并采用受信任发布或细粒度令牌。
通过npm分发原生CLI有哪些常见坑？
包括--ignore-scripts导致postinstall失效、国内网络下载不稳定、供应链安全风险、静态编译问题、Windows文件占用、macOS签名公证、以及files白名单漏掉许可证和README等。
