Question SkinnedMeshRenderer.BakeMesh() shows split vertices at UV seams, different from the .mesh asset

I am using simplygon to export some skinnedMesh models and the mesh asset is stored as .mesh file.
When in static mode, no abnormality is observed, but when playing animation, it randomly has some gaps along the uv seams, which makes no sense, as when I export .mesh file to .fbx, I can see the mesh intact with no split vertices or gaps.

When I try to capture the mesh with animation to make more comparison, I find a strange thing:
when using SkinnedMeshRenderer.BakeMesh() to bake it into a new mesh and export it to fbx, it will show those split vertices.

That explains why with animation you can see random gaps at uv seams.

But how could the mesh baked from SkinnedMeshRenderer be different from the original .mesh file? And how to avoid this?

The 3dsMax comparison is below:

 

Vertices at UV seams are always splitted. There's no way around that. The UV coordinates are part of the vertices on the GPU. To have two or more different UV coordinates at a vertex, it has to be split. This already happens when you import your mesh and when it's uploaded to your GPU. Splitted vertices shouldn't really be an issue, you just have to make sure you move the two vertices together. We don't know how you animate your mesh. However if you imported a mesh that has an animation and bone weight on each vertex, a splitted vertex would have the same position and the same weight and therefore should move together at all times.

So maybe something is wrong with your animation?

 

The animation is based on LOD0 and the gaps/spits at uv seams are occurring on LOD1 only.
Due to the mesh assemble process being only considering original vertex, I don't know how the spit-at-uv-seam-in-GPU version could have different skinweights. Unless during this process something under the hood changes the skinweights for the spit version. Because manually, by code, I don't even think I have an approach to change skinweights for the to-be-spit-in-GPU-vertices, because they doesn't exist in the generation process via my code.