所以我觉得tween.parallel是不是有点问题，要找人指点一下
上下移动时position改成y就好了，不要去控制x。
同理水平移动只控制x
你的第2个action里同时改了x, y，所以我推测你在做2.5视角的功能，自己模拟Z轴。
这种情况最好把Z上下移动和XY平面移动拆分到两个父子关系节点里，各自做action。
用runAction可以轻松实现两组动作同步并行，这个tween却无法对同一属性双重操作，这也太费劲了吧
我刚刚尝试by动作只对y轴操作 ，但是会导致to这个动作里的y轴属性无变化。。。。同一时间无法对同一属性双重操作
真是有点绕的慌
好吧，我把模拟跳跃放到z轴上操作
假如是我要实现魂斗罗里面的F子弹，这用tween来做估计也是费脑子，用runAction来组合轻松多了
只是打个比方，肯定是用cc.Animation来实现
我没有系统的学过JAVA，cocos也是才摸了几个月，源码看的太费劲了
不怕笑话，几个月前还在为let,var,this纠结，到现在还是没明白var用在哪里好，我整篇代码都没用过var
但是看别人的都是在用var
我这用的纯2d的思路，压根没用过2.5d啊。。。
我还是用runAction凑合着用吧
let和const是ES6才加入的吧，用var一般来说是因为习惯了。
我现在是 2.4.6 也遇到这个问题，我是想将一个 runAction 实现的动画采用 tween 实现，结果使用 parallel 来代替 spawn 的效果一直不对劲儿 
楼主这个代码明显是错的啊。
jump：y向下相对移动30px
move：y绝对移动向上60px
你这要能一起正常运动那真是出鬼了
刚刚简化了一下逻辑。
通过 runAction 实现，节点会先向上移动一段距离后向下移动，最终停留在 cc.v2(0, -100) 位置，有一种跳跃感：
node.runAction(
cc.spawn(
cc.moveTo(1, cc.v2(0, 100)),
cc.moveBy(4, cc.v2(0, -200)),
)
);
通过 tween 实现同样的逻辑，会直接从 cc.v2(0, 0) 的位置向下移动，最终停留在 cc.v2(0, -200) 位置：
cc.tween(node)
.parallel(
cc.tween()
.to(1, { position: cc.v2(0, 100) }),
cc.tween()
.by(4, { position: cc.v2(0, -200) }),
)
.start();
这一看就是写法不规范，你非要往反方向动一下你可以用sequence的做法。本身从逻辑上就说不通，一个要向左同时一个要向右，切两半动么？
这只是一个示例说明，实际上的需求是处理 100 个彩带在屏幕中四散飘舞后落下的效果。
通过其它方法确实可以实现（比如贝塞尔曲线），但是不可否认 runAction 可以并行地对同一个属性执行操作，而 tween 目前来看是不可以的。
现在我这边是使用了一个折中的办法，那就是在 cc.tween(0).then() 中传递 cc.spawn(…)。
刚测试了一下，实际上效果是不对的，效果不可控
代码很简单：
屏幕录制2021-10-29 下午3.19.24.zip (61.1 KB)
上下白框距离中心都是105的距离，方块宽高为10，视频中可以看见方块往上移动了一段距离但是并没有移动到上边界，也就是说moveby是被影响了的，这种不可控的方式为什么还要用呢？
通过你这边录制的视频正好能够说明这种方式是正确的。
-
moveTo的作用是在 1s 的时间内绝对向上移动 100px； -
moveBy的作用是在 4s 的时间内相对向下移动 200px；（即 1s 相对向下移动 50px）
因此，方块在前 1 秒向上移动 50px (100-50)，后 3 秒向下移动 150px，最终停留在底部白色边界处正是这段代码逻辑期望的结果，也说明这种方式是“完全可控”的。
这么说相当于还是计算成了先（-200/4）+（100/1）运动1秒，然后（-200/4）运动3秒
但是代码中并没有直观体现出这个逻辑，你这纯粹是给维护人员增加阅读难度
从代码中直观体现就是向上相对100像素然后向下绝对200像素，过程并没有体现在代码中
我在上面已经说过，这个只是一个示例，用于说明在 tween 的 parallel 中对节点的同一个属性进行修改未按预期执行，而在 cc.spawn 中进行该操作一切正常。
如果我最终需求只是简单地让节点先向上移动 50px，后向下移动 150px 我肯定不会采用这种方式。我真正实现的是类似于下图中的功能，需要在不同时间周期内同步地对节点的 position 属性做修改，以便实现彩带在屏幕内四散飞舞后落下的效果。
目前的情况是通过 runAction 可以正常实现需求，但是控制台说明这种方式将被 tween 替代，但是移植过程中发现 tween 的 parallel 未按预期执行，这与“给维护人员增加阅读难度”无关。 
如果是真的按运动流程来写，肯定是可以转换的，关键是同一时刻对同一属性做不同操作，这种阅读起来能迅速确定动画轨迹？我不信