服务端编写多层嵌套foreach是否正常？对应业务场景最优实践是什么？

业务场景：现有若干学生，每名学生对应一组课程，每门课程对应多组课时，需要对所有课时做笛卡尔积生成全部可能的组合。
示例：
学生1选修的课程为：c#、c++
c#对应的理论课时为1、2，实验课时为3、4
c++对应的理论课时为5、6，实验课时为7、8
需要生成所有课时的排列组合，目前使用多层嵌套foreach可以正常实现功能，询问是否属于正常实现、有没有更优方案。

多层嵌套foreach的合理性判断 #

业务逻辑需要的前提下，3层以内的短逻辑嵌套foreach属于正常实现方式，但你当前的场景属于可变层级的笛卡尔积计算，硬编码多层foreach属于凑能用的临时方案，后续业务扩展（比如新增课程、新增课时类型）时需要不断加嵌套层数，会导致代码可读性、可维护性极速下降，不属于最优实践。

更优解决方案：通用笛卡尔积计算方法 #

你可以直接实现一套不依赖硬编码嵌套层数的通用笛卡尔积计算逻辑，不管后续有多少组课时参与计算，都不需要调整循环结构。以下为C#的实现示例：

/// 通用多集合笛卡尔积计算方法，支持任意数量的同类型集合做乘积
public static IEnumerable<IEnumerable<T>> BuildCartesianProduct<T>(IEnumerable<IEnumerable<T>> inputCollections)
{
    // 初始化结果容器
    IEnumerable<IEnumerable<T>> result = new[] { Enumerable.Empty<T>() };
    foreach (var collection in inputCollections)
    {
        // 每次迭代拼接一层集合的所有可能
        result = result.SelectMany(prevCombination => 
            collection.Select(currentItem => prevCombination.Concat(new[] { currentItem }))
        );
    }
    return result;
}

业务侧调用代码非常简洁：

// 按顺序组装所有需要做笛卡尔积的课时集合
var hourCollections = new List<List<int>>
{
    new() {1, 2}, // C#理论课时
    new() {3, 4}, // C#实验课时
    new() {5, 6}, // C++理论课时
    new() {7, 8}  // C++实验课时
};

// 直接获取所有组合，输出结果和多层嵌套foreach完全一致
var allCombinations = BuildCartesianProduct(hourCollections).ToList();

该方案的优势非常明显：

• 可扩展性极强：后续新增课程、新增课时类型只需要往hourCollections里加对应集合即可，不需要修改核心逻辑
• 可读性更高：业务侧不需要关心嵌套逻辑，核心计算逻辑集中在通用方法，便于维护
• 性能和硬编码多层foreach基本持平，没有额外的大额性能损耗

大数据量场景的额外优化 #

如果最终生成的组合量级超过10万，可以做两点优化：

• 流式返回：不要一次性把所有组合加载到内存，使用迭代器（如C#的yield return）按需返回组合，降低内存占用
• 前置过滤：参与乘积之前先过滤掉无效的课时数据，减少参与计算的元素数量，从源头降低组合量级

多层嵌套foreach的通用最优实践 #

日常开发中可以参考以下规则判断是否需要优化嵌套foreach：

• 嵌套层级不超过3层、每层逻辑非常简单的场景可以保留嵌套写法
• 嵌套层级超过3层、或者嵌套层数会随业务扩展增加的场景，优先抽离通用逻辑、用链式调用（如LINQ）、递归等方式替代
• 深层嵌套中不要写复杂业务逻辑，复杂处理逻辑统一抽离为独立方法
• 性能敏感场景提前预估总循环次数，总次数超过10^6时优先优化算法、提前过滤无效数据，避免服务端出现性能瓶颈

内容的提问来源于stack exchange，提问作者Mohammad Bhbouh