bash-completion 的补全能细到什么程度，说到底并不是靠某个统一参数来“总控”，而是由每条命令对应的补全函数自己决定。补得到多深、多准，主要看这几个层面：有没有调用 _filedir、_command 这类辅助函数，是否设置了 COMP_WORDBREAKS 等上下文变量，以及对当前语义上下文究竟能解析到什么程度。
bash-completion 的补全深度由什么控制？
补全到底能“补到多深”，并不存在一个统一的“联想词深度”参数来一把梭地控制，真正拍板的是每条命令各自对应的补全函数。举个很直观的例子，git 的补全可以一路细到子命令层面，比如 git checkout 会直接把分支列表抛出来；但 ls 默认通常只补路径，不会顺手把文件类型过滤也展开。这里面的差别，说到底还是补全脚本本身怎么写：有没有调用 _filedir、_command 这类底层辅助函数，以及有没有结合 COMP_WORDBREAKS、COMP_LINE 这类上下文变量来判断当前该怎么补。
如何修改特定命令（如 conda）的补全行为？
以 conda 为例，它的补全逻辑由 conda shell completions bash 生成，但默认不包含“深度联想”（比如输入 conda activate py 不会自动过滤出所有含 py 的环境名）。要增强它：
- 确认已启用最新补全：
source <(conda shell completions bash)，且该行已写入~/.bashrc - 检查补全函数是否被覆盖：运行
complete -p conda，输出应为类似complete -F _conda_auto_dev conda；若显示-o default，说明 fallback 到了基础文件补全，需重载 - 手动增强环境名补全：在
~/.bash_completion末尾追加
_conda_activate() {
local cur="${COMP_WORDS[COMP_CWORD]}"
COMPREPLY=($(conda env list --name-only 2>/dev/null | grep "^$cur"))
}
complete -F _conda_activate "conda activate"
这样 conda activate py 就只会匹配以 py 开头的环境名，而非列出全部。
为什么 Terminator 里补全响应慢或不一致？
Terminator 是多进程终端复用器，每个标签页是独立的 Bash 进程，补全函数必须在每个会话中重新加载。常见问题包括：
~/.bash_completion被 source 但未执行complete -F注册（尤其在非交互式子 shell 中）$TERMINATOR_UUID环境变量存在时，某些补全脚本会跳过初始化（例如旧版bash-completion1.x）- 补全函数依赖外部命令（如
kubectl、aws），而这些命令在某分会话中 PATH 不全，导致补全卡住或失败
验证方式：新开 Terminator 标签页，运行 complete -p conda 和 type _conda_activate，两者都应有输出；若无，说明补全未生效，需检查 ~/.bashrc 是否在每次新会话中完整执行。
自定义补全时最容易忽略的兼容性点
补全函数不是纯 Bash 脚本，它运行在 COMP_* 变量约束的上下文中，几个关键限制常被忽略：
COMP_WORDS是分词后的数组，但分词依据是COMP_WORDBREAKS（默认含=:），所以git -c core.editor=vim会被截断，补全函数需手动解析COMPREPLY必须是纯字符串数组，不能含空格或换行；想补带空格的路径，得用printf %q转义- Bash 4.4+ 支持
compopt -o nospace防止补全后自动加空格，但 Ubuntu 22.04 默认 Bash 5.1，而 20.04 是 5.0 —— 跨版本写补全函数时要避开compopt或做版本判断
补全深度本质上是函数实现粒度的问题，不是开关一开就变深。真正影响体验的，往往是补全函数是否处理了当前光标位置的语义上下文，而不是单纯增加候选数量。
