关键帧清理后时间不准是因帧率推算与吸附干扰所致，需关闭Snap to Frame、手动输入精确秒值、确保总时长≥循环需求、校准系统时间、严格核对首尾帧数值一致性。
关键帧清理后时间标尺显示帧数不准，先关吸附再手动输秒值
不是时间轴“坏了”，而是清理操作（比如删掉中间帧）后，Composer 仍按原始帧率推算总时长，而 UI 默认开启 Snap to Frame，导致你拖动或点击生成的新关键帧自动对齐到最近整数帧——比如你想设在 2.0s，它实际存成 1.998s，回放时就差一帧。必须关闭吸附，改用输入框精确控制。
- 右键时间轴 → 取消勾选
Snap to Frame（或按Ctrl+Shift+S切换） - 双击关键帧下方的时间数字区域，直接输入带一位小数的值，如
0.0、2.0、4.0，回车确认 - 不要依赖拖动或鼠标滚轮微调，它们受吸附和缩放比例影响，精度不可控
导出前总时长必须 ≥ 循环段 × 次数，否则末尾硬跳
清理关键帧常伴随删减片段，但 Composer 不会自动延长时间轴。若你保留了 0.0–3.0s 的循环段，想重复 3 次，时间轴终点却停在 8.9s，导出时最后一段会被截断，播放器直接跳回第 0 帧——看起来像“帧数少了一帧”。
- 手动拖动时间轴滑块到末尾，看右下角显示的总时长数值
- 若小于目标值（如
9.0），按End键跳到最后，再拖动时间滑块向右拉伸，直到显示 ≥9.0 - 拉伸后记得检查关键帧是否仍在原位：有时拉伸会意外移动关键帧，需逐帧确认
系统时间不同步会导致关键帧时间戳漂移
你在 WSL2、Docker 或 CI 环境中编辑过文件，或从另一台机器拷贝过项目，就可能触发这个隐藏问题。Composer 读取的是文件的 filemtime()，一旦宿主机与虚拟环境系统时间偏差超 60 秒，它会错乱解析关键帧先后顺序，表现为时间轴上帧位置随机偏移、首尾帧对不齐。
- WSL2 中运行：
sudo hwclock --hctosys同步一次硬件时间 - Docker 启动时加挂载：
-v /etc/localtime:/etc/localtime:ro - GitHub Actions 等 CI 脚本开头加：
sleep 2 && timedatectl timesync-status，等 NTP 就绪再执行后续命令
清理后首尾帧数值必须严格相等，不能只看UI显示
时间标尺对齐了，关键帧也打在 0.0 和 9.0，但循环仍卡顿？大概率是首帧 RotationZ 是 0.0，末帧显示 360° 实际存的是 360.001。Composer 不做浮点归一化，差 0.001 就会插值出一个微小位移，叠加循环就变明显顿挫。
- 双击每个关键帧，打开属性面板，逐项核对
PositionX、RotationZ、ScaleY等字段 - 手动输入
0.0或360.0并回车，别信界面上显示的“约等于”值 - 尤其注意 Digger 关键帧：它只记录开关状态，不记录角度/深度，清完后务必重设开/关动作本身，而非反复点关键帧按钮
