根本原因是lsp-bash仅是客户端，未安装配置bash-language-server；需npm全局安装、正确设置command路径与selector为source.shell.bash，并解决source文件索引限制及shellcheck冲突问题。
为什么装了LSP-bash还是没提示？
根本原因是LSP-bash本身不自带语言服务器，它只是个客户端插件，必须手动安装并配置 bash-language-server 才能工作。只通过Package Control装上 LSP-bash 插件，编辑器会安静得像没装过——没有报错，也没有补全、跳转或诊断。
常见错误现象包括：LSP: bash 状态栏始终显示“starting…”或直接不出现；Ctrl+Click 无法跳转函数定义；输入 echo $ 后无变量名提示。
- 确认已用 npm 全局安装服务端：
npm install -g bash-language-server - 若使用 nvm 或自定义 Node.js 版本，确保 Sublime Text 启动时能读取到对应
PATH（macOS/Linux 下推荐从终端执行subl启动） - Windows 用户注意：npm 安装路径需加入系统环境变量，且 Sublime Text 必须以能继承该环境的方式启动（避免双击桌面图标）
LSP-bash 配置文件怎么写才生效？
Sublime Text 的 LSP 插件要求每个语言单独配置，LSP-bash 不会自动识别 .bashrc 或 /bin/bash 路径。你必须在 LSP.sublime-settings 中显式指定 bash-language-server 的可执行路径和初始化选项。
典型配置示例（放在 "clients": { ... } 内）：
"bash": {
"command": ["bash-language-server", "start"],
"selector": "source.shell.bash",
"enabled": true,
"settings": {
"bash.suggestSnippets": true,
"bash.format.enable": true
}
}
-
"selector"必须为source.shell.bash（不是source.bash或shell-script），否则 LSP 不会绑定到 .sh 文件 - 如果
bash-language-server不在PATH中，"command"要写绝对路径，例如["/usr/local/bin/bash-language-server", "start"] -
"settings"里的选项实际由服务端解析，不是所有字段都支持；bash.suggestSnippets在较新版本中才有效，旧版会静默忽略
Shell 脚本里 source 的文件为啥不被索引？
LSP-bash 默认只分析当前打开的文件，不会递归解析 source 或 . 引入的脚本，所以跨文件的函数跳转和变量提示基本失效。这不是配置错误，而是服务端设计限制。
- 临时解决办法：把被
source的文件也同时在 Sublime Text 中打开（哪怕最小化），服务端会将其纳入语义分析范围 - 更可靠的做法是统一项目结构，用
#!/usr/bin/env bash开头，并把公共库放在固定路径（如lib/），然后在 LSP 配置中通过"initializationOptions"传入{"includePaths": ["./lib"]}（需服务端 v1.12+ 支持） - 注意：LSP-bash 对数组、关联数组、间接变量（
${!var}）等 Bash 4+ 特性支持有限，提示可能缺失或误报，别依赖它检查语法正确性
和 ShellCheck 冲突怎么办？
很多人同时装了 SublimeLinter-contrib-shellcheck 和 LSP-bash，结果发现诊断重复、高亮打架，甚至光标卡顿。这是因为两者都监听文件变化并上报问题，但底层机制不同：ShellCheck 是静态扫描，LSP-bash 是基于 AST 的实时分析。
- 优先保留 LSP-bash：它提供补全、跳转、重命名等 IDE 功能，而 ShellCheck 只做 lint —— 若只需语法检查，关掉
SublimeLinter更轻量 - 如必须共存，可在
SublimeLinter.sublime-settings中禁用 shellcheck 的 auto-lint："lint_mode": "manual"，或限定只对保存时触发 - 性能敏感时，关闭 LSP-bash 的实时格式化（设
"bash.format.enable": false），它在大脚本里容易引发延迟
真正麻烦的不是装不上，而是装完以为好了，结果在写 for file in ${files[@]}; do 时补全不出数组元素——那多半是服务端没跑起来，或者 source 路径根本没被看到。
