为何globalize-compiler需区分npm与NuGet的Globalize引入？

我来帮你拆解这个问题，先理清两类包的核心区别，再说说怎么实现你想要的构建流程。

一、npm和NuGet上Globalize包的核心差异 #

这两类包本质是对Globalize项目的不同打包分发方式，定位和用法完全不一样：

• npm的globalize与globalize-runtime分工明确
  • globalize是完整的开发包，包含了CLDR数据动态加载、国际化规则编译等开发阶段需要的功能，还附带了globalize-compiler工具的依赖。
  • globalize-runtime是专门的生产轻量运行时，它砍掉了开发阶段的冗余代码，只保留了执行国际化操作（格式化数字、日期、消息等）的核心逻辑，体积小、性能高。你用globalize-compiler生成的cldr_en.js，就是专门为这个runtime预编译的——它把CLDR数据直接绑定到runtime的逻辑里，不需要动态加载。
• NuGet的Globalize包是完整开发包的移植
  NuGet上的Globalize包，其实是把npm上的完整globalize包（包含开发+运行时所有代码）打包成NuGet格式发布的，它没有拆分出单独的runtime版本。这个包的设计预期是动态加载CLDR原始数据，而不是用预编译好的绑定数据，所以你直接把cldr_en.js和它一起引入时，会因为代码接口不匹配（runtime的绑定逻辑和完整包的加载逻辑不一样）导致报错，Globalize自然无法工作。

二、能否仅在生产环境使用NuGet包？ #

理论上可以，但非常不推荐，原因有两个：

1. 体积冗余：NuGet的完整包包含了开发时用的编译、动态加载等代码，生产环境用会平白增加加载体积，拖慢页面性能。
2. 适配成本高：要让预编译的cldr_en.js和NuGet的完整包兼容，你得修改编译逻辑或者手动适配数据绑定方式，反而比直接用globalize-runtime麻烦得多。

三、实现你的理想构建流程的建议 #

如果你想保留globalize-compiler预编译CLDR的优势，同时在生产环境精简依赖，其实可以这么做：

1. 开发阶段：用npm的globalize和globalize-compiler完成CLDR数据的编译，生成cldr_en.js。
2. 生产环境：
   • 把npm的globalize-runtime相关脚本（就是你一开始成功运行的那几个globalize-runtime/*.js）复制到你的项目静态资源目录，替换NuGet提供的完整globalize.js及相关脚本。
   • 然后只保留cldr_en.js和globalize-runtime脚本，删除npm的开发依赖包。
     这样既满足了你预编译CLDR的需求，又能在生产环境用轻量的运行时，完全不需要依赖NuGet的完整包。

补充一句：你之前用NuGet脚本报错的核心原因，就是预编译的CLDR数据是给globalize-runtime量身定做的，而NuGet的完整Globalize包不识别这种预绑定的数据格式，它还是期望你通过Globalize.load()来动态加载原始CLDR数据，所以才会出现无法工作的情况。

内容的提问来源于stack exchange，提问作者Alexander Mihailov