/// 案例二：Mutex 是 Send 但不是 Sync
/// 
/// 这个例子展示了 Send 和 Sync 的微妙区别
mod case_mutex_send_not_sync {
    use std::sync::Mutex;
    use std::thread;
    pub fn demonstrate() {
        let mutex = Mutex::new(0);
        // Mutex 实现了 Send：可以把所有权转移到另一个线程
        // 这对用 Mutex 保护跨线程共享数据至关重要
        thread::spawn(move || {
            let mut guard = mutex.lock().unwrap();
            *guard += 1;
        }).join().unwrap();
        // 但是 &Mutex 不能随意跨线程共享
        // 因为 Mutex 允许通过不可变引用获取可变访问（内部可变性）
        // 编译器需要确保引用传递是安全的
    }
}

Mutex 相关场景容易让人误判。它之所以重要，不是因为“加了锁就万事大吉”，而是因为它展示了 Rust 如何区分“所有权转移”和“引用共享”这两类不同的线程行为。

/// 案例四：Arc> 的自动推导链
/// 
/// 为什么 Arc> 同时是 Send 和 Sync（当 T: Send 时）：
/// - Arc: 当 T: Send + Sync 时，Arc 是 Send + Sync
/// - Mutex: 当 T: Send 时，Mutex 是 Send + Sync
/// - 因此 Arc>: 当 T: Send 时，同时是 Send + Sync
/// 
/// 这个组合是 Rust 中最常用的线程安全共享模式
fn arc_mutex_auto_derivation() {
    let shared = Arc::new(Mutex::new(vec![1, 2, 3]));
    let shared_clone = Arc::clone(&shared);
    thread::spawn(move || {
        // Arc>> 实现了 Send，可以 move 进闭包
        let mut data = shared_clone.lock().unwrap();
        data.push(4);
    }).join().unwrap();
    // Arc>> 实现了 Sync
    // 可以安全地在多个线程间共享不可变引用
    let guard = shared.lock().unwrap();
    println!("Final: {:}", *guard);
}

Arc> 之所以常见，不是因为它神奇，而是因为推导链条完整闭合了：Arc 负责跨线程共享所有权，Mutex 负责串行化内部访问，只要内部的 T: Send，这个组合通常就能同时满足 Send 和 Sync。

这些案例背后的系统价值

这些例子最值得看的地方，不是某个技巧本身，而是 Rust 的整体思路：默认让编译器替你兜底，只有在确实需要突破自动规则时，才显式写出 unsafe impl Send 或 unsafe impl Sync，把责任清楚地放回开发者手里。

当自动推导不够用时，如何用 PhantomData 精细控制

/// 案例三：自定义类型 Send/Sync 推导的精细控制
/// 
/// 使用 PhantomData 标记来手动控制自动推导
use std::marker::PhantomData;
/// 一个包装了 C 库句柄的类型
/// C 库的句柄通常是线程不安全的，但可能在某些条件下安全使用
pub struct ForeignHandle {
    raw: *mut std::ffi::c_void,
    /// 为什么用 PhantomData<*const u8>：
    /// *const u8 既不 Send 也不 Sync
    /// 编译器会阻止自动推导 ForeignHandle 的 Send/Sync
    /// 这比标记 !Send 更灵活——可以在确认安全后手动 unsafe impl
    _not_send: PhantomData<*const u8>,
}
// 确认句柄在特定条件下可安全跨线程传递后，
// 手动 unsafe impl Send
// 
// 为什么需要 unsafe impl 而非让编译器自动推导：
// 编译器看到 *mut c_void 就会拒绝推导 Send
// 但这可能是误报——如果 C 库文档明确声明线程安全
unsafe impl Send for ForeignHandle {}

自动推导依赖的是结构信息，也就是“字段长什么样”。可现实里的线程安全很多时候取决于语义约束，例如底层 C 库的文档、句柄是否绑定线程、API 是否要求单线程初始化等。这些信息编译器本身并不知道。

这时 PhantomData 就成了一个很实用的工具。它不一定真的持有某个值，但能把某种语义影响带进类型系统，让编译器停止对 Send/Sync 做过于乐观的自动推导。

/// 案例五：通过 newtype 模式阻断 Send 推导
/// 
/// 为什么需要阻断自动推导：
/// 某些类型在语义上不应跨线程，但字段碰巧都是 Send 的
/// 如：绑定到特定 OS 线程的句柄（信号处理、TLS 数据）
pub struct ThreadBound {
    inner: T,
    /// PhantomData> 阻止 Send 推导
    /// 因为 Rc<()> 不实现 Send
    /// 这不是真正持有 Rc，只是借用其 Send 否定语义
    _not_send: PhantomData>,
}
impl ThreadBound {
    pub fn new(inner: T) -> Self {
        Self { inner, _not_send: PhantomData }
    }
    pub fn get(&self) -> &T {
        &self.inner
    }
}

这种做法的价值在于，它让“这个类型不该跨线程”成为类型定义的一部分，而不是散落在文档注释或团队约定里。对于线程绑定资源、TLS 数据、特定 OS 句柄之类对象，这种约束往往比事后排查 bug 更可靠。

自动推导的边界，以及 unsafe impl 真正危险的地方

自动推导很强，但它不是万能的。编译器只能检查字段组合，无法理解业务语义，也无法替你阅读第三方 C 库的并发说明。因此，“字段看起来能跨线程”并不等于“这个抽象真的适合跨线程使用”。