如何在两个TableView间基于Struct保持数组顺序？

首先，核心问题在于你的List是值类型（Struct），每次复制都会生成新的实例——直接靠实例本身无法关联原始数据的顺序。所以我们需要给每个List实例加一个唯一标识，再基于这个标识来维护顺序逻辑，具体步骤如下：

1. 给List添加唯一标识符 #

给List结构体新增一个不可变的id属性，用UUID生成（保证全局唯一性），这样即使是复制出来的List实例，也能通过id对应到原始的逻辑实体：

struct List {
    let id = UUID() // 初始化时自动生成唯一ID，不可修改
    var name: String
    var items: [Item]
}

2. 向第二个数组添加元素时维护顺序 #

当用户从第一个TableView（listOfPossibleThings）选中行，需要复制到第二个数组（listOfActualThings）时，我们要根据选中List在listOfPossibleThings中的位置，把它插入到listOfActualThings的正确位置，确保顺序和源数组一致：

extension SomeTasks {
    mutating func addToActualList(selectedList: List) {
        // 先避免重复添加同一个List
        guard !listOfActualThings.contains(where: { $0.id == selectedList.id }) else {
            return
        }
        
        // 找到选中List在源数组中的索引
        guard let sourceIndex = listOfPossibleThings.firstIndex(where: { $0.id == selectedList.id }) else {
            return
        }
        
        // 找到目标数组中第一个在源数组里位置更靠后的元素，确定插入点
        let insertionIndex = listOfActualThings.firstIndex { actualList in
            guard let actualSourceIndex = listOfPossibleThings.firstIndex(where: { $0.id == actualList.id }) else {
                return false
            }
            return actualSourceIndex > sourceIndex
        } ?? listOfActualThings.count
        
        // 复制并插入到正确位置
        listOfActualThings.insert(selectedList, at: insertionIndex)
    }
}

比如源数组顺序是ListA → ListB → ListC，用户先选ListC再选ListA，最终listOfActualThings的顺序会是ListA → ListC，和源数组的顺序一致。

3. 同步源数组顺序变化后的目标数组 #

如果用户在第一个TableView中调整了listOfPossibleThings的顺序（比如拖拽排序），我们需要同步更新listOfActualThings的顺序，保证两者始终一致：

extension SomeTasks {
    mutating func syncActualListOrder() {
        listOfActualThings.sort { list1, list2 in
            guard let index1 = listOfPossibleThings.firstIndex(where: { $0.id == list1.id }),
                  let index2 = listOfPossibleThings.firstIndex(where: { $0.id == list2.id }) else {
                return false
            }
            return index1 < index2
        }
    }
}

在源数组顺序变化后调用这个方法，listOfActualThings就会按照源数组的新顺序重新排序。

为什么这是最佳实践？ #

• 值类型友好：通过唯一ID关联逻辑实体，避开了值类型实例复制无法追踪的问题。
• 顺序一致性有保障：无论是添加元素还是源数组排序变化，都能严格保持两个数组的顺序匹配。
• 可扩展性强：后续如果需要添加更多关联逻辑（比如移动回源数组、编辑元素），基于id的设计可以轻松扩展。

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