选择JS全静态方法类或独立函数文件是否存在功能性原因？

这两种写法不是纯粹的代码风格区别，存在少量实际功能性差异，不过多数日常场景下二者可以互相替代，选型更多受开发习惯影响。

实际存在的功能性差异 #

• 命名空间与导入使用的区别
  全静态类天然自带聚合命名空间，导入后统一通过JWT.xxx()的形式调用，不需要担心和其他模块的同名函数冲突。如果用独立函数导出，要达到同样的聚合调用效果，需要用import * as jwt from './jwt.ts'把整个模块当对象导入；二者的区别是ES模块的导入对象是只读不可修改的，而类的静态属性/方法可以在运行时被改写。如果直接用命名导入import { getPayload } from './jwt.ts'，遇到同名函数就必须手动起别名避免冲突。
• 面向对象特性支持的区别
  类支持继承、实现TS接口，比如后续要扩展JWT能力，可以写子类继承原有JWT类，重写个别静态方法，也可以把类作为值传入符合类型约束的场景（比如要求参数是带指定静态方法的构造函数类型）。独立导出的函数没有继承、实现类接口的能力，要做扩展只能手动写包装函数。
• 打包构建的tree shaking效果区别
  主流打包器对ES模块的独立导出函数分析效率更高，没有被引用的函数可以在生产构建时直接被剔除，减小包体积。如果导出的是包含全静态方法的类，绝大多数打包器很难把类内部未使用的静态方法单独拆分摇掉，通常会把整个类全部打入产物，对包体积敏感的前端场景这是很实际的影响。
• 运行时行为的区别
  类静态方法内部的this默认指向类本身，ES模块顶层定义的独立函数在严格模式下this为undefined。另外全静态类默认是可以被new实例化的（当然可以通过添加私有构造器private constructor() {}禁止这种无意义的实例化操作），独立函数不存在被实例化的可能。

全静态类写法的来源 #

这种写法大多是从Java、C#等传统面向对象语言的开发习惯迁移来的，在ES6模块标准普及之前，JS没有原生的模块规范，开发者通常会用构造函数、类挂载静态方法的方式做命名空间，避免全局变量污染，属于历史遗留的开发习惯。在ES模块已经成为Web、Node.js通用标准的现在，多数工具函数场景下，独立导出函数+模块命名空间导入的写法完全可以替代全静态类，还能获得更好的构建优化效果。

选型建议 #

• 如果你的工具集后续需要支持继承重写、或者要适配要求传入类构造器的类型定义，可以选全静态类写法，记得加私有构造器禁止实例化。
• 如果只是普通的无状态工具函数集合，优先选独立函数导出的形式，构建优化空间更大，写法也更灵活。

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