new Vec3这个返回，一看就是会得到一个 （x, y, 0)的向量啊，z轴是0不该是正常的吗？
这里是不是该考虑使用另外的借口来设置？比如setScale(x, y)?
1赞
+1，去年我也踩了一次这个坑，排查才发现是用tween设置scale的时候z轴传0导致的点击失效
我们做2D的人没有3D大佬们思维的维度（字面意义）高啊。。。
关键这个事情一出现还特别难调试…
噼里啪啦几十几百行代码敲出来发现点击无效或者东西没了, 在回过头找还是挺麻烦的。
感觉API注释如果能够提醒一下会好很多。
可以使用 setScale(x, y)。如果传了 Vec3 的话，那只能是根据传入的参数值进行赋值了。引擎能做的可能只是加入一些在 debug 阶段打印一些 warning 信息了。
这个问题搞了我两天…当时就想爆粗. z的默认值不能是1或者不填就默认原来的值.非得是0吗
传分量有时候会很麻烦，支持传入 Vec2 的话可以不出现这种问题
这个原因是 Vec3 你传 x, y 的话，z 的默认值是 0 是合理的。Vec3 不是专门给 scale 设计的，它是个通用的数据结构。
如果是在 Node.setScale 里判断 Vec3 的值，如果传 0 就改为 1 也不是很合理：
- 可能就是想设置为 0 起到隐藏的效果
- 0 也是个合法的值，不能只针对 2D 来说它不合法它就是不合法的，毕竟 Node 也不是专门给 2D 用的。
另外就是引擎本身就有设置 x, y, z 的接口，可以用这个接口。
由于脚本语言没有函数重载机制，重载的写法已经很恶心了，再多一种类型的话会更恶心，而且还需要运行时判断，效率也有影响。
vec3强制填入xyz三个值，填不完整就报红得了，这下就不会忘了
这是一个思路。虽然我也没明白为什么之前允许参数可选，不过这样改的话又会涉及到破坏兼容性了。
自己封装一个类似于cc.v2呗，这不也快嘛
1赞
重载写法的恶心是库作者（引擎方）去承担的，但会方便用户这边的使用。
效率是有影响，但这可以看性能的影响程度做一个权衡。
如果影响大，那可以做一个 2D 兼容模式的选项，在勾选后才支持 Vec2 的传入，这样性能洁癖也可以满足。
在不勾选时，代码直接被剔除，完全不影响，就类似这个。
方便新人、2.x 用户的加入。
如果影响大，那可以做一个 2D 兼容模式的选项，在勾选后才支持 Vec2 的传入，这样性能洁癖也可以满足。
影响大不大和游戏逻辑有关，没有标准答案。做兼容模式会导致引擎设计的复杂度增加，也增加引擎的使用难度（毕竟每多个选项都是带来负担）。
因此这个接口暂时不会修改。
注释优化一下就好啦。 给用户一点提示， 比如默认值是多少，可能会影响什么的。
2赞
骑灵子大佬说的好，，
所以说，有没有一款引擎，专门开发2d游戏的
所以说，有没有一款引擎，专门开发2d游戏的
引擎现在行为肯定是正确的。
主要这个问题确实在手册和文档都没有提到, 只能遇到了再来社区查找, 这点比较麻烦。
是，我也是觉得在API提示一下足够了。这个地方做2D的确实不少人踩过这坑，而且一旦遇到真的很蒙圈。
踩过坑+1