herolulu it could be that even if you copied all keys from one animation, when pasting it into another the movement is still incorrect. This could be caused by keys absent in your first animation but present in the next one. To ensure that what you paste looks exactly the same in the target animation there are a couple of ways:

A brutal one that creates many extra keys consists in selecting all the bones then pressing CTRL+L (CMD on mac) to key all of their transforms. You would then need to clean up the animations to remove the unnecessary keys.

A second method that only adds the keys necessary in the second animation consists in copying all of the frames from the first animation, then in the second animation pushing the already present keys forward so that there's enough room at the beginning to accomodate all of the first animation keys.
Paste the first animation keys, then press the spacebar to deselect and make the whole dopesheet visible,
now you can create the missing keys by pressing CTRL+SHIFT+L (CMD on mac).
With all the necessary keys in place, you can select the frames that belong to the first animation, cut them, (you can also undo after copying) then paste them at the desired point of the animation once its original timingis restored.

http://esotericsoftware.com/spine-cheat-sheet

herolulu Okay, so see the videos below. The copy-and-paste should have been done in the following way (To make the problem easier to understand, I reproduced the problem with an animation leaving only the path position animation.):

To fix this, delete the middle key and double the value of the last key to the original value:

The reason for doubling the value of the last key is that if the original value is left unchanged, it would take twice as long to reach the specified path position. (This is the state shown at 0:02-0:06 in the video above.) To make it move at the same speed, we need to double the value.

For a closed path, changing the path position from 0 to 100 means that the constrained bones will move along the path. So if we think in terms of the constrained bones' coordinates, their coordinates at path position 0 and at path position 100 will be the same. However, the value that the path position keys have is different, and this is what we need to be aware of when copying and pasting the key.

Next, let's look at how to set the path position to 100 at frame 59.99 and back to 0 at frame 60. To set the key at frame 59.99, either hold the SHIFT key and move the timeline bar to set the key there, or use the Current field of the Dopesheet view to move the timeline bar to frame 59.99. In the following video, I used the former approach. I then selected the key at frame 59.99 and switched the curve to stepped.:

If you copy and paste this animation to repeat it, there is no need to modify the path position values after pasting:

For your information, a frame like 59.99 is called a fractional frame. This is explained on the Keys page of the User Guide: https://zh.esotericsoftware.com/spine-keys#%E5%B8%A7%E5%AF%B9%E9%BD%90

herolulu I am glad the videos were helpful!

As for how to invert the entire animation, this can be accomplished by performing a box selection of keys in the dopesheet view and scaling them. Scaling can be used to reverse the order of the keys by moving the left edge past the right, or the right edge past the left. See the User Guide for instructions on how to make box selections:
https://zh.esotericsoftware.com/spine-dopesheet#%E6%A1%86%E9%80%89

Incidentally, if the animation is to be played using the Spine runtime, you can specify reverse playback via the code for playing the animation. See the API reference if you are interested:
https://esotericsoftware.com/spine-api-reference#TrackEntry-reverse

herolulu Oh, when doing box selection and inverting, be aware of the fact that if you have not held down the Shift key, the keys on the fractional frames will be placed on the integer frames, and the key may disappear if the near integer frames have keys. On the other hand, if you do it with the Shift key pressed, the operation is a little more difficult because the frame you want to place on the integer frame is not properly aligned with the integer frame. A feature that would make it easier to invert the animation might be something we could consider. I will think about how best to add this.

herolulu Hmm, I checked the Spine project, but I can offset the zuoxiaobi bone's timeline and the mesh shapes seen in the viewport seem to match at frame 0 and at the last frame, so I'm not sure what the problem is. If you have sorted out the constraints so that it works, could you please show me the project where the problem occurs?

By the way, if you send us a Spine project that is too complicated, it tends to be unclear where to look, so it would be helpful if you could send us a project with only the parts that cause problems and remove the rest.

herolulu Thanks for submitting the simplified Spine project! It seems that the rotation keys for bone84, bone85 and bone86 do not match in frame 0 and the last frame:

Did you filter the rotation timeline? When you filter the timeline of a particular transformation in the Dopesheet or Graph view, you may think you have selected all the keys, but you have not. If you can think of any reason for this confusion, please let us know for our reference.

herolulu Hmm, that's weird. As far as I have tested, I have been able to match the rotation values of the first and last keys by copying and pasting the keys:

So I am not sure what the actual cause of the problem is. However, I noticed that while the offset button is enabled, even if you select the white key in the overview row, you cannot select the keys in all the timelines of the same frame, so I thought that might be the reason why you thought you had selected all the keys, but actually hadn't:

In the video above, you can see that when the offset button is disabled, selecting the white key in the overview row selects keys in all rows, but when it is enabled, only the key of the top bone is selected. This has always been the case, so it's not a bug, it's design, but I thought it might cause confusion when trying to copy keys.

Could you please try again to see if you can copy and paste the keys correctly?

herolulu Hmm, I'm not sure I fully understand the content of your question, but is it correct to say that you are asking where you can check the correct scale when importing a skeleton that has been exported once? If the skeleton's texture was scaled when exporting, the scale information is saved in the atlas file.

If you set the scale based on this value when importing the skeleton data, you can set the correct size for all the attachments at once without having to manually modify the size of each attachment:

The following blog post, which explains how to import skeleton data, also explains this, so you may find it helpful:
Blog 导入骨架数据 #疑难解答 - 为何有些部分比正确尺寸小或大？