std::mutex 仅保护访问行为而非数据本身，需手动在所有并发访问路径上加锁/解锁；结构体复杂性不影响锁用法，但影响临界区设计合理性，关键在于保障不变量原子性、避免锁内阻塞、统一多锁获取顺序、正确管理指针生命周期。
std::mutex 不能直接保护结构体，只能保护访问行为
互斥锁本身不“绑定”到某个变量或结构体上，它只是一把门禁开关。你定义一个 std::mutex，然后在所有可能并发读写该结构体的代码路径前加锁、操作后解锁——这才是保护逻辑。结构体是否“复杂”（含 vector、string、嵌套对象等）不影响锁的用法，但会影响临界区设计是否合理。
- 结构体内部成员是否可被独立访问？如果是，考虑拆分锁（如为每个字段配独立 mutex），而非一把锁锁整个结构体
- 若结构体有不变量（例如
size == data.size()），必须确保所有破坏该不变量的操作都在同一把锁下原子完成 - 避免在持有锁时调用可能阻塞或抛异常的函数（如
std::cout、文件 I/O、第三方库接口），否则延长临界区或导致死锁
std::lock_guard 是首选，但注意作用域和拷贝问题
对结构体的多步操作（比如先查再改、遍历后删）必须包裹在同一个 std::lock_guard 作用域内，否则中间状态暴露给其他线程。常见错误是误以为“锁一次就能管全程”，结果把锁声明在函数开头，却在中间某处提前释放（比如 return 或 goto 跳出）——std::lock_guard 的析构是自动的，只要它还在作用域里，锁就一直持有。
- 不要把
std::lock_guard对象传参或返回，它不可拷贝、不可移动 - 不要在循环体内反复构造/析构
std::lock_guard（性能损耗小但语义易错），应把整个循环包进一个锁作用域，除非循环体内部可安全并行 - 如果结构体方法需要对外提供线程安全接口，建议把
std::mutex成员和std::lock_guard使用封装在类内部，而不是让调用方手动加锁
多个 mutex 一起用时，顺序不一致必然导致死锁
当一个结构体涉及多个资源（例如缓存 + 日志队列 + 状态标志），且不同线程以不同顺序获取这些锁时，std::mutex 的阻塞特性会立刻引发死锁。这不是结构体复杂导致的，而是锁序混乱的必然结果。
- 所有线程必须按**完全相同的全局顺序**获取多个 mutex，例如始终先 lock
cache_mutex再 locklog_mutex - 使用
std::lock（可变参数版本）配合std::adopt_lock可规避手写顺序，但要求你明确管理所有锁对象的生命周期 - 更稳妥的做法是：把多个关联资源合并到一个结构体中，并只用一个
std::mutex保护其整体不变量，减少锁数量
结构体含指针或 shared_ptr 时，锁不解决对象生命周期问题
std::mutex 只同步访问，不管理内存。如果结构体成员是指向动态对象的裸指针或 std::shared_ptr，而其他线程可能在你加锁期间销毁该对象，那即使锁住了结构体本身，解引用仍会崩溃。
- 裸指针场景：加锁后需额外检查指针是否仍有效（通常需配合引用计数或外部生命周期协议）
-
std::shared_ptr场景：指针本身的读写是线程安全的（C++11 起），但其所指对象的内容仍需单独同步 - 最简方案：避免在结构体中存裸指针；若必须，用
std::weak_ptr配合 lock() 检查有效性，且该 check 和后续使用必须在同一临界区内完成
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
