GoLand 不识别 node_modules，因其索引仅处理 .go 文件并严格按 go.mod 确定项目边界；若搜索变慢，实为误开普通文件夹或混合项目所致。
GoLand 本身不识别 node_modules，也不默认扫描它——所以你根本不需要、也不应该在 GoLand 中配置排除 node_modules。
这是个常见误解：把 VSCode 的习惯直接套用到 GoLand 上。GoLand 是 Go 专用 IDE，它的索引和搜索机制天然绕过非 Go 目录，node_modules 根本不会被纳入语义分析或符号搜索范围。
为什么 GoLand 搜索不扫 node_modules？
GoLand 的代码理解基于 Go modules 和 AST 解析，只处理 .go 文件，并严格按 go.mod 确定项目边界。只要你的项目是标准 Go 项目（含 go.mod），node_modules 就是“不可见”的——它既不会出现在项目结构树里，也不会被 Ctrl+Shift+F 全局搜索命中，更不会拖慢索引速度。
如果你发现搜索变慢或结果里出现了 node_modules 下的文件，说明当前打开的不是 Go 项目，而是普通文件夹（File → Open 而非 File → Open Project），此时 GoLand 降级为文本编辑器，会全盘扫描所有文件。
真正该排除的 Go 构建产物目录
GoLand 项目中真正需要关注的是 Go 自身生成的中间产物，它们虽小但可能干扰搜索或占用空间：
GoLand 2026.1.1 是 2026.1 发布后的首个维护修正版本，适合已经开始体验 2026.1 新功能并希望同步补丁的开发者。它更适合用于入门项目、现有项目迁移测试和 IDE 行为验证。
-
bin/：存放go install生成的可执行文件，如gopls、mockgen -
pkg/：存放编译后的.a归档包（位于$GOPATH/pkg） -
$GOCACHE：构建对象缓存（如~/Library/Caches/go-build），体积最大，但不在项目内
这些目录无法通过 GoLand 设置“排除搜索”，因为它们本就不参与 Go 语义索引；但你可以手动清理：
go clean -cache
注意：go clean -cache 不影响 $GOPATH/pkg/mod（模块缓存），删它会导致下次 go run 重下依赖。
搜索卡顿？先检查是不是打开了错误的项目类型
如果搜索响应明显变慢，优先排查以下几点：
- 确认右下角状态栏显示 “Go Modules” 或 “gopls running”，而不是 “Plain text”
- 检查是否误将前端项目（含
node_modules+go.mod）整个作为 GoLand 项目打开——这会让 IDE 同时加载两套索引逻辑，严重拖慢性能 - 用
Ctrl+Shift+A搜 “Reload project”，强制重建 Go 索引（尤其改过go.mod后） - 关闭 Settings → Go → Build Tags & Vendoring → “Build project automatically”，避免保存即触发构建写缓存
真正的瓶颈从来不在 node_modules，而在项目结构混淆、gopls 配置不当，或误把混合项目当纯 Go 项目处理。一旦确认是 Go 项目，node_modules 就只是文件系统里的一个普通文件夹，IDE 甚至不知道它的存在。
