先说几个核心判断：Snyk插件在VSCode里不自动跑snyk test，这其实是设计如此，不是Bug。插件默认走的是「被动监听」模式——你不动它，它就不动。只有当你手动点击“Scan Project”、打开问题面板，或者把snyk.autoScanOnOpen设为true（默认是false）时，它才会乖乖去扫一遍。而且它背后依赖的是本地CLI的登录状态、能否正常访问Snyk的API，以及项目根目录下有没有package.json——缺了任何一个，插件都静默跳过，连个提示都不给。
VSCode里装Snyk插件后，为什么snyk test不自动跑？
说白了，插件只负责「监听」，不是每次保存都触发扫描。它只在特定动作下才拉取最新漏洞数据——比如你手动点一下“Scan Project”，或者打开问题面板。而这一切的前提是：本地CLI已经登录，并且能连通snyk.io的API。
实操建议：
- 先在终端里跑一遍
snyk auth，完成GitHub登录。插件底层调用的就是同一套CLI凭据，终端能跑通，插件才能用。 - 检查VSCode设置里
snyk.autoScanOnOpen是否开启——默认是false，改成true后，打开工作区时才会自动扫一次。 - 注意：插件不会监控
package.json的变更。改完依赖后，必须手动点右下角的“Snyk: Rescan”按钮，否则新引入包的漏洞不会刷新。 - 项目根目录下没有
package.json或node_modules？插件会直接静默跳过，不报错，不提示。
Node版本不匹配导致snyk test失败怎么办？
Snyk CLI本身是Node.js工具，扫描目标项目时，它会尝试复用项目本地的Node版本来解析依赖树。如果你用nvm管理多版本，而VSCode启动时没加载对应的shell配置，就可能拿错Node版本——结果就是snyk test报错Cannot find module 'semver'，或者卡在resolving dependencies...上不动。
实操建议：
- 在VSCode终端里先跑
which node和node -v，确认和项目里的.nvmrc或.tool-versions一致。 - Mac/Linux用户：在VSCode的
settings.json里加一行"terminal.integrated.env.osx": { "PATH": "/opt/homebrew/bin:/usr/local/bin:${env:PATH}" }，确保能读到nvm的初始化脚本。 - Windows用户：建议改用
corepack替代nvm。它通过package.json#engines自动匹配Node版本，Snyk兼容性更好。 - 临时绕过方案：在项目根目录下执行
npm install --no-sa ve snyk@latest，然后用npx snyk test——这样可以避免全局CLI和项目Node版本冲突。
扫描结果里一堆transitive dependency漏洞，该修哪个？
90%的高危漏洞都藏在传递依赖里。举个例子：你只装了lodash，但真正出问题的是它依赖的lodash.template 4.5.0——这个版本根本不在你的package.json里，没法直接npm install升级。怎么办？
实操建议：
- 优先处理标记为
Direct dependency的条目。这些是你能够控制的入口点，升级它们往往能顺带修复下游的漏洞。比如把axios从0.21.x升到1.6.0+，可能会替换掉有漏洞的follow-redirects。 - 对于纯
transitive漏洞，别急着用resolutions强制覆盖——很多包的resolutions在pnpm/yarn v4下会失效，反而导致安装失败。 - 用
snyk wizard（在终端里运行）比插件UI更靠谱。它会逐个询问你是否升级、是否忽略，并生成可提交的snyk-policy.json。 - 真正棘手的是那些已被上游废弃、无维护者的子依赖（比如
debug@2.6.9）。这时候只能靠pnpm overrides或yarn set version berry+resolutions来锁死补丁版，别指望Snyk能自动修复。
CI/CD里怎么让Snyk扫描不阻塞构建？
本地扫描可以忽略中低危漏洞，但CI里常常要求“零高危”。如果直接用snyk test --fail-on=high，一个未及时修复的间接漏洞就会让整条流水线挂掉，尤其在PR阶段，很影响协作节奏。
实操建议：
- 区分场景：PR环境用
snyk test --severity-threshold=high --policy-path=.snyk，允许开发者基于已有策略临时豁免；主干分支用--fail-on=high强制拦截。 .snyk文件必须提交进仓库，否则CI里snyk test会按默认策略走，和本地行为不一致。- 避免在Docker构建阶段重复扫描。Node.js镜像里装Snyk CLI再执行
snyk test会严重拖慢构建，建议改为在npm ci之后、npm run build之前单独起一个job。 - 注意缓存：Snyk默认每小时查一次远程漏洞库。CI里可以加
--offline参数跳过网络请求，前提是本地有缓存（需要提前运行snyk monitor）。
需要警惕的是：Snyk插件在VSCode里显示的漏洞等级（low/medium/high/critical），和你在CLI里看到的可能不一致。原因在于插件默认同时开启了“Snyk Code”（静态分析）和“Snyk Open Source”（依赖扫描）双引擎，而CLI默认只开后者。如果你没买企业版，插件里部分high级漏洞其实是误报。得切到Terminal里用snyk test --json | jq '.vulnerabilities[] | select(.severity=="high")'看原始字段才能确认。
