要让 cargo.toml 具备依赖版本自动补全，必须安装 tamasfe.even-better-toml 插件，它是目前唯一稳定支持在 dependencies 等块中输入时实时调用 crates.io api 提供版本建议的 vscode 插件，开箱即用且不依赖 rust-analyzer。
要让 Cargo.toml 有依赖版本自动补全，必须装 tamasfe.even-better-toml
这个插件是目前唯一稳定提供「在 dependencies 或 [dev-dependencies] 块中输入时，自动弹出 crates.io 上最新可用版本」功能的 VSCode 插件。它不依赖 rust-analyzer，也不需要额外 CLI 工具，开箱即用。
注意：bierner.toml 只做基础语法高亮和格式化，不提供版本补全；redhat.vscode-yaml 完全无效——TOML 不是 YAML。
- 安装后重启 VSCode（或重载窗口），打开任意
Cargo.toml，在tokio =后按空格或双引号，会立刻触发版本建议 - 补全来源是 crates.io 的实时 API，不是本地缓存，所以首次触发可能稍慢（约 300–500ms）
- 如果没反应，检查是否禁用了网络请求：插件默认启用
crates.io查询，但若你在公司代理/防火墙后，需手动配置代理（见插件 README 中的evenBetterToml.cratesIoProxy设置）
Cargo.toml 悬停提示失效？检查 serayuzgur.crates 是否与 tamasfe.even-better-toml 冲突
serayuzgur.crates（常简称为 crates 插件）能显示依赖当前版本、最新版本、是否过期，并支持一键升级，但它不提供悬停提示中的语义信息（比如 crate 描述、仓库链接、关键词）。真正负责悬停的是 tamasfe.even-better-toml —— 它会在你把光标停在 serde = "1.0" 这行时，显示该版本的发布时间、crate 页面 URL 和简短描述。
- 两个插件可以共存，但若发现悬停内容变少或只显示原始字符串，大概率是
crates插件覆盖了语言服务器响应（它会注册自己的 hover provider） - 解决方案：在 VSCode 设置中搜索
evenBetterToml.hover.enabled，确保为true；再搜crates.showHover，设为false（禁用它的 hover，保留版本管理功能） - 不要同时开启
crates的“自动检查更新”和even-better-toml的“实时查询”，否则编辑器状态栏右下角会频繁闪烁网络图标
为什么 search crates.io 补全有时不出现？关键看字段位置和语法结构
自动补全只在明确的依赖声明上下文中触发，不是所有等号右边都生效。它依赖 TOML 的 section 解析和 key 名称识别，对书写格式敏感。
- ✅ 有效位置：
[dependencies]、[dev-dependencies]、[build-dependencies]下的裸 key 形式，例如：clap =、tokio = { version = - ❌ 无效位置：在
[package]块里写version =不会触发；用数组语法如dependencies = ["serde"]也不会补全（这不是标准 Cargo 写法，且插件不解析该形式） - ⚠️ 注意引号：写
serde =后直接打"，补全才激活；如果先打了"1.0"再删掉引号，插件可能未重置上下文，此时按Ctrl+Space手动唤出补全即可
依赖补全和悬停背后的网络调用不可跳过，离线时表现有限
所有版本数据来自 crates.io 的公开 API（https://crates.io/api/v1/crates/NAME/versions），插件本身不带本地数据库。这意味着：
- 没有网络时，补全列表为空，悬停只显示已缓存的最近一次结果（通常仅限过去 24 小时内查过的 crate）
- 首次查询某个 crate（如
anyhow）时，延迟取决于 CDN 响应速度，国内用户偶尔会卡顿 1–2 秒，属正常现象 - 如果你反复编辑
Cargo.toml且依赖项多于 20 个，建议关闭evenBetterToml.cratesIoThrottle的节流（默认 300ms 间隔），避免补全被排队丢弃
真正难处理的不是配置，而是当多个插件都试图接管同一段 TOML 文本的语义能力时，hover 和 completion 提供者之间的优先级竞争——这没法靠开关解决，得靠手动禁用非必要插件来保底。
