WakaTime 不统计代码执行时间，只记录编辑器内活跃编码时长；需确认文件后缀、忽略规则、CLI安装、API key配置及多根工作区的.project文件设置。
WakaTime 在 VSCode 中不统计 Python/JavaScript 执行时间？
WakaTime 本身不记录“代码执行”时长（比如 python main.py 运行了多久），它只统计「编辑器内活跃编码时间」——即你在文件中输入、删除、保存、跳转等操作的累计时长。如果你看到 Python 或 JS 文件没被计入，大概率不是语言支持问题，而是插件没识别到文件类型或项目路径被忽略。
- 确保文件有正确后缀（
.py、.js），且未被.wakatime-project或wakatime-cli的ignore规则屏蔽 - 检查 VSCode 状态栏右下角是否显示
WakaTime活动图标；若无，说明插件未激活或认证失败 - 打开命令面板（
Ctrl+Shift+P），运行WakaTime: Debug Info，确认language字段是否为预期值（如python而非plaintext）
VSCode 启用 WakaTime 后仍无数据上传？
最常见原因是本地 wakatime-cli 未正确安装或 API key 配置错误。WakaTime 插件依赖命令行工具采集行为日志，不是纯前端实现。
- 首次启用后，插件会自动下载并安装
wakatime-cli到~/.wakatime（macOS/Linux）或%USERPROFILE%\.wakatime（Windows），可手动检查该目录是否存在wakatime-cli可执行文件 - API key 必须填入
~/.wakatime.cfg的api_key字段，而非 VSCode 设置项；如果通过 VSCode 设置界面填写过，需重启编辑器并观察日志输出 - 在 VSCode 开发者工具（
Help → Toggle Developer Tools）的 Console 标签页里搜索wakatime，常见报错如command 'wakatime-cli' not found或HTTP 401，分别对应 CLI 缺失和 key 无效
如何让 WakaTime 统计终端里运行的脚本时间？
它做不到。WakaTime 不监听 shell 命令或进程生命周期，python train.py 在终端里跑 2 小时，只要你在 VSCode 里没编辑任何文件，这段时长不会计入。这是设计使然，不是配置缺陷。
- 若你真需要追踪运行耗时，应改用专用工具：Python 用
time.time()或line_profiler，Node.js 用process.uptime()，或者统一用系统级监控如time命令（time python script.py） - 有人尝试用 VSCode 的 Tasks + WakaTime 组合，但 Task 启动终端后编辑器已失去焦点，WakaTime 自动暂停计时——这属于预期行为，无法绕过
- 唯一接近的折中方案：在脚本开头加一行注释（如
# coding: wakatime-trace），然后用自定义插件监听保存事件并触发伪编辑，但稳定性差、不推荐生产使用
多根工作区（Multi-root Workspace）下统计异常？
WakaTime 对多根工作区支持有限：它按「当前活动编辑器所属文件夹」决定项目名和统计归属，不会合并多个根目录的时长，也不会自动识别 workspace-level 的 .wakatime-project。
- 每个子文件夹若想独立打标，需各自放一个
.wakatime-project文件（内容为纯文本项目名），否则全部归入默认项目（通常是第一个打开的根目录名） - 切换编辑器标签页时，如果新文件来自另一个根目录，WakaTime 会重新初始化项目上下文，可能造成短暂断点（
- 不要在 workspace 文件（
.code-workspace）里写wakatime相关配置——它完全被忽略
WakaTime 的核心价值是衡量「你花在写代码上的注意力时间」，不是「机器在跑什么」。越想让它统计执行、调试、查文档、写注释甚至摸鱼时长，越容易掉进配置陷阱。真正要警惕的，是把编辑器活跃时间直接等同于有效开发产出。
