就是一个再简单不过的变量 或许提高了一丢丢可读性（简化了注释哈哈） 
我只能说每家公司的思维是不同的，相对雅基，夸张点讲，如果你发现他的代码里有个1=2（举例表示一个显而易见的逻辑或代码语法错误）的代码，如果你提bug，他的第一反应大概率就是，请告诉我在哪个平台出现了什么bug，而不是去看代码可能造成的问题。
当然，我并不对此有任何反对，因为能跑就不要动，谁知道就因为这个错才没造成更大的错呢？但是吧，相对引擎，个人认为这种方式很容易造成屎山，越到后面越难维护，顺便可以联想到的就是cocos的各种不兼容。
针对你这个问题，我觉得不如像楼上的所说，自己定义一个方便的多。
提 bug 时把问题描述清楚这是很基本的要求啊。省去了沟通的成本。有些情况是只有在特定情况特定平台才出现的问题。
回到这个问题。我觉得 Color.WHITE 这样做也没什么问题。比如我代码就是想判断颜色是否是 Color.WHITE，每次 new 个对象出来也不合理啊。目前的这个设计可以根据自己的需求决定是要要克隆。
3赞
所以我说文化区别啊
- 明显的bug，一定要开发者提供完善信息才愿意去改bug，说实话，这种开发环境真的好安逸
- WHITE那个当然合理，所以呢？开发者的需求是合理呢？还是好用呢？
比js的undefined强就可以了 
可以麻烦举个例子吗？我相信之所以要完善信息肯定是还有双方理解不一致或者不清楚的地方。
我觉得目前的设计是让开发者有选择而不是一味克隆一个出来。可能 C# 的垃圾回收做得很好，但是对于 javascript，是能不克隆尽量不克隆。
- 比如一个promise没有返回，对就是没有resolve也没有reject，我提交pr后，追问我复现条件以及为什么会影响
- 问题就是，大部分用户要修改啊，哪怕如楼主所说，哪怕来个可变和不可变的给用户选择也好啊
有感而发~还在用雅基的软件混饭吃，希望creator更好~
我猜测他这样问不是说这个 PR 有问题，而是想测试一下是否解决了问题。这样可以加单元测试或者测试例子。在 release note 也容易把影响说得清楚些。
那你的建议是什么？
Cocos研发确实很喜欢跟人要demo，基本上每个反馈帖子下面第一句话都是要demo
有些问题，别人都把报错日志、必现方式、改进方法、后续问题都贴出来了，他们还是直接要demo，有点像机器人回复
成本转移，人少就是这样。他们没有时间去一个一个的复现，你能让他直接复现，他成本就低，就更快处理。面对那么多开发者，看了帖子，一眼觉得不可能，就不会管你了，你要么给demo要么觉得你误报。正常。
这个帖子走向渐渐变成了《jara走后的每一天》哈哈哈
感觉相比判断颜色是否为白色的对比，个人更多的是直接赋值用得多，我这没用过判断一个颜色是否为白色。另外能帮忙看看这个问题吗，demo都给出了 https://forum.cocos.org/t/topic/158577
开发效率高、符合直觉的 API 设计永远优先于性能，我觉得性能只需要做到 “有办法” 就行。
之前的设计算符合，人们普遍使用 Color.WHITE，当出现性能问题、或者高级用户就会懂得改为使用 Color.WHITE_R。
大家都觉得 new 的方式好的话，我们是可以改。不过有个问题就是，一旦改了就又破坏兼容性了。对兼容性的保证也导致了引擎的修改比较困难。
虽然需要的同学会说只要说明了就没问题，但实际遇到的情况是，只要这个修改影响到了你自己的项目，你就不会这么想了。
能理解，只希望这种技术、设计的债务会被记录好，在 4.x 的时候全部实现。
建议给typescript提交PR，让readonly定义具备传染性。无法把一个readonly值赋值给一个writable。学习rust能在编译器层面解决问题的问题就不要让这个问题暴露在运行时。
我起初用都觉得怪怪的， 因为在2.x 是用new的,类似Vec2/3，但后来我觉得这様做是为了减少垃圾回收吧， 因为如果你在运算中需要用到该静态变量来计算值， 如果是老new的方法就是每次计算完都要垃圾回收呢， 但是在2.x 年代有区分 cc.Color.WHITE 和 cc.Color.WHITE_R ，不知为何不继续用这方法
人力有限的情况下，有个 demo 我们直观能看到问题，解决问题，毕竟面对这么多开发者，如果要每个问题去沟通，复现，修复，需要花费多少时间？所以才会希望大家提问题的时候，能附上 demo 是最好的，或者描述完整能重现的步骤。
jare去哪了呀？
完全同意。
另外合理一说，Unity，还有 早于 3.0.0 版本的 cocos，为什么觉得返回一个新变量反而合理呢？
请问除了引擎有几个项目几个地方会用到 color == Color.WHITE？