在开发桌面剪贴板同步应用时，遇到了一个令人困扰的问题：即使修改与 objc2 库无关的代码，Rust 编译器也会重新编译 objc2 库，严重影响效率。经优化 Cargo 配置和使用 sccache 加速编译等措施，大幅提升了构建效率。优化策略包括增加并行编译单位、差异化处理依赖、优化缓存策略以及改进增量编译。优化后，首次构建略有增加但增量构建时间减少至80%以上，开发体验由等待30-60秒减至5-10秒。优化经验包括理解依赖关系、差异化处理依赖、利用缓存以及权衡取舍。这些技巧不仅适用于objc2库，也适用于其他包含慢速编译依赖的Rust项目，为提高开发效率提供了指导。

在 Rust 开发中，优化类型转换代码是一个常见问题。通过使用 Rust 标准库提供的 `From` trait，可以更符合语言惯用法地实现类型转换。在此过程中，遇到了传入参数数量不匹配的问题，通过使用元组来解决。另外，在处理 `Path` 和 `PathBuf` 类型时，发现了它们的差异，需要灵活处理。最终，采用了标准的泛型参数方式，通过实现 `From<(&Payload, P)> for ClipboardMetadata` 使代码更通用灵活，符合 Rust 的设计原则。`AsRef` trait 在实现灵活引用转换中起到关键作用，提供了统一转换方式，设计更灵活、避免冗余代码，让 API 更加通用。通过这次重构，代码更符合 Rust 的惯用法，接口更灵活，利用 Rust 强大的类型系统，适用于需要设计接受多种相似类型参数的 API 场景。在 Rust 中，建议优先使用标准 trait 进行类型转换，利用 `AsRef` / `AsMut` 实现灵活引用转换，通过泛型参数使 API 更通用。

在 Rust 异步编程中，一个常见的错误是在持有 Mutex 锁的情况下使用 .await，导致编译错误。出错的本质在于 MutexGuard 不是 Send 的，而异步任务在 .await 点可能会在不同线程间切换，违反了 Rust 的线程安全保证。解决方案是在 await 前释放锁，通过作用域控制确保 MutexGuard 在 .await 之前被释放。此外，建议考虑使用专为异步设计的锁如 tokio::sync::Mutex，以及使用更细粒度的锁策略以减少锁持有时间。在 Rust 异步编程中应特别注意锁的使用方式，避免在持有 Mutex 的锁时使用 .await，确保 MutexGuard 在调用 .await 之前被释放，优先使用作用域块来控制锁的生命周期。

异步互斥锁与同步互斥锁相比更昂贵的原因在于内部实现复杂、需管理任务等待队列、唤醒机制，与异步运行时集成带来额外开销，并在内部仍使用同步互斥锁。只有需要在持有锁的同时执行异步操作时，异步互斥锁的额外开销才值得。在IO密集型操作、长时间持有锁和资源有限环境下使用异步互斥锁。标准互斥锁更适合不跨越.await点持有锁的情况。在性能对比中，异步互斥锁可能比标准互斥锁慢1.5-3倍。

互斥锁（Mutex）是一种同步原语，用于保护共享数据，确保只有一个线程可以访问。两种互斥锁的主要区别在于阻塞行为、跨越.await点和性能开销：标准库Mutex阻塞整个线程，而异步Mutex只挂起当前任务；标准库Mutex不能安全地跨越.await点，但异步Mutex可以。何时使用哪种互斥锁取决于场景：标准库互斥锁适合保护内存数据、短时间持有、不需要异步操作且对性能要求高；异步互斥锁适合需要执行异步操作、保护IO资源、可能长时间持有且不希望阻塞整个线程的场景。最佳实践是默认选择标准库互斥锁，并将其包装在结构体中提供方法来操作内部数据，对于IO资源考虑使用专门的管理任务。

在 Windows 上构建 Rust 时，缺少 OpenSSL 报错问题可以通过使用 choco 安装 OpenSSL 并设置环境变量解决。安装完成后设置 OPENSSL_DIR 和 OPENSSL_LIB_DIR 环境变量，重启 VSCode 即可成功构建。详情可参考 https://juejin.cn/post/6994715287178182693。

在 Rust 开发中，测试是确保代码质量的关键环节。然而，并行执行测试可能导致共享资源冲突。解决方案包括使用 serial_test crate 进行串行测试、互斥锁控制资源访问、创建独立测试环境、使用测试模块和一次性初始化以及忽略并行影响敏感测试。选择合适策略取决于具体需求，但保证测试的可靠性与一致性至关重要。