Trunk插件不会自动运行检查，需手动配置"trunk.runOnSave": true才能保存时执行check；依赖.trunk/trunk.yaml存在且正确配置工具，否则静默失败；多根工作区仅识别首个文件夹的配置。
Trunk 插件在 VSCode 里根本不会自动运行检查
装完插件不等于代码一保存就标红——Trunk 默认不监听文件保存事件，也不会在编辑时实时 lint。它只响应你手动触发的命令，比如右键菜单里的 Trunk: Run Check 或终端里敲 trunk check。
- 必须手动配置
"trunk.runOnSave": true才能在保存时自动执行（但注意：这仅对当前工作区生效，且只跑check，不包括fmt或test） - 如果项目根目录没有
.trunk/trunk.yaml，插件会静默失败，VSCode 底部状态栏可能只显示 “Trunk: Not initialized”，但不会弹报错 -
trunk.yaml里没启用某个 linter（比如没把eslint加进tools列表），就算本地装了 ESLint，插件也完全无视它
“Trunk: Install Tools” 按钮点完没反应？大概率是权限或路径问题
VSCode 插件调用 trunk install 时，依赖系统 PATH 中的 trunk CLI。但它不会帮你装 Rust、Node.js 或 Python 运行时——这些得自己配好。
- Windows 用户常见卡点：
trunk安装后默认在%USERPROFILE%\.trunk\bin，这个路径没加进系统 PATH，VSCode（尤其从开始菜单启动时）根本找不到命令 - macOS / Linux 下如果用
curl装的 trunk，记得chmod +x，否则插件执行时会报Permission denied - 插件调用
trunk install时，会读取当前工作区的.trunk/trunk.yaml决定装哪些工具；如果该文件不存在或格式错误，按钮点击后控制台可能只输出空行，毫无提示
VSCode 显示的诊断信息来自 trunk 的缓存层，不是实时重跑结果
Trunk 为了性能，默认复用上一次 check 的结果（类似增量分析）。你在 VSCode 里改了代码，但诊断没更新，不一定是插件坏了，而是 trunk 认为“这次改动不影响已检查过的文件块”。
- 强制刷新诊断：按
Ctrl+Shift+P（Win/Linux）或Cmd+Shift+P（macOS），输入并执行Trunk: Clear Cache and Run Check - 某些 linter（如
prettier）被 trunk 封装后，错误位置可能偏移 1–2 行——这不是 VSCode 渲染问题，是 trunk 传递diagnostic时对原始输出做了归一化处理 - 如果某个文件明明有错却没标红，先确认该文件是否在
trunk.yaml的include列表里；默认只检查src/和tests/，config/或scripts/下的 JS 文件常被漏掉
多根工作区下，Trunk 插件只认最外层 .trunk 目录
VSCode 打开一个含多个文件夹的工作区（Multi-root Workspace），Trunk 插件只会加载第一个文件夹根目录下的 .trunk/trunk.yaml，其他文件夹里的配置完全被忽略。
- 即使第二个文件夹里有独立的
.trunk/trunk.yaml，插件也不会切换上下文去读它——它没有 workspace-aware 的配置路由逻辑 - 临时解法：把所有子项目的
.trunk配置合并到主工作区根目录，用repos字段分组管理不同路径的规则 - 更稳的做法：放弃多根工作区，改用单独窗口打开各项目；或者用
trunk check --repo=xxx在终端手动指定作用域
Trunk 的核心复杂点不在安装，而在于它把一堆工具的生命周期、版本隔离、配置拼接全包进一个 YAML 里——你看到的“一键集成”，背后是每个 linter 的二进制路径、参数透传、输出解析规则都得对得上。稍微改个 tool.version 或删掉一行 args，诊断就可能消失，而且没有任何明确报错告诉你哪错了。
