LiftTrace v1.3.0发布：自托管健身追踪器的隐私优先实践

开源自托管应用正在成为对抗数据云端化的一股力量，健身追踪领域也不例外。LiftTrace是一款采用AGPL-3.0协议的自托管举重训练记录器，定位为Strong、Hevy、FitNotes和Jefit等商业应用的替代品。它的核心卖点非常明确：无遥测、无云同步、无外部账号，你的整个训练日志就是一个存在自己机器上的SQLite文件，整个应用打包成单个Docker容器运行。近日发布的v1.3.0版本带来了多项实用更新，也体现了这类隐私优先工具的设计哲学。

LiftTrace是什么：训练日志优先的完整方案

LiftTrace隶属于TraceApps工具家族，这个家族还包括营养管理的NutriTrace、菜谱与采购的CookTrace，以及笔记任务的NoteTrace。作为一款"训练日志优先"的应用，它的基础体验相当扎实：逐组记录重量、次数和RPE（自觉用力程度），标记热身组，组合超级组，休息计时器还能自动启动。

一个贴心的细节是，你正在填写的那一行上方会显示上次训练的数据，让你清楚知道要超越的目标。如果嫌手动输入慢，还可以直接输入或语音说出"bench 3x5 185"这样的指令。此外它内置了包含数千个动作的练习库（配图片），并提供有意义的统计分析：训练量随时间变化、单个动作进展、预估1RM、自动记录个人最佳成绩，以及一张肌肉恢复图。

对健身房场景的考量也很到位——原生Android应用支持离线记录，回到有信号处再同步，甚至可以完全本地运行而无需任何服务器。它还能从Strong、Hevy、FitNotes、Jefit和Garmin导入旧数据，并支持OIDC单点登录、多用户角色管理和完整备份。

RPE（Rate of Perceived Exertion，自觉用力程度）是力量训练中常用的主观强度量表，通常采用1-10分制（Borg RPE量表的变体），10分代表力竭。与固定百分比强度不同，RPE能动态反映当天身体状态——同样的重量在疲劳时可能是RPE 8，状态好时只有RPE 6。预估1RM（一次最大重量）则是根据多次数组合推算理论极限重量的公式，常见的有Epley公式（重量 × (1 + 次数/30)）和Brzycki公式，它让训练者无需每次真正测试极限也能追踪力量进展。这两个指标结合使用，是现代循证力量训练体系的核心数据点。

v1.3.0的核心新功能

这一版本的更新围绕真实训练场景展开，解决了此前一些结构性的局限。

单日多次训练

过去一天只能对应一次训练，现在这个限制被打破了。你可以在同一天分别记录一次举重训练和一次独立的柔韧性训练，各自单独追踪；当第二次训练创建后，界面会出现标签页切换。这对同时进行力量和活动度训练的用户是刚需。

计时组（Timed Sets）

平板支撑、悬垂、靠墙静蹲和负重行走这类动作，按持续时间而非次数来衡量才合理。新的保持计时器会先倒数进入，然后为保持时间计时并勾选完成，同时记录你的最长保持时间。更重要的是，训练计划、CSV导出以及Strong、Hevy、FitNotes、Garmin的导入器都理解这一数据类型。

进度照片

带日期的照片拥有独立页面：一条附带当天记录体重的时间线、可拖拽的两张照片对比擦除效果，以及能将整个记录以延时形式播放的滑块。iPhone的HEIC照片会在浏览器中转换，且照片文件仅提供给拥有它的账户访问。

周报与恢复图

新增了一份"值得一读"的周报：按目标完成的训练次数、组数、训练量、训练时长和记录，每项都与前一个月的周平均值对比。肌肉恢复图也按正确的身体比例重新绘制。

隐私与安全设计的取舍

LiftTrace最鲜明的立场是"绝不回传"。没有遥测、没有云同步、任何地方都没有账号绑定。这种设计对注重数据主权的用户极具吸引力，但也意味着数据备份和多设备同步的责任完全落在用户自己身上。

本版本在安全上做了实质性加固：进度照片置于认证之后提供，完整备份归档不再能通过URL直接访问，上传文件根据真实类型确定扩展名并以沙盒化内容策略提供服务。开发者还清除了本周期内涉及中高严重级别的依赖项漏洞，包括拒绝服务、验证绕过和原型污染问题。

对于希望做自动化集成的高级用户，v1.3.0提供了MCP服务器、REST API和webhooks三种接口——但它们默认全部关闭。作用域令牌可跨MCP和REST API使用，webhooks能向n8n、Home Assistant等发送签名的POST请求，无需轮询。默认关闭的设计再次体现了"安全优先"的思路。

MCP（Model Context Protocol）是Anthropic提出的一种开放协议，允许AI助手通过标准化接口读写外部应用的数据，相当于为大语言模型提供"工具插槽"。LiftTrace提供MCP服务器意味着用户可以让支持该协议的AI客户端（如Claude Desktop）直接查询训练历史、分析进展趋势，而无需手动导出数据。Webhooks是另一种集成机制：当特定事件发生时（如完成一次训练），应用主动向预设URL发送HTTP POST请求，n8n和Home Assistant等自动化平台可借此触发后续动作，比如更新日历或推送通知。原型污染（Prototype Pollution）是JavaScript特有的安全漏洞，攻击者通过篡改Object.prototype向所有对象注入恶意属性，可能导致权限绕过或代码执行，属于Node.js后端应用需要重点防范的中高危风险类别。

Docker用户必读的升级注意事项

这次升级有一个容易踩坑的破坏性变更：容器监听端口从3003改为3002，以匹配示例主机端口。如果你的compose文件映射的是"3002:3003"，需要在拉取前后将其改为"3002:3002"，否则应用将无响应。

任何直接通过旧端口访问容器的方式——同一Docker网络内的反向代理、Traefik端口标签或隧道——都需要做同样修改。好消息是主机端口不变，因此书签和Android应用的服务器地址仍然有效。自行设置PORT变量的安装不受影响。

Docker的端口映射语法为"宿主机端口:容器端口"，例如"3002:3003"表示将宿主机的3002端口流量转发到容器内部监听的3003端口。此次变更将容器内部监听端口从3003改为3002，意味着映射规则需同步更新为"3002:3002"。Traefik是一款常见的反向代理和负载均衡器，在Docker生态中通过容器标签（Labels）自动发现服务路由，若其标签中硬编码了旧容器端口，同样需要手动修正。对于使用Cloudflare Tunnel或Tailscale Funnel等隧道方案直接指向容器IP和端口的用户，端口变更同样会导致连接失败，需在隧道配置侧同步更新目标端口号。

AI在开发中的角色

值得一提的是，按照社区规则，开发者公开披露了AI在项目中的使用情况。具体分工大致是：功能实现约为人机各半，AI起草代码，开发者审查、在真实硬件上测试，只提交验证过的部分，每次提交都经过人工审查；架构决策由人主导，AI建议权衡和边界情况；文档同样约五五开；测试以真机手动为主，AI协助起草测试计划和思考边界。这种坦诚的AI使用说明，正在成为开源社区一种值得推广的透明度实践。

本次开发周期共有九位社区成员贡献了代码、详细的Bug报告和功能建议，所有人都在发布说明中被署名。这也是开源项目健康运转的一个缩影。