Composer 命令原生无 zsh 补全，需通过 zsh-completions 提供 _composer 函数并正确配置 fpath 和 compinit 才能实现子命令、选项及包名的动态补全。
很多开发者可能都遇到过这样的困惑：明明在 Oh My Zsh 里启用了 Composer 插件，为什么输入 composer require 后按 Tab 键，期待的包名补全却迟迟不出现？其实，问题的关键在于，Oh My Zsh 自带的那个 composer 插件，主要功能是提供别名，它本身并不负责参数级的智能补全。要实现后者，通常需要借助 zsh-completions 这个社区项目，或者手动注册补全函数。
composer 插件只提供别名，不提供参数补全
首先得澄清一个常见的误解。当你把 composer 加入 Oh My Zsh 的插件列表（比如 plugins=(composer)），它确实会为你创建一些便捷的别名，比如 ci 对应 composer install，cu 对应 composer update。但是，它的工作到此为止。这个插件本质上是一个 alias 集合，与 zsh 强大的补全系统（completion system）是两套完全不同的机制。
- 它不会去修改
$fpath这个决定补全函数查找路径的关键变量。 - 它也不会调用
_command_names或_arguments这类底层函数来定义补全规则。 - 所以，即便启用了这个插件，当你输入
composer require lara vel/然后按 Tab，shell 依然不知道接下来该提示什么包名。同样，composer --help里列出的所有子命令，比如create-project、diagnose，也都不会被识别为可补全的目标。
必须启用 zsh-completions 并确保 compinit 正确加载
那么，真正的补全从何而来？答案是 zsh-completions。这是一个由社区维护的补全定义集合，其中就包含了一个名为 _composer 的函数。这个函数能够识别 Composer 的各种子命令、命令行选项，甚至能根据本地项目上下文动态补全包名和供应商（vendor）名称。
- 安装
zsh-completions只是第一步。安装后，必须确保包含_composer文件的目录路径被添加到了$fpath环境变量中。一个常见的错误是只安装了插件，却没有正确运行compinit来初始化补全系统。 - 在
~/.zshrc配置文件里，顺序很重要。compinit的调用必须放在所有插件加载之后，否则补全函数可能注册失败。 - 一个推荐的配置写法如下：
plugins=(git composer zsh-completions) autoload -Uz compinit compinit -i
（这里的-i选项可以忽略某些不存在的补全文件，避免启动时报错中断。） - 配置完成后，可以通过运行
echo $fpath命令来验证。你应该能在输出中看到类似/Users/xxx/.oh-my-zsh/custom/plugins/zsh-completions/src这样的路径。
补全效果依赖 Composer 的本地上下文
需要特别注意的是，_composer 提供的补全并非完全静态的列表，它的行为高度依赖于当前的 Composer 环境上下文。
- 如果你在一个空目录下输入
composer require然后按 Tab，它可能只会补全一些通用选项，比如--dev、--no-update，而不会列出任何具体的包名。 - 但当你进入一个已有 Composer 项目的根目录后，再输入
composer require lara vel/并按 Tab，它就有可能动态地提示出lara vel/framework、lara vel/tinker等已知的包名前缀。 - 如果想要补全 Packagist 上的所有包（例如输入
monolog/后补全），这通常需要composer global show命令可用且网络连接通畅。如果条件不满足，补全系统可能会回退到使用缓存，或者干脆静默失败。 - 另外，对于自定义的私有仓库（比如用 Satis 搭建的），补全函数通常无法自动识别，除非你在项目的
composer.json文件中显式配置了repositories字段。
自定义补全函数比改插件更可控
对于有特定工作流的开发者来说，依赖通用的补全逻辑可能不够用。如果你经常执行一些模式固定的命令，比如 composer create-project lara vel/lara vel myapp --stability=stable，那么自己编写一个硬编码的补全函数往往更可靠、更高效。
- 你可以在
~/.oh-my-zsh/custom/completions/目录下创建一个文件，例如_mycomposer，然后在里面使用_arguments等 zsh 函数来显式声明参数规则。 - 举个例子，为自定义别名
ccp编写补全，让它固定提示几个常用的项目模板：_ccp() { local -a templates templates=( "lara vel/lara vel" "symfony/skeleton" "yiisoft/yii2-app-basic" ) _describe 'template' templates } - 接着，在
~/.zshrc中添加配置，将这个自定义目录加入补全搜索路径，并加载函数：fpath+=("$ZSH_CUSTOM/completions") autoload -Uz _ccp - 这里有个关键细节：自定义的补全函数名必须以
_下划线开头，并且文件名必须与函数名完全一致，否则compinit在扫描时就无法找到它。
总而言之，Composer 在 zsh 下的补全能否生效，最终取决于几个条件：_composer 函数是否被正确加载到环境中、当前目录是否提供了足够的上下文信息、以及你输入的命令是否匹配补全函数中定义的 case 分支。别指望它像集成开发环境（IDE）那样无所不知，它只是 shell 层面的一层轻量级适配，旨在提升命令行操作的流畅度。
