如何在SwiftUI中为macOS拖拽功能注册多个Transferable或NSItemProvider表示

我之前也踩过一模一样的坑！SwiftUI的Transferable在macOS上的多表示支持确实有不少反直觉的地方，不过我们可以通过手动控制NSItemProvider的方式精准解决，或者调整Transferable的注册逻辑，让内部、外部拖拽各司其职。

核心问题分析 #

你遇到的第一个痛点是Transferable的多表示优先级冲突——系统会优先匹配第一个符合接收方需求的表示，而且visibility设置有时候没起到预期作用，本质是内部表示和外部表示的类型覆盖了。另外，Finder在拖拽悬停时就触发下载的问题，是macOS的默认行为，Transferable的FileRepresentation确实会提前执行异步操作，得用更底层的NSItemProvider规避。

解决方案一：手动构建NSItemProvider（推荐，更灵活） #

放弃Transferable的自动注册，改用.onDrag和.dropDestination手动控制每个拖拽表示，精准区分内部、外部场景：

1. 自定义UTType保持不变

extension UTType {
    static var customItem = UTType(exportedAs: "com.example.custom-item")
}

2. 调整View的拖拽逻辑

struct Item: Codable {
    let url: URL
    let isExternal: Bool
    
    // 辅助方法：下载文件到临时目录（替换成你的网络下载逻辑）
    func downloadToTempFile() async throws -> URL {
        let tempDir = FileManager.default.temporaryDirectory
        let tempFile = tempDir.appendingPathComponent(url.lastPathComponent)
        let data = try await Data(contentsOf: url)
        try data.write(to: tempFile)
        return tempFile
    }
}

// 你的列表视图
var body: some View {
    List(items, id: \.url) { item in
        ItemView(item: item)
            .onDrag {
                let provider = NSItemProvider()
                
                // 1. 内部拖拽：自定义类型，仅自己应用可见
                provider.registerDataRepresentation(
                    forTypeIdentifier: UTType.customItem.identifier,
                    visibility: .ownProcess
                ) { completion in
                    do {
                        let data = try JSONEncoder().encode(item)
                        completion(data, nil)
                    } catch {
                        completion(nil, error)
                    }
                    return nil // 不需要取消操作的回调
                }
                
                // 2. 外部拖出到Finder：文件URL表示，延迟加载（仅在放下时触发下载）
                provider.registerFileRepresentation(
                    forTypeIdentifier: UTType.fileURL.identifier,
                    visibility: .all
                ) { completion in
                    Task {
                        do {
                            let tempFile = try await item.downloadToTempFile()
                            // 第三个参数true表示系统会自动删除临时文件
                            completion(tempFile.path, nil, true)
                        } catch {
                            completion(nil, error, false)
                        }
                    }
                    return nil
                }
                
                return provider
            }
    }
    .dropDestination(of: [UTType.customItem, UTType.fileURL]) { providers, _ in
        for provider in providers {
            if provider.hasItemConformingToTypeIdentifier(UTType.customItem.identifier) {
                // 处理内部拖拽
                _ = provider.loadDataRepresentation(forTypeIdentifier: UTType.customItem.identifier) { data, error in
                    guard let data = data, error == nil else { return }
                    do {
                        let item = try JSONDecoder().decode(Item.self, from: data)
                        DispatchQueue.main.async {
                            print("内部拖拽接收：", item.url)
                            // 这里添加你的内部处理逻辑
                        }
                    } catch {
                        print("解码内部项失败：", error)
                    }
                }
            } else if provider.hasItemConformingToTypeIdentifier(UTType.fileURL.identifier) {
                // 处理外部拖入
                _ = provider.loadObject(ofClass: URL.self) { url, error in
                    guard let url = url as? URL, error == nil else { return }
                    DispatchQueue.main.async {
                        let externalItem = Item(url: url, isExternal: true)
                        print("外部拖拽接收：", externalItem.url)
                        // 这里添加你的上传逻辑
                    }
                }
            }
        }
        return true
    }
}

为什么这个方法有效？

• 内部拖拽的自定义表示设置了visibility: .ownProcess，只有你的应用能识别，不会干扰外部拖拽。
• 外部拖拽的registerFileRepresentation闭包仅在接收方（比如Finder）实际请求数据时才会执行，也就是用户放下拖拽项的时候，完美解决了提前下载的问题。
• 手动控制每个表示的优先级，不会出现系统只取第一个表示的情况。

解决方案二：修复Transferable的表示注册逻辑 #

如果你不想放弃Transferable，可以调整表示的顺序和类型，确保内部表示优先被自己的应用识别：

struct Item: Codable, Transferable {
    let url: URL
    let isExternal: Bool
    
    static var transferRepresentation: some TransferRepresentation {
        // 1. 内部拖拽：自定义类型，仅自己应用可见，放在最前面
        CodableRepresentation(contentType: .customItem)
            .visibility(.ownProcess)
        
        // 2. 外部拖出：文件表示，处理异步下载
        FileRepresentation(exportedContentType: .fileURL) { item in
            let tempFile = try await item.downloadToTempFile()
            return SentTransferredFile(tempFile, shouldRemove: true)
        }
        
        // 3. 外部拖入：接受文件URL
        FileRepresentation(importedContentType: .fileURL) { file in
            Item(url: file.file, isExternal: true)
        }
    }
}

extension UTType {
    static var customItem = UTType(exportedAs: "com.example.custom-item")
}

然后你的View可以继续用.draggable(item)和.dropDestination(for: Item.self)，不过要注意：

• 这种方式在某些macOS版本下可能还是会出现优先级问题，比如Finder仍然优先选择自定义类型（虽然设置了visibility），所以手动用NSItemProvider的方法更可靠。
• 外部拖出的异步下载仍然可能在悬停时触发，这是Transferable的限制，所以如果这个问题对你影响很大，还是推荐方案一。

最后补充 #

你之前尝试的全局internalDrop变量思路其实可行，但.data类型确实不适合大文件。而用NSItemProvider的延迟加载表示，刚好解决了提前下载和大文件的问题——只有用户真正放下时才会下载，而且直接提供文件路径，不需要处理二进制数据。

备注：内容来源于stack exchange，提问作者Yakuhzi