C++11起局部静态数组初始化线程安全，但内容访问不安全；编译器通过__cxa_guard_acquire等机制确保首次初始化仅执行一次，后续并发线程阻塞等待，而数组元素读写需额外同步。
不安全，但需分两层看：局部静态 int 数组（如 static int arr[10]）的地址本身是线程安全的；而通过该数组返回的指针若被多线程并发读写其内容，则完全不安全。
局部静态数组的初始化是线程安全的，但内容访问不是
C++11 起，static 局部变量（包括数组）的**零初始化和动态初始化**由标准保证线程安全——编译器会插入类似 __cxa_guard_acquire 的保护逻辑，确保构造只执行一次。这意味着：
-
static int buf[256] = {0};这类带初值的数组，在首次调用时完成初始化，不会重复赋值 -
static std::array<int> buf;</int>或static std::vector<int> buf(256);</int>的构造也受此保障（前提是构造函数本身无数据竞争） - 但一旦初始化完成，后续所有线程拿到的都是同一块内存地址，
buf[0] = 42和buf[0] += 1就是典型的竞态操作
为什么返回 int* 指针在多线程里容易出问题
常见误用模式是封装一个“格式化函数”，例如：
const char* format_time() {
static char buffer[64];
time_t now = time(nullptr);
strftime(buffer, sizeof(buffer), "%Y-%m-%d %H:%M:%S", localtime(&now));
return buffer;
}问题不在 buffer 地址是否有效，而在于：
立即学习“C++免费学习笔记（深入）”；
- 线程 A 调用后拿到指针，还没来得及用完，线程 B 又调用，覆盖了
buffer全部内容 - 若两个线程同时执行
strftime，可能因内部localtime使用静态缓存而互相干扰（POSIX 中localtime本身就不线程安全） - 返回
const char*并不能阻止调用方强制转为非 const 后写入
替代方案：什么时候该换、怎么换
不要为了“省一次 malloc”牺牲正确性。实际选型取决于使用模式：
- 如果只是临时拼接、立刻打印（如日志宏内），用
std::string或std::ostringstream更清晰：return std::format("{}", now);（C++20） - 若必须返回 C 风格字符串且要求高性能，改用线程局部存储：
thread_local static char buffer[64];—— 每个线程独享一份 - 若需跨线程共享结果，必须用
std::shared_ptr<const std::vector>></const>或带引用计数的缓冲区，而非裸指针 - 绝对避免在递归调用或信号处理函数中使用这类静态缓存，
signalhandler 内调用strftime是未定义行为
最常被忽略的一点：即使你没显式开线程，C++ 标准库中某些操作（如 std::async、std::jthread 初始化、甚至部分 STL 算法的并行版本）都可能触发并发访问。静态数组的“全局可见性”是它的便利来源，也是它在现代 C++ 中越来越难安全使用的根本原因。
