cargo build 正常，cargo test 却报 unknown lint：别漏了 rustdocflags

cargo build、cargo clippy 和 cargo run 都能通过，cargo test 却提示 unknown lint: must_not_suspend。把 unknown_lints 设成 deny 后，测试直接失败。若功能开关只写在 build.rustflags，需要检查失败的是不是文档测试。

这个明确场景使用 Cargo 1.101.0-nightly，以及支持 must_not_suspend 的 nightly 编译器。该 lint 仍受不稳定功能开关约束；不能把下面的 -Z 配置复制到稳定工具链。

先分开两个测试入口

在已经选择相同 nightly 工具链的前提下，分别运行：

cargo test --lib
cargo test --doc

多包工作区应加相同的 -p 选择，使用外部清单时也保持 --manifest-path 一致。测试可能调用项目代码和构建脚本，按项目原有测试环境运行。

如果 --lib 能过而 --doc 报未知 lint，问题集中在 rustdoc 路径。默认 cargo test 会包含 lib 的文档测试，即使库文件没有文档示例，也不能凭“没有写文档”排除这个阶段。删除 lib 目标会改变测试覆盖范围，不宜用它消除报错。

给 rustdoc 配置所需功能开关

下面是这个 nightly lint 的配置形状，写在项目实际读取的 .cargo/config.toml 中：

[build]
rustflags = ["-Zcrate-attr=feature(must_not_suspend)"]
rustdocflags = ["-Zcrate-attr=feature(must_not_suspend)"]

rustflags 控制 rustc，rustdocflags 控制 rustdoc，两者不会自动互相补齐。保留 Cargo.toml 中原有的 lint 等级；把未知 lint 统一降成 allow 只会隐藏配置缺失。

若环境中设置了 RUSTDOCFLAGS 或 CARGO_ENCODED_RUSTDOCFLAGS，它们可能优先于配置文件，应连同 CI 变量一起核对。不要在 shell 与配置文件中随意叠加多套开关。

还有一类相似症状：把父目录 .cargo 复制进子目录后，出现 duplicate_features。Cargo 会向上寻找并合并配置，数组可能累加。--manifest-path 指定清单不意味着只读清单旁边的配置。保留一处功能开关，或明确配置继承关系；复制文件来“确保能读到”反而可能重复注入。

修改前保存原配置和工具链文件。复查时先分别确认 --lib 与 --doc，再跑原来的完整测试命令，检查未知 lint 和重复 feature 都消失，测试数量没有因删除目标或禁用 doctest 减少。将来切换稳定版时，应同时重新判断 lint 是否稳定，不能长期保留仅 nightly 可用的 -Z 参数。