std::span 传给 C 函数时，data() 和 size() 安全可用，前提是 span 生命周期 ≥ C 调用期且内存连续；它不管理内存、零开销，但跨 DLL/SO 边界需谨慎。

std::span

传给 C 函数时，data() 和 size() 是安全的起点

只要 std::span 持有的是连续内存（比如 std::vector、原生数组、std::array），它的 data() 返回的就是符合 C ABI 的裸指针，size() 是元素个数——这两者可直接喂给绝大多数 C 风格 API，例如 memcpy、write、glBufferData 等。

关键前提是：确保 span 生命周期 ≥ C 函数调用期。C 函数不会持有 span，只读/写当前内存块，所以只要 span 所指内存没被提前释放或移动，就安全。

• std::span 本身不管理内存，它只是视图；传参不触发拷贝，开销为零
• 避免把临时容器的 data() 包进 span 再传出去，比如 std::span{std::vector{1,2,3}.data(), 3} —— vector 一销毁，data 就悬空
• 对 const 数据，优先用 std::span，防止 C 接口意外修改（即使函数声明为 const T*，也建议类型匹配）

从 C 指针 + 长度构造 std::span 要检查空指针和长度

用 std::span(ptr, count) 构造时，标准允许 ptr == nullptr 当且仅当 count == 0。但很多 C API 在缓冲区为空时仍可能传 nullptr + 0，此时构造合法；若 ptr == nullptr && count > 0，行为未定义。

实际交互中常见场景是封装 C 回调（如网络 recv 回调传 void* buf, size_t len），需手动防护：

• 显式判断：if (buf == nullptr && len > 0) throw std::invalid_argument("null buffer with non-zero length");
• 或用 std::span 的构造函数重载：只有 std::span(T*, size_t) 和 std::span(std::array&) 等安全重载，没有接受裸 void* 的构造函数，必须先 static_cast(buf)
• 如果 C API 可能传 NULL 表示“跳过”，建议在封装层统一转成空 span：std::span{} （等价于 std::span(nullptr, 0)）

与 C++17 之前的 raw pointer + size 模式对比，span 更易防错

过去常用 T* ptr, size_t n 组合传参，容易漏校验、误传 n、混淆字节 vs 元素数。而 std::span 把二者绑定，类型系统强制关联：

• 传 std::span 给期望 int* + size_t 的 C 函数？编译不过 —— 必须显式调用 .data() 和 .size()，提醒你“正在脱壳”
• 函数签名用 std::span 表达二进制 blob，比 const void* 更清晰，且支持范围 for、subspan 切片
• 注意：C 接口若要求字节长度（如 send(int, const void*, size_t, int)），别直接传 span.size() —— 要乘以 sizeof(ElementType)，否则发错字节数

跨 DLL / SO 边界传递 std::span 可能出问题

std::span 是纯头文件、无状态、标准布局（trivially copyable），按理说可以跨 ABI 边界传值。但实际中要小心：

• 不同编译器（MSVC / GCC / Clang）或同一编译器不同 STL 版本，对 std::span 的内存布局是否完全一致，没有强保证；C ABI 不承诺 C++ 类型布局
• 更稳妥做法：DLL 导出函数参数坚持用 T* + size_t，内部再包成 std::span；不要导出带 std::span 的函数签名
• 如果必须跨模块传视图（比如插件系统），考虑用 struct { void* data; size_t size_bytes; } 这类 POD，由双方约定元素类型

void process_buffer(std::span buf) {
    // 安全：buf.data() 可直接传给 write()
    ssize_t n = write(STDOUT_FILENO, buf.data(), buf.size_bytes());
    if (n < 0) handle_error();
}
// 调用方：
std::vector v = {1,2,3,4};
process_buffer(v); // 自动推导为 span
// 从 C 回调来：
extern "C" void on_data_received(void buf, size_t len) {
if (!buf && len > 0) return; // 防御性检查
std::span s{
static_cast>(buf), len
};
process_buffer(s); // 复用上面函数
}

C 风格 API 本身不关心 span，真正需要警惕的是生命周期管理和跨边界假设——类型安全只是第一步，内存活着才是硬门槛。