Python赛跑bib扫描计时场景下time.perf_counter与datetime计算的时间值异常

• 时间采集时序完全错位：当前代码在每轮循环刚启动时，就提前采集了now_time_perf、now_time两个时间戳，但真正的冲线时刻是input()收到扫描器输入完成的瞬间——这两个时间戳是在扫描等待开始之前抓的，等扫描完成后，代码根本没有重新采集当下的时间，直接拿之前存的旧时间算差值，自然会出现“扫描Lucy时，计算出来的经过时长仅0.00001秒”的离谱偏差，完全没把input阻塞等待扫描的那段时间算进去。
• 冗余NTP请求打乱流程：每完成一次扫描就立刻发公网NTP请求，网络往返的延迟、抖动会让拿到的NTP值本身存在数百毫秒到数秒的误差，既不能作为精准参照，还额外拖慢了扫描流程的响应速度。
• 时钟混用与精度丢失问题：同时用datetime.now()（系统墙钟）和time.perf_counter()（高精度单调时钟）计算时长，两类时钟的运行节奏、受外部干扰的程度完全不同，混算必然出现偏差；同时用time.gmtime()格式化时长时，会直接丢弃毫秒级的精度，让最终显示的时间看起来和实际间隔对不上。

• 严格调整时间采集顺序：必须把时间戳采集动作放在input()拿到扫描结果的之后，因为input()是阻塞调用，返回的瞬间才是真正的扫描触发时刻，提前采集的时间完全没有参考价值。
• 选定单一计时源：赛事计时场景优先用time.perf_counter()，这是系统提供的单调递增高精度计时器，不会因为手动改系统时间、NTP对时跳变出现计时倒退的问题，精度可达微秒级，完全不需要再混用datetime.now()计算经过时长。
• NTP仅做赛前一次性同步：NTP只需要在比赛正式开赛之前，提前同步一次系统基准、标记开赛时刻即可，绝对不要在每次扫描的流程中插入公网请求。
• 自定义格式化逻辑：不使用time.gmtime()处理经过时长，直接基于计算得到的秒数拆分时、分、秒、毫秒的数值做格式化，保留赛事计时需要的毫秒精度。

修正后的可运行代码：

import time
import ntplib

# 赛前准备阶段：开赛之前完成一次NTP同步，固定开赛计时基准
ntp_client = ntplib.NTPClient()
# 标记正式开赛的单调时钟时刻，后续所有成绩都基于这个基准计算
race_start_mono = time.perf_counter()
# 可选：记录开赛的真实世界时间，方便赛后和官方计时做对时参考
start_world_time = ntp_client.request('pool.ntp.org').tx_time
print(f"比赛正式开赛时间：{time.ctime(start_world_time)}")

while True:
    # 先等待扫描器输入，收到完整扫描内容的瞬间才是真正的冲线时刻
    scan_result = input("等待号码布扫描：")
    # 拿到扫描结果的第一时间，立刻采集当前的单调时钟值
    scan_moment_mono = time.perf_counter()
    # 计算选手的净计时时长
    elapsed_total_sec = scan_moment_mono - race_start_mono

    # 手动拆分时间分量，保留毫秒精度
    hours = int(elapsed_total_sec // 3600)
    minutes = int((elapsed_total_sec % 3600) // 60)
    seconds = int(elapsed_total_sec % 60)
    millis = int((elapsed_total_sec % 1) * 1000)
    elapsed_display = f"{hours:02d}:{minutes:02d}:{seconds:02d}.{millis:03d}"

    print(f"扫描号码布：{scan_result}，净计时：{elapsed_display}")

之前运行输出里出现的偏差，本质就是采集时机错位：比如扫描Lucy的那次，代码在循环开头（离扫描触发还有5秒）就抓了时间，等扫描完成后没有重新抓时间，直接用之前的旧值算差值，才会出现计算时长几乎为0的结果，调整采集时机后，时间偏差会立刻消失。

内容的提问来源于stack exchange，提问作者David