为何用struct而非static class存储常量？以JWT相关结构体为例

1. 已有静态类常量容器，为何仍用结构体？ #

• 历史兼容需求：这类结构体属于早期API设计的遗留产物。在Microsoft.IdentityModel.Tokens的迭代过程中，可能先推出了结构体版本的常量容器，后续为贴合编码规范新增了静态类版本，但为了不破坏大量依赖这些结构体的现有代码，只能保留结构体实现。
• 语义更精准：结构体在语义上能强化“这些常量完全绑定JWT头/注册声明这个特定实体”的认知，相比通用静态类，能更清晰地传递API意图——看到结构体名就知道这是专属JWT头参数/注册声明的常量集合。

2. 为何设计仅含常量或静态成员的结构体？ #

• 隐性限制实例化：结构体无法删除默认无参构造，但如果只存静态成员，开发者即便实例化了结构体，也拿不到任何可用的实例成员，这就从设计上引导用户直接通过类型名访问常量，避免无意义的对象创建。
• 更清晰的常量分组：结构体作为容器，能把同属一类的JWT常量聚合在一起，在代码补全时，输入JwtHeaderParameterNames.就能直接看到所有头参数相关常量，比零散常量或通用静态类的组织性更强。
• 早期.NET设计习惯：在.NET发展初期，用结构体做静态常量容器是不少开发者的选择，属于当时的常见编码风格。虽然现在更推荐用静态类，但历史遗留的API会延续这种设计。

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