应将秒数显式乘以1000转毫秒再传入Date，但更推荐纯数学拆解：用Math.floor(value/3600)、Math.floor((value%3600)/60)、value%60分别获取时分秒，并统一padStart(2,'0')补零。
过滤器里直接处理秒数要先转成毫秒
秒数（如 3661）不是标准时间戳，new Date(3661) 会当成毫秒处理，结果是 1970 年某个极小时间点，不是你想要的「1 小时 1 分 1 秒」。必须显式乘以 1000 才能进 Date 构造函数。
但更稳妥的做法是避开 Date，直接数学拆解——毕竟秒数本身不含日期信息，用 Date 反而引入时区和本地化干扰。
- 传入值类型必须判断：
typeof value === 'number'才按秒数处理；字符串需先parseInt() - 避免写
new Date(value * 1000).toTimeString().slice(0, 8)：iOS 下可能返回 UTC 时间，且含 AM/PM - 推荐纯计算：
Math.floor(value / 3600)得小时，Math.floor((value % 3600) / 60)得分钟，value % 60得秒
补零逻辑不能靠 toLocaleTimeString
toLocaleTimeString() 在不同平台返回格式不一致：iOS 可能带秒、Android 可能不带、H5 可能含上午/下午标识，且无法保证两位数补零。
手动拼接时，所有字段都必须强制两位：String(h).padStart(2, '0') 或 ('0' + h).slice(-2)，否则会出现 1:5:3 这种非预期格式。
- 小时可能为 0，也要补零（如
00:01:05） - 别用三元表达式
h —— 看似等价，但h是数字，'0'+h是字符串，类型混用易在后续逻辑中出错 - 最终格式统一用
HH:mm:ss，避免空格或中文冒号
过滤器里别混用时间戳和秒数逻辑
很多开发者把「后端返回的时间戳（毫秒）」和「持续时长秒数（如视频时长、倒计时剩余秒）」塞进同一个 formatTime 过滤器，结果在 iOS 上 new Date('1722841505') 解析失败，因为字符串没标准化。
要么拆成两个过滤器：formatTimestamp 和 formatSeconds；要么在函数开头加类型路由：
-
if (String(value).length === 10) value *= 1000—— 假设 10 位是秒级时间戳 else if (String(value).length —— 视为纯秒数（≤5 位，即最多约 27 小时）- 否则直接返回空或原始值，不强行解析
uni-dateformat 不适用秒数转时分秒
Date.now() 做差值计算。它不支持把 3661 这类纯秒数当持续时间处理。
如果你需要「倒计时显示」或「视频时长」这类功能，必须手写过滤器或方法，不能依赖该组件。它的 threshold 属性只控制「多久以前」的文案分级，跟时分秒格式无关。
真正容易被忽略的是：秒数转时分秒本质是单位换算，不是时间解析。拿 Date 处理它，就像用温度计量长度——能凑合，但逻辑错位，跨平台时最先暴露问题。
