cargo metadata 少了工作区成员：检查默认成员与调用目录

在虚拟工作区根运行 cargo metadata 能看到多个默认成员，切到某个成员目录后，workspace_default_members 却只剩当前包。若质量检查工具只遍历这个数组，就可能悄悄漏掉其他包。

Cargo 1.94.0 有这个明确表现：该字段反映的是调用上下文下的默认成员，不应直接当成根清单的 [workspace] default-members 原样导出，更不能当成所有工作区成员。

先确定工具到底要检查哪些包

元数据中三个字段承担不同职责：packages 提供包信息，workspace_members 标识整个工作区的成员，workspace_default_members 是默认选择的成员。数组中的值是包 ID，应与 packages 的 id 关联，不要根据字符串末尾猜包名。

如果工具承诺检查整个工作区，应使用 workspace_members。如果工具要模拟当前目录执行 Cargo 的默认选择，则保留 workspace_default_members 的语义。两种用途不能共用一个“成员列表”变量后假定完全相同。

固定根清单与工作目录

需要读取根级默认选择时，让调用入口先切到已确认的工作区根。例如 Unix shell：

(cd /path/to/workspace && cargo metadata --format-version 1 --no-deps)

/path/to/workspace 是实际根目录占位值，需替换。子 shell 不改变外层终端目录，&& 保证切换失败后不在其他目录继续运行。--no-deps 省略依赖包展开，适合只读取本地工作区成员的工具；依赖图分析不能照抄这个选项。

若工具使用 --manifest-path，应明确指向根清单，不能仍指向当前成员的 Cargo.toml；同时固定调用位置，避免配置发现方式随启动目录改变。

非虚拟工作区还有根包，默认成员也不必然等于所有成员。若要设计明确的默认范围，可以在根清单设置 default-members，但这会影响根目录执行构建、测试等命令的默认选择，应作为项目行为变更评估，不能只为一段解析脚本顺手改掉。

验证时从根目录和至少一个成员目录读取同一工作区，比较 workspace_members 与默认选择，并检查工具实际处理的包名。验收标准是没有漏检承诺范围内的包，而不是两个数组强行变成相同内容。