FastF1 v2.1.1 实时时序数据记录与回放Live Timing Data 完整实战指南【免费下载链接】Fast-F1FastF1 is a python package for accessing and analyzing Formula 1 results, schedules, timing data and telemetry项目地址: https://gitcode.com/GitHub_Trending/fa/Fast-F1FastF1 v2.1.1 引入了两项影响深远的能力一是可以在比赛进行时通过 SignalR 协议记录 F1 官方实时时序数据流二是在赛后把这份本地记录作为数据源回放让那些赛后无法通过 API 获取的数据得以分析与使用。与此同时本版本还包含一个需要注意的破坏性变更Session.load_laps默认不再加载遥测数据。本文以 v2.1.1 变更记录docs/changelog/v2.1.1.rst为骨架结合 docs/api_reference/livetiming.rst 的用法文档与fastf1/livetiming/模块源码完整讲解记录、回放、认证、缓存与排障的每一个环节。一、v2.1.1 核心变更总览v2.1.1 版本记录的核心内容可归纳为三部分变更类型内容影响新功能支持记录record实时时序数据比赛中通过 SignalR 客户端把官方流保存为本地文本文件新功能支持使用use已记录的实时时序数据作为数据源赛后通过LiveTimingData对象把本地记录喂给Session.load潜在破坏性变更fastf1.Session.load_laps默认不再加载遥测数据仅加载时序数据需显式要求才会读取遥测调用方式需相应调整官方给出的变更说明docs/changelog/v2.1.1.rst非常简练但背后对应着一整套fastf1/livetiming/模块客户端、数据解析、命令行入口以及Session.load的livedata参数链路fastf1/core.py。下面逐一展开。二、为什么要自己记录实时时序数据F1 官方在比赛期间通过 SignalR 协议wss://livetiming.formula1.com/signalrcore实时推送时序数据。这些数据的特点是只在直播窗口内可得部分时序数据如逐圈TimingData、车队/车手信息、实时位置流在赛后可能无法从普通 API 完整获取或获取范围受限内容远超赛后静态结果实时流中包含了TimingAppData、TrackStatus、SessionStatus、WeatherData、RaceControlMessages、Position.z、CarData.z、LapCount、TopThree等二十余类主题覆盖比赛进程的几乎全部动态细节。因此在比赛进行时把它记录下来相当于拥有了与比赛同步的原始数据底稿赛后即可离线回放。FastF1 v2.1.1 提供的正是这条记录 → 回放的完整链路F1 官方实时流(SignalR) │ SignalRClient 订阅并落盘 ▼ 本地文本文件原始消息 │ LiveTimingData 解析 ▼ Session.load(livedata...) → 时序/遥测/圈速等数据模块的类注释也明确说明记录的数据不能用于实时处理只能在赛后通过Session.load配合LiveTimingData对象回放见 fastf1/livetiming/client.py。前置条件实时时序数据属于 F1TV 付费权益。使用该功能需要有效的 F1TV Access/Pro/Premium 订阅FastF1 会在未登录时引导你完成账户认证认证细节见 fastf1/internals/f1auth.py。另外由于登录方式依赖本地回调实时时序客户端无法在 Google Colab 这类托管环境或 WebAssemblyJupyter Lite环境中使用。三、记录实时时序数据SignalR 客户端记录功能由fastf1.livetiming.client.SignalRClient实现fastf1/livetiming/client.py。它有两种使用方式命令行与 Python 脚本。3.1 方式一命令行记录推荐模块提供了命令行入口python -m fastf1.livetiming解析逻辑见 fastf1/livetiming/main.pypython -m fastf1.livetiming save saved_data.txt执行后客户端会连接官方流、订阅全部主题并把数据持续写入saved_data.txt直到超时或手动中断CtrlC为止。3.2 方式二Python 脚本记录在脚本中创建SignalRClient实例并调用start()from fastf1.livetiming.client import SignalRClient client SignalRClient(filenamesaved_data.txt) client.start()3.3 参数说明SignalRClient的完整参数及语义如下与 docs/api_reference/livetiming.rst 及源码 docstring 一致参数默认值说明filename必填输出文件路径filemodeww覆盖写入a追加写入。会话中途重启客户端时用追加模式很有用debugFalse原用于保存完整 SignalR 消息而非仅数据部分。注意从当前仓库源码看该模式已被移除传入debugTrue会直接抛出ValueError(Debug mode is no longer supported.)fastf1/livetiming/client.pytimeout60连续多少秒收不到数据则自动退出设为0可禁用超时loggerNone默认错误输出到控制台可传入logging.Logger自定义日志no_authFalse设为True时尝试免认证连接但可能只对部分会话有效或只能拿到空/不完整数据命令行对应关系usage: python -m fastf1.livetiming save [-h] [--append] [--debug] [--timeout TIMEOUT] file positional arguments: file 输出文件名 optional arguments: -h, --help 显示帮助并退出 --append 追加到输出文件默认覆盖已存在文件 --debug 启用调试模式保存完整 SignalR 消息而非仅数据 --timeout TIMEOUT 收不到数据后自动退出的超时秒数默认 603.4 底层工作原理从源码fastf1/livetiming/client.py可以看清客户端的关键调用链预协商Pre-negotiate_run()首先向https://livetiming.formula1.com/signalrcore/negotiate发起OPTIONS请求拿到AWSALBCORSCookie 并写入请求头fastf1/livetiming/client.py建立连接通过HubConnectionBuilder构建 SignalR Core 连接access_token_factory指向认证函数get_auth_tokenno_authTrue时为None并注册on_open/on_close/on(feed, ...)回调fastf1/livetiming/client.py订阅主题连接建立后发送Subscribe消息订阅列表包含Heartbeat、DriverList、TimingData、CarData.z、Position.z、TrackStatus、WeatherData、SessionStatus、LapCount、TopThree等 21 个主题fastf1/livetiming/client.py落盘每条消息经_on_message序列化后写入文件并立即flush()fastf1/livetiming/client.py监督退出_supervise()每秒检查一次最近收到消息的时间超过timeout即告警并自动关闭连接fastf1/livetiming/client.py。需要注意当前仓库源码中async_start()已不再提供会抛出NotImplementedError因为客户端不再基于 asyncio统一使用同步的.start()fastf1/livetiming/client.py。四、把已记录数据用作数据源LiveTimingData记录完成后数据默认以原始文本形式保存每行一个 JSON 数组元素形如[TimingAppData, {...}, 2021-03-27T12:00:32.086Z]分别对应分类名、消息体、UTC 时间戳。要回放它需要借助fastf1.livetiming.data.LiveTimingDatafastf1/livetiming/data.py。4.1 基本用法import fastf1 from fastf1.livetiming.data import LiveTimingData livedata LiveTimingData(saved_data.txt) session fastf1.get_testing_session(2021, 1, 1) session.load(livedatalivedata)Session.load的livedata关键字参数会贯穿整条加载链路_load_session_info、_load_drivers_results、_load_session_status_data、_load_total_lap_count、_load_track_status_data、_load_laps_data、_load_telemetry、_load_weather_data、_load_race_control_messages等全部数据加载方法都接受并透传该对象见 fastf1/core.py。也就是说只要传入livedata时序数据、圈速、遥测若可用、天气、赛道状态、比赛控制消息等都可以从本地记录解析而不是请求赛后 API。4.2 多文件与重叠去重如果一次录制被拆成了多个文件例如因断连而分两次录制可以直接传入多个文件名文件需按时间先后顺序排列livedata LiveTimingData(saved_data_1.txt, saved_data_2.txt)多个文件之间允许重叠load()在解析时会加载当前文件 下一个文件首行遇到与下一文件首行相同的行即停止解析当前文件从而自动识别并去除重叠区间的重复数据fastf1/livetiming/data.py。这个行为有专门测试验证test_duplicate_removal构造了两个内容完全相同的临时文件加载后断言数据量只有 1 份fastf1/tests/test_livetiming.py。早期版本的remove_duplicates参数已废弃——重复数据现在总是会被移除传入该参数只会触发警告fastf1/livetiming/data.py。4.3 底层解析逻辑LiveTimingData内部做了三件关键的事时间基准校准解析首个文件时先扫描内容寻找SessionStatus中状态为Started的消息以其Utc时间作为会话开始时间_start_date随后所有消息时间都转换为相对会话开始的timedeltafastf1/livetiming/data.py。若找不到Started记录则退而使用第一条数据的时间戳作为基准非标准 JSON 修复F1 官方推送的数据不是严格 JSON使用单引号、True/False字面量解析前会统一替换为合法 JSON→、True→true、False→falsefastf1/livetiming/data.py按分类归档解析后的[时间增量, 消息体]按分类名存入self.data字典fastf1/livetiming/data.py并提供get(name)、has(name)、list_categories()三个查询接口——首次调用时自动触发load()因此会有一次性的解析耗时fastf1/livetiming/data.py。即使文件中混入大量坏数据也不会崩溃test_file_loading_w_errors专门用带大量错误行的参考数据验证了解析的健壮性fastf1/tests/test_livetiming.py参考数据位于 fastf1/testing/reference_data/livedata/。五、破坏性变更load_laps 默认不再加载遥测v2.1.1 明确指出一个可能破坏现有代码的变更fastf1.Session.load_laps数据现在默认在不加载遥测的情况下载入即只加载时序数据。遥测数据通常本来也不可用因此这可以避免一个令人困惑的错误。也就是说在 v2.1.1 及之后调用load_laps()时不会再顺带拉取每圈的遥测数据。如果你的分析流程依赖Lap.telemetry之类的字段需要显式开启遥测加载而不能假设load_laps会自动带出。顺带一提Session.load本身仍然支持灵活的按需加载开关laps / telemetry / weather / messages并可配合livedata同时指定本地数据源fastf1/core.py。在回放录制数据时建议显式指定所需数据种类避免加载不必要的部分拖慢首次解析。六、实战注意事项官方经验总结在正式投入录制前请记住以下来自官方文档docs/api_reference/livetiming.rst的硬性建议尽量录制完整会话录制可能需要提前到比赛开始前 1 小时启动才能覆盖全部数据。如果会话开头缺失API 解析器可能无法正确处理数据——缺多少、缺什么将直接影响可用性不要混用数据源同一场比赛不要既用录制数据又用赛后 API 数据两者时间基准可能无法正确对齐一定要启用缓存录制数据配合缓存可以大幅加快第二次及之后的加载速度fastf1.Cache.enable_cache(path/to/cache/directory)同一场比赛的不同数据源必须使用不同缓存目录缓存无法区分数据来源。如果同一场比赛已有 API 数据缓存就不会自动用录制数据重新加载。修改输入源后还需强制刷新缓存一次fastf1.Cache.enable_cache(path/to/cache/directory, force_renewTrue)注意force_renewTrue只需要在修改输入例如新增了第二个录制文件后执行一次连接约 2 小时后会被服务器断开官方流似乎会在录制约 2 小时后主动终止连接。若不想有录制空洞需要在断开前手动启动第二次录制并使用不同的输出文件名。之后把文件按时间顺序传入LiveTimingData即可重叠部分会被自动去重。七、认证流程与限制实时时序数据需要 F1TV 订阅认证。认证实现在 fastf1/internals/f1auth.py 中流程大致是客户端在本地启动一个临时 HTTP 服务并打印一个登录链接f1login.fastf1.dev?portport用户在浏览器中完成 F1TV 账户登录回调把subscriptionToken写回本地服务FastF1 通过jwt库、以 JWKS 公钥https://api.formula1.com/static/jwks.json校验令牌签名RS256校验通过的令牌会被持久化到平台用户数据目录下的f1auth.json后续直接复用令牌失效时会提示重新认证。因此该登录方式依赖本地起服务 浏览器跳转这决定了它无法在 Google Colab、Jupyter Lite 等托管/WebAssembly 环境中运行只适合在本地开发机上使用。八、如何验证与继续深入阅读模块文档docs/api_reference/livetiming.rst 是这份功能的完整使用手册阅读源码fastf1/livetiming/client.py客户端、fastf1/livetiming/data.py数据对象、fastf1/livetiming/main.pyCLI 入口运行测试仓库内置了录制数据的解析与回放测试可直接执行验证pytest fastf1/tests/test_livetiming.py测试用参考数据位于 fastf1/testing/reference_data/livedata/其中2021_1_FP3.txt是一份真实格式的录制样例with_errors.txt用于验证容错性若要了解认证细节见 fastf1/internals/f1auth.py 及文档 docs/api_reference/accounts_auth.rst。结语v2.1.1 是 FastF1 数据能力的一次重要补全它把只有直播时才能看到的官方时序流变成了可保存、可离线回放的本地资产同时通过load_laps默认行为的调整让圈速数据的加载更符合直觉、避免无意义的遥测请求报错。只要遵循完整录制、分开缓存、按时间序传文件这三条原则你就能稳定地把任何一场比赛的实时时序数据完整归档并在赛后用 FastF1 的完整分析管线任意挖掘。【免费下载链接】Fast-F1FastF1 is a python package for accessing and analyzing Formula 1 results, schedules, timing data and telemetry项目地址: https://gitcode.com/GitHub_Trending/fa/Fast-F1创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
FastF1 v2.1.1 实时时序数据记录与回放：Live Timing Data 完整实战指南
FastF1 v2.1.1 实时时序数据记录与回放Live Timing Data 完整实战指南【免费下载链接】Fast-F1FastF1 is a python package for accessing and analyzing Formula 1 results, schedules, timing data and telemetry项目地址: https://gitcode.com/GitHub_Trending/fa/Fast-F1FastF1 v2.1.1 引入了两项影响深远的能力一是可以在比赛进行时通过 SignalR 协议记录 F1 官方实时时序数据流二是在赛后把这份本地记录作为数据源回放让那些赛后无法通过 API 获取的数据得以分析与使用。与此同时本版本还包含一个需要注意的破坏性变更Session.load_laps默认不再加载遥测数据。本文以 v2.1.1 变更记录docs/changelog/v2.1.1.rst为骨架结合 docs/api_reference/livetiming.rst 的用法文档与fastf1/livetiming/模块源码完整讲解记录、回放、认证、缓存与排障的每一个环节。一、v2.1.1 核心变更总览v2.1.1 版本记录的核心内容可归纳为三部分变更类型内容影响新功能支持记录record实时时序数据比赛中通过 SignalR 客户端把官方流保存为本地文本文件新功能支持使用use已记录的实时时序数据作为数据源赛后通过LiveTimingData对象把本地记录喂给Session.load潜在破坏性变更fastf1.Session.load_laps默认不再加载遥测数据仅加载时序数据需显式要求才会读取遥测调用方式需相应调整官方给出的变更说明docs/changelog/v2.1.1.rst非常简练但背后对应着一整套fastf1/livetiming/模块客户端、数据解析、命令行入口以及Session.load的livedata参数链路fastf1/core.py。下面逐一展开。二、为什么要自己记录实时时序数据F1 官方在比赛期间通过 SignalR 协议wss://livetiming.formula1.com/signalrcore实时推送时序数据。这些数据的特点是只在直播窗口内可得部分时序数据如逐圈TimingData、车队/车手信息、实时位置流在赛后可能无法从普通 API 完整获取或获取范围受限内容远超赛后静态结果实时流中包含了TimingAppData、TrackStatus、SessionStatus、WeatherData、RaceControlMessages、Position.z、CarData.z、LapCount、TopThree等二十余类主题覆盖比赛进程的几乎全部动态细节。因此在比赛进行时把它记录下来相当于拥有了与比赛同步的原始数据底稿赛后即可离线回放。FastF1 v2.1.1 提供的正是这条记录 → 回放的完整链路F1 官方实时流(SignalR) │ SignalRClient 订阅并落盘 ▼ 本地文本文件原始消息 │ LiveTimingData 解析 ▼ Session.load(livedata...) → 时序/遥测/圈速等数据模块的类注释也明确说明记录的数据不能用于实时处理只能在赛后通过Session.load配合LiveTimingData对象回放见 fastf1/livetiming/client.py。前置条件实时时序数据属于 F1TV 付费权益。使用该功能需要有效的 F1TV Access/Pro/Premium 订阅FastF1 会在未登录时引导你完成账户认证认证细节见 fastf1/internals/f1auth.py。另外由于登录方式依赖本地回调实时时序客户端无法在 Google Colab 这类托管环境或 WebAssemblyJupyter Lite环境中使用。三、记录实时时序数据SignalR 客户端记录功能由fastf1.livetiming.client.SignalRClient实现fastf1/livetiming/client.py。它有两种使用方式命令行与 Python 脚本。3.1 方式一命令行记录推荐模块提供了命令行入口python -m fastf1.livetiming解析逻辑见 fastf1/livetiming/main.pypython -m fastf1.livetiming save saved_data.txt执行后客户端会连接官方流、订阅全部主题并把数据持续写入saved_data.txt直到超时或手动中断CtrlC为止。3.2 方式二Python 脚本记录在脚本中创建SignalRClient实例并调用start()from fastf1.livetiming.client import SignalRClient client SignalRClient(filenamesaved_data.txt) client.start()3.3 参数说明SignalRClient的完整参数及语义如下与 docs/api_reference/livetiming.rst 及源码 docstring 一致参数默认值说明filename必填输出文件路径filemodeww覆盖写入a追加写入。会话中途重启客户端时用追加模式很有用debugFalse原用于保存完整 SignalR 消息而非仅数据部分。注意从当前仓库源码看该模式已被移除传入debugTrue会直接抛出ValueError(Debug mode is no longer supported.)fastf1/livetiming/client.pytimeout60连续多少秒收不到数据则自动退出设为0可禁用超时loggerNone默认错误输出到控制台可传入logging.Logger自定义日志no_authFalse设为True时尝试免认证连接但可能只对部分会话有效或只能拿到空/不完整数据命令行对应关系usage: python -m fastf1.livetiming save [-h] [--append] [--debug] [--timeout TIMEOUT] file positional arguments: file 输出文件名 optional arguments: -h, --help 显示帮助并退出 --append 追加到输出文件默认覆盖已存在文件 --debug 启用调试模式保存完整 SignalR 消息而非仅数据 --timeout TIMEOUT 收不到数据后自动退出的超时秒数默认 603.4 底层工作原理从源码fastf1/livetiming/client.py可以看清客户端的关键调用链预协商Pre-negotiate_run()首先向https://livetiming.formula1.com/signalrcore/negotiate发起OPTIONS请求拿到AWSALBCORSCookie 并写入请求头fastf1/livetiming/client.py建立连接通过HubConnectionBuilder构建 SignalR Core 连接access_token_factory指向认证函数get_auth_tokenno_authTrue时为None并注册on_open/on_close/on(feed, ...)回调fastf1/livetiming/client.py订阅主题连接建立后发送Subscribe消息订阅列表包含Heartbeat、DriverList、TimingData、CarData.z、Position.z、TrackStatus、WeatherData、SessionStatus、LapCount、TopThree等 21 个主题fastf1/livetiming/client.py落盘每条消息经_on_message序列化后写入文件并立即flush()fastf1/livetiming/client.py监督退出_supervise()每秒检查一次最近收到消息的时间超过timeout即告警并自动关闭连接fastf1/livetiming/client.py。需要注意当前仓库源码中async_start()已不再提供会抛出NotImplementedError因为客户端不再基于 asyncio统一使用同步的.start()fastf1/livetiming/client.py。四、把已记录数据用作数据源LiveTimingData记录完成后数据默认以原始文本形式保存每行一个 JSON 数组元素形如[TimingAppData, {...}, 2021-03-27T12:00:32.086Z]分别对应分类名、消息体、UTC 时间戳。要回放它需要借助fastf1.livetiming.data.LiveTimingDatafastf1/livetiming/data.py。4.1 基本用法import fastf1 from fastf1.livetiming.data import LiveTimingData livedata LiveTimingData(saved_data.txt) session fastf1.get_testing_session(2021, 1, 1) session.load(livedatalivedata)Session.load的livedata关键字参数会贯穿整条加载链路_load_session_info、_load_drivers_results、_load_session_status_data、_load_total_lap_count、_load_track_status_data、_load_laps_data、_load_telemetry、_load_weather_data、_load_race_control_messages等全部数据加载方法都接受并透传该对象见 fastf1/core.py。也就是说只要传入livedata时序数据、圈速、遥测若可用、天气、赛道状态、比赛控制消息等都可以从本地记录解析而不是请求赛后 API。4.2 多文件与重叠去重如果一次录制被拆成了多个文件例如因断连而分两次录制可以直接传入多个文件名文件需按时间先后顺序排列livedata LiveTimingData(saved_data_1.txt, saved_data_2.txt)多个文件之间允许重叠load()在解析时会加载当前文件 下一个文件首行遇到与下一文件首行相同的行即停止解析当前文件从而自动识别并去除重叠区间的重复数据fastf1/livetiming/data.py。这个行为有专门测试验证test_duplicate_removal构造了两个内容完全相同的临时文件加载后断言数据量只有 1 份fastf1/tests/test_livetiming.py。早期版本的remove_duplicates参数已废弃——重复数据现在总是会被移除传入该参数只会触发警告fastf1/livetiming/data.py。4.3 底层解析逻辑LiveTimingData内部做了三件关键的事时间基准校准解析首个文件时先扫描内容寻找SessionStatus中状态为Started的消息以其Utc时间作为会话开始时间_start_date随后所有消息时间都转换为相对会话开始的timedeltafastf1/livetiming/data.py。若找不到Started记录则退而使用第一条数据的时间戳作为基准非标准 JSON 修复F1 官方推送的数据不是严格 JSON使用单引号、True/False字面量解析前会统一替换为合法 JSON→、True→true、False→falsefastf1/livetiming/data.py按分类归档解析后的[时间增量, 消息体]按分类名存入self.data字典fastf1/livetiming/data.py并提供get(name)、has(name)、list_categories()三个查询接口——首次调用时自动触发load()因此会有一次性的解析耗时fastf1/livetiming/data.py。即使文件中混入大量坏数据也不会崩溃test_file_loading_w_errors专门用带大量错误行的参考数据验证了解析的健壮性fastf1/tests/test_livetiming.py参考数据位于 fastf1/testing/reference_data/livedata/。五、破坏性变更load_laps 默认不再加载遥测v2.1.1 明确指出一个可能破坏现有代码的变更fastf1.Session.load_laps数据现在默认在不加载遥测的情况下载入即只加载时序数据。遥测数据通常本来也不可用因此这可以避免一个令人困惑的错误。也就是说在 v2.1.1 及之后调用load_laps()时不会再顺带拉取每圈的遥测数据。如果你的分析流程依赖Lap.telemetry之类的字段需要显式开启遥测加载而不能假设load_laps会自动带出。顺带一提Session.load本身仍然支持灵活的按需加载开关laps / telemetry / weather / messages并可配合livedata同时指定本地数据源fastf1/core.py。在回放录制数据时建议显式指定所需数据种类避免加载不必要的部分拖慢首次解析。六、实战注意事项官方经验总结在正式投入录制前请记住以下来自官方文档docs/api_reference/livetiming.rst的硬性建议尽量录制完整会话录制可能需要提前到比赛开始前 1 小时启动才能覆盖全部数据。如果会话开头缺失API 解析器可能无法正确处理数据——缺多少、缺什么将直接影响可用性不要混用数据源同一场比赛不要既用录制数据又用赛后 API 数据两者时间基准可能无法正确对齐一定要启用缓存录制数据配合缓存可以大幅加快第二次及之后的加载速度fastf1.Cache.enable_cache(path/to/cache/directory)同一场比赛的不同数据源必须使用不同缓存目录缓存无法区分数据来源。如果同一场比赛已有 API 数据缓存就不会自动用录制数据重新加载。修改输入源后还需强制刷新缓存一次fastf1.Cache.enable_cache(path/to/cache/directory, force_renewTrue)注意force_renewTrue只需要在修改输入例如新增了第二个录制文件后执行一次连接约 2 小时后会被服务器断开官方流似乎会在录制约 2 小时后主动终止连接。若不想有录制空洞需要在断开前手动启动第二次录制并使用不同的输出文件名。之后把文件按时间顺序传入LiveTimingData即可重叠部分会被自动去重。七、认证流程与限制实时时序数据需要 F1TV 订阅认证。认证实现在 fastf1/internals/f1auth.py 中流程大致是客户端在本地启动一个临时 HTTP 服务并打印一个登录链接f1login.fastf1.dev?portport用户在浏览器中完成 F1TV 账户登录回调把subscriptionToken写回本地服务FastF1 通过jwt库、以 JWKS 公钥https://api.formula1.com/static/jwks.json校验令牌签名RS256校验通过的令牌会被持久化到平台用户数据目录下的f1auth.json后续直接复用令牌失效时会提示重新认证。因此该登录方式依赖本地起服务 浏览器跳转这决定了它无法在 Google Colab、Jupyter Lite 等托管/WebAssembly 环境中运行只适合在本地开发机上使用。八、如何验证与继续深入阅读模块文档docs/api_reference/livetiming.rst 是这份功能的完整使用手册阅读源码fastf1/livetiming/client.py客户端、fastf1/livetiming/data.py数据对象、fastf1/livetiming/main.pyCLI 入口运行测试仓库内置了录制数据的解析与回放测试可直接执行验证pytest fastf1/tests/test_livetiming.py测试用参考数据位于 fastf1/testing/reference_data/livedata/其中2021_1_FP3.txt是一份真实格式的录制样例with_errors.txt用于验证容错性若要了解认证细节见 fastf1/internals/f1auth.py 及文档 docs/api_reference/accounts_auth.rst。结语v2.1.1 是 FastF1 数据能力的一次重要补全它把只有直播时才能看到的官方时序流变成了可保存、可离线回放的本地资产同时通过load_laps默认行为的调整让圈速数据的加载更符合直觉、避免无意义的遥测请求报错。只要遵循完整录制、分开缓存、按时间序传文件这三条原则你就能稳定地把任何一场比赛的实时时序数据完整归档并在赛后用 FastF1 的完整分析管线任意挖掘。【免费下载链接】Fast-F1FastF1 is a python package for accessing and analyzing Formula 1 results, schedules, timing data and telemetry项目地址: https://gitcode.com/GitHub_Trending/fa/Fast-F1创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考