调整不了的吧，这两个互斥的条件，应该只能编译其中一个，也就是只有一个有跳转、refactor 之类的 ide 功能

你说的这几个在vscode中的问题，都可以通过调整vscode的配置，设置高亮的模式，是全部高亮，还是选择分支高亮。vscode的显示不是问题。 唯一需要考虑的是cfg这种方式，写多了，太乱，是不太优雅，哈哈。

这种方式基本只能应急，因为有很多缺点，比如

1. 在 vscode 中，rust-analyzer 默认是打开 test 的，所以只会高亮 #[cfg(tset)] 下的代码，实际环境中调用的代码反而失去 ide 支持
2. 第一个缺点的延申，如果 #[cfg(not(test))] 下的代码使用了 use 导入的依赖，rust-analyzer 会报警告，因为依赖未使用，但实际编译不会有警告。虽然解决很简单，但看着很难受就是了
3. 如果需要区分的地方多了，很容易写错，而且东一块西一块的，影响 review 代码
4. 为了测试而侵入业务逻辑，这种做法不太优雅，当然，如果是应急，怎么来都行，有时我还会用 if false {} 代替注释，这样不会报警告，对强迫症非常友好，哈哈

所以总体来说，用条件编译有点得不偿失

--
👇
LazyBoy: 在不更改书写模式的情况下，大概也只有条件编译宏好用了，就是第一位老兄说的#[cfg(test)]

简单写的就是：

#[cfg(test)]
let seed = generate_odd_int();
#[cfg(not(test))]
let seed = CONST VALUE / FN;

在不更改书写模式的情况下，大概也只有条件编译宏好用了，就是第一位老兄说的#[cfg(test)]

简单写的就是：

#[cfg(test)]
let seed = generate_odd_int();
#[cfg(not(test))]
let seed = CONST VALUE / FN;

推荐使用依赖注入，对测试非常友好

pub struct Random;

impl utils::RandomOddInt for Random {
    fn random_odd_int() -> usize {
        todo!("这里是实际实现")
    }
}

pub mod utils {
    pub trait RandomOddInt {
        fn random_odd_int() -> usize;
    }

    pub fn generate_id<R: RandomOddInt>() -> String {
        // 在这里调用random里的random_odd_int
        let seed = R::random_odd_int();
        format!("{:010}", seed)
    }
}

#[cfg(test)]
mod tests {
    use super::utils::*;

    use super::utils::RandomOddInt;

    struct MockRand;

    impl RandomOddInt for MockRand {
        fn random_odd_int() -> usize {
            1
        }
    }

    #[test]
    fn test_generate_id() {
        let excepted = "newid9091";
        // 在调用generate_id之前，我要怎样使用mock才能让random_odd_int返回固定值
        let actual = generate_id::<MockRand>();
        assert_eq!(actual, excepted.to_string());
    }
}

给一个不太美观的方法，用类似下面的方法来区分Test和非Test的代码，可以有多种用法，比如用Test标签来修饰use的部分，也可以在被调用的模块那边动手脚

#[test]
fn aaa() {
    println!("this is in test");
}

#[cfg(not(test))]
fn aaa() {
    println!("normal mode");
}