这是不可能的
opt-level是Cargo profile的一部分，它控制编译器的行为。配置文件是在构建时从默认配置文件、任何最终用户自定义配置文件以及用于执行构建的Cargo.toml设置的任何覆盖中选择的。您在库的Cargo.toml中设置的覆盖仅影响属于库的二进制文件。
如果您选择分发动态库，则可以为分布式共享对象/DLL设置opt-level，但这会阻止库的函数内联到用户代码中。
你最好的选择（关于opt-level）是建议用户（在文档，README或其他地方）opt-level = 3会产生代码膨胀，并建议使用opt-level = 2。一个提供类似建议的流行项目是Bevy，它建议设置opt-level以使调试构建更快。
根据库的不同，这可能会显著增加二进制文件的大小，同时可能比opt-level = 2慢。
如果您担心最终的二进制文件大小，还有其他方法可以减少生成的代码量。您可能会建议用户启用LTO，这可以以额外的编译时间为代价减少代码大小。
另一个常见的罪魁祸首是泛型，特别是非常长的函数的单体化。如果性能允许，您可以选择将泛型函数作为调用公共非泛型函数的存根。例如：

fn foo<S: AsRef<str>>(input: S) {
    // Some long, complex function.
    // ...
}

字符串
代码是为每一个调用foo()的不同类型生成的（&str，String，Cow<str>等）。你可以通过强制所有这样的调用遵循相同的路径来减少重复单态化的成本：

fn foo<S: AsRef<str>>(input: S) {
    foo_str(input.as_ref());
}

fn foo_str(input: &str) {
    // Complex logic goes here.
    // ...
}

型
这为foo()的每个单态化生成很少的代码，并且所有生成的函数都调用共享代码路径，从而导致更小的二进制文件和可能更好的指令缓存使用率。当然，YMMV;首先分析并关注导致最膨胀的函数。