最简单的方法，因为已经enum了，要改色值直接手动改就行了。
如果你一定要强迫症，要自动更新，建议写成这样。
你这个代码存在的问题
-
枚举键有改动时需要手动替换所有值
-
编辑器会展示无意义的内容（键值对，键的作用就代表描述内容）
-
如果键中包含的值（比如 #0000ff）太长代码中占用的空间太大，不符合你上面的代码洁癖，多写几个switch 都比我函数占用的字节多了
-
键有修改时你的值数组需要对应修改，数组位置错误直接取值错误
所以你怎么证明你的代码比我的不费劲？ 毕竟这上面的问题我的代码都没有
所以我要修改键中包含的值，需要做以下的操作
- 修改值
- 替换所有对应的值（还必须保证其他代码的相同字符串位置不会被替换）
- 修改键顺序时数组需要同步修改
而我的代码只需要
- 修改值
引用一下上面的话
所以我一直说你没理解我意思
针对1、枚举就是分情况讨论，有改动就改动啊。
针对2、编辑器里展示的有没有意义，根据需要来，我这个是适合一般情况的，比如
编辑器里压根不显示有关色值的东西，而是
“红色，适合新年主题”
“蓝色，让人心情平静”
具体显示什么才是有意义，由设计者根据自己需要决定，我提供的是能满足需求的方法
3、既然都enum了，说明需求本身就复杂，而不是代码复杂导致的。
还是那句话，如果不需要switch case分情况讨论，你干嘛要写个enum呢？直接获取色值就行了。
最后，代码的运行效率，简洁不是根据代码量来决定的，而是设计思路的合理性、可拓展性多方面综合考虑的结果。
让我整理下你后面的回复类型
-
你用字符串枚举是没有意义的，为什么要用这个？
-
你为什么不用取色器或者输入框，为什么要用这个？
-
枚举的类型不是 Object，你应该去看看 enum 是什么？
-
否认自己之前的发言
你转移问题的方式已经用腻了，有没有新的？
请开始你的表演，怎么优化修改值的步骤？不会你不费劲的代码比我费劲的代码还要费劲吧？，如果你不承认自己的错误就让我来给你揭穿
感觉你要么就意识模糊了，要么就是为了争个面子在死撑。
我说的意思很明确，谁都能看懂，你也能曲解成别的意思，我不知道是不是故意的，但说明跟你说什么都没意义了，因为你根本看不懂别人表达的意思。
请不要转移话题
怎么你的代码还比我的费劲呢？解释一下？反而我倒是觉得你是为了自己的面子死不承认自己的代码没我的好
如果你想诋毁我的话，你提出的所有问题我上面都有对应的回复，而我的问题你一直在转移话题，我觉得你应该是意识模糊了，需要去医院看看
修改值你就直接改，这就是最合理的做法
哦？请问你怎么直接一步修改所有对应的值呢？包括其他脚本引用当前脚本的值？但又不能修改到其他脚本相同值但是毫不相干的字符串
包括你的数组顺序，怎么在我修改枚举内键的顺序的时候自动修复呢？毕竟我的代码不需要这些
为什么要“自动修改”、“自动修复”？你处理的是enum，不是object，我说的意思一直很明确，enum的情况下已经都枚举出来了，你所谓的改动有多少频次呢？有多少使用场景？
因为这是enum，不是object，所以说意义不大，有问题么？
哦，既然你自己说了不能自动修改，自动修复，那么是不是承认了自己的代码用起来比我的费劲？
你营造了一个前提，就是你枚举了很多种情况，然后又有很多大量修改的需求。
我说的是，这种前提没有使用场景，因此为了满足这种需求写那一段代码是没有意义的。
抱歉我可没有说有很多，我说的情况单独修改一次会触发的操作
你扪心自问下，你自己写个enum，有多少次大量修改的情况发生？
简单的修改直接改就行了，是不是没有使用场景？为了争口气跟我杠半天
我只是说了修改键中包含的值会触发的操作，请问你指的很多种情况是什么？列举一下？
这不是你自己吗？死不承认自己的代码用起来比我的麻烦，一问就转移话题
另外我想问下你写的代码永远都是一次通过？策划不改需求？这个功能模块一直保留？你们项目只新加代码从不删/改代码？
别搞笑了大哥，是个人都能看出来你在转移话题
你说的情况都存在，但不存在于enum的情况下。
真正到了要用enum来枚举的场合，不会存在大量的修改需求的，所以你写的那一段把enum对应到string的代码，我说意义不大。
非要能对应，写个数组映射一下会让结构更简洁合理，改动和拓展都更方便，毕竟你写个enum，肯定不只是获取一个颜色值就够了，还有其他变量呢？你不一样要区分处理么。
如果你说我就一个颜色值写个enum，我建议你用拾色器获取，直接处理就行了，不需要写enum
又来了又来了，解决不了问题就解决提出问题的人，或者修改问题？别转移话题了