最近在整理跑步和骑行数据时我在一份设备导出的训练记录里看到了两个很显眼的值2.88 split和31.21 mph。前者对应某个分段用时后者是速度。第一次看到时确实愣了一下因为 GPS 数据里常出现“分段时间”“英里/小时”“公里/小时”“配速”这些混合单位如果不做一次清洗和换算很难判断这段表现到底属于什么水平。于是我用 Python 写了一个小工具专门用来处理类似的运动指标。本文会从基础概念讲起逐步完成一个可复现的“配速与速度换算器”。无论你是刚开始跑马拉松、做骑行数据分析还是打算把运动数据导出后进行二次开发这篇教程都可以作为入手参考。1. 背景与核心概念1.1 Split、Speed、Pace 分别是什么在跑步和骑行语境中几个指标经常容易被混淆。split分段成绩。比如跑 10 公里时手表往往会把每 1 公里或每 1 英里的用时拆出来记录这段用时就是 split。它本质上是一个时间值而不是速度值。speed瞬时速度或平均速度常用单位是 mph英里/小时或 km/h公里/小时。pace配速表示完成单位距离需要多少时间比如“5 分 30 秒 / 公里”。配速越低速度越快。很多国内跑步爱好者习惯使用“公里配速”而国际平台或部分运动设备默认输出“英里配速”和“mph”。所以当我们拿到一条原始记录看到2.88 split或者看到31.21 mph第一步不要急着判断成绩而是先弄清楚数值的单位和含义。1.2 为什么要对运动指标做换算不同运动 App、手表品牌、骑行码表之间的数据格式并不统一。同样是速度有的记为km/h有的记为mph同样是配速有的显示为min/km有的显示为sec/100m还有的用min/mile。如果只是单次阅读手工换算倒不算麻烦。但当你需要做多日训练量统计、周跑量分析、骑行强度对比甚至把几十条 CSV 记录合并到一张表里时单位不统一就会导致计算失败、图表异常、排行错误。从程序员的视角看这类运动数据本质上是一份“带单位的多维时序数据”。解析、清洗、统一单位和日常处理订单数据、日志数据的过程非常相似。区别在于运动数据经常需要处理时间字符串和速度字符串的嵌套格式例如02:52.8、31.21mph、530\/km。1.3 本文要完成的任务本文不会只停留在数学公式层面而是使用一个具体的数据场景某条训练记录中出现了2.88 split同一条记录还包含了31.21 mph我们需要把 split 理解为分段用时2.88 分钟然后把该分段的速度换算成公制单位并估算该分段的距离最后输出一份标准化的结果并完成简单的可视化代码采用 Python 3 编写不依赖复杂框架。只要安装了 Python 环境就能直接运行。2. 环境准备与项目结构2.1 运行环境说明本文示例采用 Python 3。由于运动数据的解析经常涉及时间与单位转换推荐 Python 3.8 及以上版本。如果需要绘图会用到matplotlib。如果暂时没有安装也可以跳过绘图部分。示例项目目录结构如下training_data/ ├── analyze_split.py ├── sample_data.py └── requirements.txt其中sample_data.py定义原始数据。analyze_split.py是主程序负责解析和换算。requirements.txt记录依赖。建议在项目目录下新建虚拟环境python -m venv venv然后激活虚拟环境。Windows 下使用venv\Scripts\activatemacOS / Linux 下使用source venv/bin/activate2.2 requirements.txtmatplotlib3.5如果你的 Python 环境安装较慢可以使用国内镜像源pip install -r requirements.txt -i https://pypi.tuna.tsinghua.edu.cn/simple2.3 原始数据描述我设计了一份简化训练日志。假设设备导出的数据中包含以下关键字段字段名示例值含义record_time2026-01-15 18:30:00记录时间split_value2.88分段用时split_unitmin分段时间单位speed_value31.21速度数值speed_unitmph速度单位初始化几个测试记录# 文件路径sample_data.py raw_records [ { record_time: 2026-01-15 18:30:00, split_value: 2.88, split_unit: min, speed_value: 31.21, speed_unit: mph, note: 示例记录2.88 split 与 31.21 mph }, { record_time: 2026-01-16 07:00:00, split_value: 4.50, split_unit: min, speed_value: 26.72, speed_unit: mph, note: 另一条骑行记录 }, { record_time: 2026-01-17 19:20:00, split_value: 1.80, split_unit: min, speed_value: 40.10, speed_unit: km/h, note: 配速换算测试记录 } ]这里有一个地方需要特别说明2.88 split如果按照分段时间来理解就是 2.88 分钟等价于 2 分 52.8 秒。如果设备显示为2.88而没带单位也可能代表其他含义。所以数据清洗阶段的第一步就是确认每一个字段的单位。3. 核心换算公式与设计思路3.1 英里制与公制的转换mph是 miles per hour即每小时运行的英里数。公制速度常用km/h或m/s。换算关系如下1 mile 1.60934 km 1 km 0.621371 mile所以kmh mph * 1.60934 mph kmh / 1.609341 mph 换算成 m/s 为1 mph 0.44704 m/s这个常数在很多运动算法库中都会用到。3.2 速度与配速的关系速度是“单位时间行驶的距离”配速是“单位距离花费的时间”。如果速度单位为 km/h则每公里配速的小时数为hour_per_km 1 / speed_kmh把小时换算成分钟min_per_km 60 / speed_kmh例如31.21 mph换算成 km/h31.21 * 1.60934 50.23 km/h那么每公里配速60 / 50.23 1.194 分钟/公里约等于1 分 11.6 秒 / 公里。3.3 分段用时、速度与距离的关系如果设分段用时为t平均速度为v分段距离为d则d v * t需要注意的是单位必须对齐。如果速度是 km/h那么时间就要用小时如果速度是 m/s那么时间就要用秒。回到原始样例split 2.88 分钟 2.88 * 60 172.8 秒 speed 31.21 mph 13.95 m/s理论上这段距离为172.8 * 13.95 2410 米也就是约 2.41 公里。这个数字听起来可能有些奇怪因为普通人不可能以 31.21 mph 连续跑 2.4 公里。所以这类数据更可能来自骑行、轮滑或者设备在高速运动状态下记录的分段。这也说明我们写代码时不能先入为主地把所有运动数据都看作跑步数据。3.4 设计一个可靠的换算器我的设计目标不是写一个只能处理两个数字的一次性脚本而是做一个可以扩展的小换算器输入任意速度值输入任意配速字符串如5:30 /km、8:00 /mi、2.88min、31.21mph输出 m/s、km/h、mph、min/km、min/mile以及对应的人类可读时间格式把这些换算能力封装成类后续接入 Excel、CSV、Web API 都方便。4. 完整实战实现配速与速度标准化工具接下来进入核心实战环节。我会先给出完整代码再逐段解释。4.1 定义换算常量与核心数据结构# 文件路径analyze_split.py MILE_TO_KM 1.60934 KM_TO_MILE 1 / MILE_TO_KM MPH_TO_MPS 0.44704 MPS_TO_KMH 3.6 def mph_to_kmh(mph): return mph * MILE_TO_KM def mph_to_mps(mph): return mph * MPH_TO_MPS def kmh_to_mph(kmh): return kmh / MILE_TO_KM def kmh_to_mps(kmh): return kmh / MPS_TO_KMH def mps_to_kmh(mps): return mps * MPS_TO_KMH def mps_to_mph(mps): return mps / MPH_TO_MPS这些代码很简单关键是不要把单位系数记错。常用的两个坑m/s换算成km/h是乘以 3.6不是除以 3.6。km/h换算成mph是除以 1.60934不是乘以 1.60934。4.2 配速格式化与解析配速的表示方式多种多样5:30 /km表示每公里 5 分 30 秒800\/mi表示每英里 8 分 00 秒2.88 min表示分段用时 2.88 分钟因此解析器要能识别不同分隔符。import re def parse_pace_string(pace_text): if not pace_text: return None pace_text pace_text.strip().lower() # 支持 5:30 /km 和 800/mi m re.search(r(\d):(\d), pace_text) if m: minutes int(m.group(1)) seconds int(m.group(2)) total_seconds minutes * 60 seconds return total_seconds / 60 # 返回 分钟每单位距离 # 支持 2.88min m re.search(r([\d.])\s*min, pace_text) if m: return float(m.group(1)) # 支持 71.6s m re.search(r([\d.])\s*s, pace_text) if m: return float(m.group(1)) / 60 return None def pace_min_to_text(pace_min): total_seconds int(round(pace_min * 60)) minute total_seconds // 60 second total_seconds % 60 return f{minute:02d}:{second:02d} /unit这里解释一下代码逻辑parse_pace_string尝试从文本中提取数字和单位。如果找到mm:ss格式统一换算为分钟的浮点数。如果找到min直接取分钟数。如果找到s换算为分钟。为了不让函数猜测距离单位我把“/km”或“/mi”留在外面处理。后续可以通过参数指定目标单位。4.3 标准化一条原始记录假设输入格式为字典。标准化流程如下判断速度字段的单位转换为 m/s 作为中间标准。判断 split 字段和时间单位。计算对应的公里配速和英里配速。输出可读的结论。def normalize_speed_to_mps(speed_value, speed_unit): unit speed_unit.strip().lower() if unit in (mph, mi/h, mile/hour): return mph_to_mps(float(speed_value)) elif unit in (kmh, km/h, kph): return kmh_to_mps(float(speed_value)) elif unit in (m/s, mps): return float(speed_value) else: raise ValueError(f不支持的速度单位: {unit}) def speed_mps_to_pace_min_per_km(mps): # 配速 时间 / 距离 # 1 km 的用时是多少分钟 if mps 0: raise ValueError(速度必须大于 0) return 1.0 / (mps * 1000 / 60) def speed_mps_to_pace_min_per_mile(mps): if mps 0: raise ValueError(速度必须大于 0) return 1.60934 / (mps * 1000 / 60)这里的核心逻辑是速度 m/s * 1000 每秒毫米数错了需要注意单位。更准确的方法是m/s 乘以 1000 得到 mm/s这是不合适的。正确换算应该是当速度为v m/s时行驶 1 km 需要的秒数为1000 / v 秒所以每公里配速为1000 / v / 60 分钟同理行驶 1 英里需要1609.34 / v 秒所以每英里配速为1609.34 / v / 60 分钟修改上面的函数def speed_mps_to_pace_min_per_km(mps): if mps 0: raise ValueError(速度必须大于 0) return (1000 / mps) / 60 def speed_mps_to_pace_min_per_mile(mps): if mps 0: raise ValueError(速度必须大于 0) return (1609.34 / mps) / 60这样代码在数学上才是准确的。4.4 根据 split 和速度估算距离下面处理最开始提出的问题已知split 2.88 分钟平均速度是31.21 mph估算本分段的距离。def infer_distance_from_split(split_minutes, speed_mps): if speed_mps 0 or split_minutes 0: return 0.0 seconds split_minutes * 60 dist_m seconds * speed_mps return dist_m def infer_distance_from_split_km(split_minutes, speed_mps): return infer_distance_from_split(split_minutes, speed_mps) / 1000.0 def infer_distance_from_split_mile(split_minutes, speed_mps): return infer_distance_from_split(split_minutes, speed_mps) / 1609.34这样一个函数就完成了距离估算。注意这个结果依赖一个假设即这段时间内速度保持稳定。对于真实运动场景如果存在大量爬升、停车、转弯平均速度只能作为估算参考。4.5 主流程有了基础函数后定义主流程函数统一处理一条原始记录。def process_one_record(record): split_value float(record[split_value]) split_unit record[split_unit].strip().lower() speed_value float(record[speed_value]) speed_unit record[speed_unit].strip().lower() if split_unit in (min, minute, m): split_minutes split_value elif split_unit in (sec, second, s): split_minutes split_value / 60 else: raise ValueError(f不支持的分段时间单位: {split_unit}) speed_mps normalize_speed_to_mps(speed_value, speed_unit) speed_kmh mps_to_kmh(speed_mps) speed_mph mps_to_mph(speed_mps) pace_km speed_mps_to_pace_min_per_km(speed_mps) pace_mile speed_mps_to_pace_min_per_mile(speed_mps) dist_km infer_distance_from_split_km(split_minutes, speed_mps) dist_mile infer_distance_from_split_mile(split_minutes, speed_mps) return { 原始记录: record, split(分钟): round(split_minutes, 2), 速度(m/s): round(speed_mps, 2), 速度(km/h): round(speed_kmh, 2), 速度(mph): round(speed_mph, 2), 配速(分钟/公里): round(pace_km, 2), 配速(分钟/英里): round(pace_mile, 2), 估算距离(km): round(dist_km, 2), 估算距离(mile): round(dist_mile, 2), }可能你已经注意到了我在函数里以m/s作为中间标准单位。这种设计的好处是无论原始单位是 mph 还是 km/h最后都先统一到 m/s后续计算配速和距离时只需要一套数学公式不会因为单位分支太多而混乱4.6 增加简单输出辅助为了便于在命令行直接观察我新增一个输出函数def format_result(analysis): r analysis note r[原始记录].get(note, ) print( * 60) print(记录说明:, note) print(f分段用时: {r[split(分钟)]} 分钟) print(f速度: {r[速度(m/s)]} m/s {r[速度(km/h)]} km/h {r[速度(mph)]} mph) print(f每公里配速: {r[配速(分钟/公里)]} 分钟/公里) print(f每英里配速: {r[配速(分钟/英里)]} 分钟/英里) print(f估算距离: {r[估算距离(km)]} km {r[估算距离(mile)]} mile) print( * 60)然后加上主程序入口if __name__ __main__: from sample_data import raw_records for record in raw_records: output process_one_record(record) format_result(output)运行命令python analyze_split.py预期输出大致如下 记录说明: 示例记录2.88 split 与 31.21 mph 分段用时: 2.88 分钟 速度: 13.95 m/s 50.23 km/h 31.21 mph 每公里配速: 1.19 分钟/公里 每英里配速: 1.92 分钟/英里 估算距离: 2.41 km 1.5 mile 这证明从31.21 mph和2.88 分钟推算出的分段距离大约是 2.41 公里反过来也说明这两个指标是可以在同一路段中共存的只要运动场景允许那么高的平均速度。4.7 绘图把多个记录可视化如果安装了 matplotlib我们可以画一张简单的柱状图对比不同记录的速度和距离。# 文件路径analyze_split.py 中追加绘图函数 import matplotlib.pyplot as plt def plot_analysis(analyses): labels [] speeds_kmh [] distances_km [] for item in analyses: label item[原始记录].get(note, ) if len(label) 12: label label[:12] ... labels.append(label) speeds_kmh.append(item[速度(km/h)]) distances_km.append(item[估算距离(km)]) fig, ax1 plt.subplots(figsize(9, 5)) color tab:red ax1.bar(labels, speeds_kmh, colorcolor, alpha0.6, label速度(km/h)) ax1.set_ylabel(速度(km/h), colorcolor) ax1.tick_params(axisy, labelcolorcolor) ax2 ax1.twinx() color tab:blue ax2.plot(labels, distances_km, colorcolor, markero, label估算距离(km)) ax2.set_ylabel(估算距离(km), colorcolor) ax2.tick_params(axisy, labelcolorcolor) fig.tight_layout() plt.title(运动分段数据分析) plt.xticks(rotation15) plt.show() if __name__ __main__: from sample_data import raw_records analyses [] for record in raw_records: output process_one_record(record) format_result(output) analyses.append(output) plot_analysis(analyses)绘图时使用双 Y 轴的原因很简单速度和距离的范围差异很大。如果共用同一个 Y 轴距离较小的柱状图可能看不清楚。左侧轴展示速度右侧轴展示距离更直观。5. 常见问题与排查思路在运动数据的解析和换算过程中新手最容易遇到以下几类问题。问题现象常见原因解决思路把 mph 当成 km/h导致速度被高估 60% 以上设备默认单位设置不同进入设置确认单位程序解析时统一转 m/s2.88被当成秒而不是分钟split 字段单位缺失检查导出文件头优先约定单位为分钟或秒2:88时间字符串解析失败时间格式不合法分钟超过 59使用正则解析时增加范围校验计算出的配速过大或为 0速度传成了秒速或英里/秒统一中间单位为 m/s再做配速计算估距距离过长或过短平均速度假设不成立结合海拔、停顿、分段方式进行校正Excel 中数据变成科学计数法数值单位格式问题使用Decimal或格式化字符串5.12:88字符串能直接解析吗不能。标准的mm:ss格式中秒数应该在 0 到 59 之间。2:88很可能是设备显示异常或格式化误差。另一种可能它想表达的是 2 分钟 88 秒也就是 3 分 28 秒而不是 2 分 88 秒。推荐做法def parse_mmss_to_seconds(text): parts text.strip().split(:) if len(parts) ! 2: raise ValueError(时间格式应为 mm:ss) minutes int(parts[0]) seconds int(parts[1]) if not (0 seconds 60): seconds int(seconds) extra_minutes seconds // 60 seconds seconds % 60 minutes extra_minutes return minutes * 60 seconds这种宽容解析并不适合所有场景但在整理训练日志时比较实用。5.2 如何防止单位歧义最安全的方案是在程序入口处就规范化所有字段。例如validated_record { split_seconds: 172.8, speed_mps: 13.95, }内部完全不保留2.88 split这样的自由文本。原始自由文本只用于展示不用于计算。5.3 为什么同一份数据在不同 App 里显示不同除了单位问题还有一个常见原因是“平均速度”的计算窗口不同。手表记录的是瞬时速度的算术平均。有的平台使用“移动平均”不计算红灯或暂停时间。有的平台使用“滑动平均”每 10 秒采样一次。因此当你说“我这段速度是 31.21 mph”时如果没有说明算法口径别人很难完全复现。程序中我统一以总量法和采样记录平均法做对比避免直接透露单个设备实现。5.4 数据合法性与隐私提醒如果你准备分析手表、码表或手机导出的运动轨迹请确保数据来自本人或已获得授权。运动数据涉及位置轨迹、健康状态、作息规律等隐私信息在公开代码、上传 GitHub、或者分享给第三方平台时务必删除定位点、具体住宅地址、可识别个人信息并开启“模糊化起点”等隐私选项。涉及安全、权限和数据脱敏的项目应严格遵循最小授权原则。6. 最佳实践与工程建议6.1 使用统一中间单位在编写运动数据换算代码时我建议避开“到处都写 unit 判断”的写法。更合理的模式是原始输入 - 中间标准单位 - 任意输出单位这就像系统时间存储统一用 UTC展示时再转本地时间一样。速度统一转为m/s距离统一转为m时间统一转为s或min这样所有业务计算都基于固定单位后续扩展新格式时只需新增一层“解析器”。6.2 用数据类组织记录如果项目稍大建议使用 Pythondataclasses而不是普通字典。from dataclasses import dataclass dataclass class SplitRecord: split_seconds: float speed_mps: float record_time: str source_unit: str property def distance_m(self) - float: return self.split_seconds * self.speed_mps property def speed_kmh(self) - float: return self.speed_mps * 3.6 property def pace_min_km(self) - float: return (1000 / self.speed_mps) / 60这里把“没有单位的数值”与“单位信息”统一封装进一个对象中业务函数调用record.distance_m即可不需要反复读取字典键。6.3 处理边界条件一个健壮的运动数据工具至少需要考虑以下边界情况速度为 0 时计算配速会除零。分段用时为 0 时距离结果为 0。速度字符串中包含空格、全角字符、小写字母。某些平台导出31.21mi/h而不是31.21mph。某些数据中split单位可能是km表示分段距离而不是时间。因此在解析函数开头就做类型检查、单位白名单检查能节省很多排错时间。6.4 可测试性建议为换算器补充基础单元测试。即使不引入pytest使用标准库unittest也很方便import unittest class TestConverter(unittest.TestCase): def test_mph_to_kmh(self): self.assertAlmostEqual(mph_to_kmh(31.21), 50.23, places2) def test_speed_to_pace_km(self): mps mph_to_mps(31.21) pace speed_mps_to_pace_min_per_km(mps) self.assertAlmostEqual(pace, 1.19, places2) if __name__ __main__: unittest.main()在重构代码时这种测试能保证你不会在无意中把单位转换写反。6.5 数据可视化建议可视化运动数据时需要注意不要用折线图表示类别数据。配速升高代表速度降低轴方向可以考虑反向。如果展示分段用时Y 轴越小越好不需要强制从 0 开始。交互式图表中鼠标悬停务必显示原始单位避免误导。图表标题中要写清楚是跑步、骑行还是综合数据因为不同运动速度差异很大。这段内容以两个示例数值为引子但最终目标不是去解释“2.88 和 31.21 mph 谁更快”而是建立一套可以复用、扩展、排错的处理流程。你可以把案例替换成自己跑步记录里的任意配速也可以用同样的逻辑处理地铁运行区间、物流车辆轨迹、自行车骑行数据。核心是理解时间、距离、速度三者的关系以及在软件工程中如何对待单位不一致的问题。接下来的练习方向也很明确把代码接入 CSV 文件、生成自动日报、增加海拔爬升分析或者做一个简单的 Web API 查询接口。动手跑一遍代码后你对运动数据的理解会比只看教程深入得多。