59.9949秒该显示59.99还是60.00？13个测试说清

一个时间戳格式化函数，看起来只是拼字符串的小活。直到某个四舍五入后的值正好跨过边界，麻烦才露头。

比如一段时长59.9949秒。如果先把它舍入到毫秒，得到59.995秒，再舍入到百分之一秒，就变成60.00；如果直接对原始小数做一次百分之一秒的舍入，结果是59.99。两个中间步骤都不神秘，分歧来自把两次量化叠在了一起。

所以真正要回答的问题不只是"打印几位小数"，而是：函数接受什么单位、舍入发生在哪一步、这个决定之后哪些不变量必须成立。

这个示例把输出单位定为整数百分秒，接口契约刻意收窄：一个公开函数只接受非负整数毫秒；另一个接受无符号ASCII十进制秒的文本，直接舍入到百分秒。两者都用四舍五入（round-half-up），并且先把总量舍入完，再拆成各个字段。

它不打开录音、不推断歌词、不修复时间轴顺序，也不校验整份歌词文档。把这条边界写清楚，小模块才容易测试，测试结果也不会被当成它根本没打算解决的问题的证据。

先定表示，再写格式化

选定的输出是方括号里的分、秒、百分秒。分钟最少两位，但不在小时处回绕；秒和百分秒因为是在舍入之后做整数除法得到的，天然落在各自区间内。这是一条示例策略，不等于所有播放器都接受任意宽的分钟字段。真实导出流程可能还要为目标端加额外限制，那些限制应该是独立的校验决定，而不是顺手借用一个时钟或日期格式化接口带来的副作用。

毫秒接口故意拒绝浮点和布尔值。在Python里布尔是整数的子类，宽泛的整数类型检查会放进一些大概率不是时长的值。这里的精确类型检查是小教学接口的策略选择；更大的应用可以接受更多数值类型，但应当写明转换和报错行为。调用方以为自己传了小数时长时，静默截断尤其糟糕——在边界上直接拒绝，比把它藏进一个看起来很像样的时间戳里要好。

先舍入总量，再拆字段

对整数毫秒，加五再整除十，就实现了非负值下的半向上规则，得到总百分秒数。用这个总数除以六千得到分钟和余数，余数再除以一百得到秒和百分秒。跨秒、跨分钟的进位已经体现在舍入后的总量里，格式化那一步不需要一堆特例修补。函数之所以短，是因为算术顺序替它干了大部分活。

十进制文本接口则不该绕道毫秒。既然目标精度已知，就只做一次量化；如果上游系统已经给出整数毫秒，那就把它当作明确的输入表示，而不是假装更早的精度还留着。

文本语法也被刻意收得比Decimal能解析的范围更小：只允许普通无符号十进制数字加可选小数部分，拒绝空白、正负号、指数写法、小数点两侧缺数字以及特殊值。这样调用方只有一个清晰的归一化边界。这不是说别的写法普遍不安全，应用有理由时当然可以支持，但那个决定应当是有意为之并被测试覆盖。

八十字符上限是这个接口的示例边界，不是对合理录音时长的估计。局部十进制上下文为乘一百之前的文本留足了精度，这一点很重要：精确解析一个长小数，并不保证后续算术会忽略当前上下文的精度。一个长输入用例专门检查预期的进位是否被保住。对生产服务来说，资源限制、目标端限制、错误如何抵达调用方，仍然需要单独评审；一个小边界加一个通过的用例，构不成安全审计。

测那些能解释设计的边界

把模块存为lrc_clock.py，测试存为同目录下的test_lrc_clock.py，在该目录运行python3 -m unittest -v。这套用例用Python标准库在本地实际跑过：13个测试方法全部通过，其中若干无效输入还带了子测试。

覆盖的场景包括：

• 零值，以及4毫秒与5毫秒之间的舍入分界；
• 994毫秒到995毫秒的跨秒进位；
• 59994毫秒到59995毫秒的跨分钟进位；
• 3599995毫秒输出为[60:00.00]，不在小时处回绕；
• 6000000毫秒输出为[100:00.00]，分钟字段变宽；
• 负数、布尔、浮点、字符串、None等被拒绝的输入类型；
• 严格十进制语法，以及59.9949与59.9950这组双重舍入对照；
• 半向上与多余前导零的处理；
• 四十位长整数部分加.995的长输入，与整数毫秒路径交叉验证。

边界测试里的期望字符串是写死的。如果调用同一个格式化辅助函数来算期望值，测试就不够独立，断言两边可能犯同一个错。长输入用例改用另一条整数毫秒路径做交叉检查，较短的十进制边界仍保留固定期望串，两种做法互补。但再多的断言，也不能让一条没写进文档的舍入规则对所有使用方都正确。

把格式化测试接到诚实的导出流程上

序列化器测得再细，歌词编辑器仍然需要人工复核：词和时序是否对应那一版录音，目标端是否认得选定的格式。这类浏览器工作区支持可编辑歌词文本、行时间戳、偏移调整、预览以及歌词或字幕导出；编辑和导出免费，自动音频处理需要已验证账号和额度，具体价格与存储条款以当前页面为准。上面这个模块是独立示例，不代表该服务如何实现导出。

把这个序列化器挡在清晰的应用边界后面：调用前先确定好时序表示，保留可编辑的源文件，让校验错误对调用方有用。不要在格式化函数里推断偏移、删除重复行或修复录音版本不匹配——那些动作需要函数并不具备的上下文。导出流程可以协调多个小部件，而不必让每个部件对所有问题负责。

最后，环境允许时，把真正导出的文件放进目标播放器或编辑器里试。检查字符、时间轴顺序和目标端期望的功能，而不是把"下载成功"当成兼容性证明。如果没法做目标端测试，就如实说明这个局限。一次舍入加边界测试带来的实际好处，是让流水线里多出一块更好理解的部件，而不是一句"歌词一定完美同步"的承诺。