省流版)
每日一学：基础知识精讲（枚举篇）
枚举（Enum）：给提瓦特的 “固定规则” 定死边界
1. 枚举的核心逻辑
枚举是「一组固定、有限的常量集合」，用来表示 “不会变化的分类 / 状态”—— 比如一周七天、四季，核心价值是避免魔法值（随意写的字符串 / 数字）导致的错误，让代码更规范。
2. 原神场景类比：元素类型枚举
提瓦特的元素类型是固定的（风、岩、雷、草、水、火、冰），不会新增也不会减少，完美契合枚举的使用场景。
下面我将用传统的代码和枚举方法对比一下为什么枚举这么受欢迎。
创建枚举类的步骤：
1. 声明枚举类型：使用 enum 关键字声明枚举类
2. 定义枚举常量：在枚举类中定义具体的枚举实例，通常使用大写字母命名
3. 添加成员变量（可选）：为枚举类添加属性来存储更多信息
4. 创建构造方法：枚举的构造方法必须是私有的，并用于初始化成员变量
5. 添加getter方法：提供公共方法来访问枚举实例的属性
6. 添加自定义方法（可选）：在枚举中定义业务逻辑方法
7. 使用枚举：通过枚举常量名直接使用枚举
那么接下来看一下，同样的业务逻辑用传统的方法是怎么做的。
1.定义常量：使用 public static final String 定义各元素常量如 PYRO, HYDRO 等
2.创建数据载体类：定义 ElementInfo 类来封装元素的多种属性（英文名、代表角色、反应列表等
3.建立映射关系：
使用 HashMap 创建元素常量到 ElementInfo 对象的映射
在静态代码块中手动初始化所有元素信息
4.提供访问方法：
提供 getElementInfo() 方法通过元素常量获取详细信息
提供 canTriggerVaporize() 等业务逻辑方法
运行结果：
两者相互对比我们不难发现相比之下传统方式的缺点有：
1. 字符串硬编码风险
容易拼写错误，如将 "火" 写成 "炎"
缺乏编译期检查，错误只能在运行时发现2. 维护一致性困难常
量定义和映射初始化分离，容易出现遗漏
添加新元素时需要同时修改多处代码3. 初始化冗余
每个元素都需要手动创建 ElementInfo 对象
代码重复度高，维护成本大4. 类型不安全
参数仍为 String 类型，可能传入非法值
编译器无法验证传入的字符串是否有效5. 扩展性差
添加新的元素属性需要修改 ElementInfo 类
相关的业务方法也需要同步更新
相比枚举方式，传统实现虽然能达到相同功能，但在安全性、可维护性和代码简洁性方面都有明显劣势。
总结：
- 传统方法的 “额外映射” 本质是用 Map / 实体类补全常量的属性绑定能力，是 “无奈的妥协”；
- 枚举天生支持 “常量 + 属性 + 方法” 一体化，无需额外映射，是更优解；
- 只有当取值范围动态变化（比如原神不定期新增活动类型）时，传统 Map 映射才更适用（可从配置文件加载映射，无需改代码）
ok,如果各位观众老爷觉得我讲的还不错，请给我留下一个小小的赞吧！🌂Q！
